TCP

You can disable the nagle algorithm using the TCP_NODELAY option..

However, it has some side effects, that you might not want.


Do a search for TCP_NODELAY in the MSDN.. or on Google



Stu M

It''s not the nagle algorithm. All the nagle algorithm does is delay sending until a minimum size is met or a certain amount of time passes. That means that even if you only send 1 byte and nothing more, it''ll eventually go through.

I''d say the problem is in your receiving program, I''ll bet you''ve got something like this:

char buffer[1024];
recv( sock, buffer, 1024, 0 );

Right? That call to recv will block until the entire buffer is full. You need to design your protocol so that each packet''s (fixed-length) header includes the length of the data, that way to can call recv to receive the header and again to receive the data.

For example, on one end:

char mymessage[] = "Hello World!";
int length = strlen(mymessage) + 1;

send( sock, &length, sizeof(int), 0 );
send( sock, mymessage, length, 0 );

And on the client:

char itsmessage[1024];
int length;

recv( sock, &length, sizeof(int), 0 );
recv( sock, itsmessage, length, 0 );
printf( "received %d bytes: ''%s''\n", length, itsmessage );

Hope this helps!

If I had my way, I''d have all of you shot!

---

codeka.com - Just click it.

quote:

---

Original post by Dean Harding
Right? That call to recv will block until the entire buffer is full. You need to design your protocol so that each packet''s (fixed-length) header includes the length of the data, that way to can call recv to receive the header and again to receive the data.

---

I''m not sure that''s right. recv should return the number of bytes it has actuall received if not a whole buffer.

---

Helpful links:
How To Ask Questions The Smart Way | Google can help with your question | Search MSDN for help with standard C or Windows functions

quote:

---

Original post by siaspete
I''m not sure that''s right. recv should return the number of bytes it has actuall received if not a whole buffer.

---

D''oh, you''re right. Sorry.

Anyway, my point is still valid, it''s unlikely the nagle algorithm which is causing you problems since it''s not meant to wait indefinatly for it''s buffer to fill up.

Anyway, the solution I provided still works...

If I had my way, I''d have all of you shot!

---

codeka.com - Just click it.

Hi guys, thanks for the many suggestions.

Yes, i think i could disable nagle algorithm with the TCP_NODELAY socket flag to force out my small packets... but i was just wondering if someone had came out with a more elegant solution, thats why i asked :-)

Dean Harding:
Thanks for ur idea. I'm actually not fixed on my header design yet.. But i'll still have to first disable nagle algorithm so that i would not be hit by the delayed-ack problem becos i'm sending out such small packets of data. My only real goal here is to ensure that all the data that i send in a send() function call gets onto the "wire" immediately instead of being held back in the buffer used by the nagle algorithm to coalase small data packets together.

siaspete:
Yeah, i think you are correct there. There is a timeout in the recv() function, so it does not necessary fills up the buffer before returning. Also, i'm using non-blocking socket(oops, i forgot to declare this), so all the functions should not block on calls at all.

Also, i'm very in-experience in advance networking technique, only gotten some experience in java/winsock network during my lazy college years. Do you guys have any advance networking resources, opensource libraries and anything i could learn from?? Please post me the links!!!! Thanks! Don't send me "Beginner-Winsock-Tutorial" links, i'd gotten a ton of those...

I'm actually learning a lot from a LGPL library called HawkNL. Its cross-platform and the implementation is quite original, but it has its shortcomings. Anyway, i need to implement a custom network library, so i can't really use an entirely external lib, thats why i need more resources to learn.

Cheers.


______________________________________________
(MSG_POST_DONE) ? InsertWittySignature() : ContinuePosting()

http://www.geocities.com/codeman_net/

[edited by - flipstar on September 26, 2002 11:30:37 AM]

I use WSAEventSelect sockets in my code. recv returns immediately, no matter how much data I ask for. send returns immediately too, and if it couldn''t send all the data when I asked, it returns the amount actually sent, and sets the socket event when it can send again.

I think event sockets are the best ones to use on Win32, as you don''t have to link your sockets code to your window, but I''ve no idea how I would translate them over to linux or whatever.

---

Helpful links:
How To Ask Questions The Smart Way | Google can help with your question | Search MSDN for help with standard C or Windows functions

WSA*** functions won''t do for me. I can only use general BSD socket functions with a view to port the network engine in the future.

______________________________________________
(MSG_POST_DONE) ? InsertWittySignature() : ContinuePosting()

http://www.geocities.com/codeman_net/

you could set the socket to non-blocking mode. that way, it would always return immediately with whatever data was there (or return an error if nothing is there).

by default sockets are in blocking mode, so calls to recv() will block indefinitely until *at least* one byte is received.

another alternative is to use timeouts, but in my experience they are not very accurate and i wouldn''t recomend using them for something like an fps.

I know about non-blocking sockets, but is there a way to not have to poll those sockets for data? One of the reasons I use event-based ones is so I can spend CPU time elsewhere instead of checking the sockets all the time.

---

Helpful links:
How To Ask Questions The Smart Way | Google can help with your question | Search MSDN for help with standard C or Windows functions