I''m using sock_stream TCP sockets for networking in a simple LAN project. I have a problem. The sending side does not seem to "flush out" the data that i''m sending unless its >=1024Bytes. That forces me to pegged all my data to 1024bytes if i want them to be sent immediately by the send(...) function. Is there anyway to "flush out" the data??? Its really wasteful to pegged my data to 1024 when theres only 50bytes of useful data. I''m using winsock, and i''m not planning to use UDP for this project since i need the data to be ordered and reliable. Any suggestion would be appreciated, thanks! ______________________________________________ (MSG_POST_DONE) ? InsertWittySignature() : ContinuePosting() http://www.geocities.com/codeman_net/

google for ''tcp nagle algorithm'' or something, should tell _why_ tcp does that... as for getting around it, i don''t know...

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

Well, luckily you can disable the Nagle-algorithm.. Can''t remember how, but you''ll find it in any socket-related doc.

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/