Jump to content
  • Advertisement
Sign in to follow this  
Bow_vernon

When will the send buffer be full??

This topic is 2778 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hi I just want to know in what occasion the send buffer be full. anyone ever experienced this?? and what action should be taken accordingly?? do I wait(for some time)and keep sending or return immediately and show error message?? and then what? close connection? exit the app?

Share this post


Link to post
Share on other sites
Advertisement
Are you referring to the socket send() function?


By default it will block. For most uses of sockets blocking is the best behavior.

If it doesn't block, it will buffer whatever it can and return that length.

The send() function returns -1 on error, or the number of bytes sent (which may be less than those you specified).


All this and more (such as the error codes and conditions) can be found in your API/SDK documentation.

Share this post


Link to post
Share on other sites
The semantics of send() is that, if it can transfer at least one byte into the buffer, it will transfer as much as possible, and then return (possibly not transferring everything). If the buffer is entirely full, send() will block until it can transfer at least something, unless the socket is in non-blocking mode, in which case it will return a WOULDBLOCK error.

select() ties into this, by returning a socket as writable if there is at least some space for send() to write into.

The default buffer for a socket that you just opened is dependent on your OS. Perhaps 16 kB, or thereabouts. You can change it by calling ioctl() / ioctlsocket(). For TCP, you want to do this before you call connect() (or listen()), so that TCP window scaling can be calculated.

Generally, I have an application-level buffer, where outgoing packets are queued. When select() then says there is space to write, I send whatever I can from the queue. If the queue is ever greater than X, where I determine X based on the application's needs, then I draw the conclusion that the client is hopelessly slow or behind, and close the socket/disconnect the client. I do this so that I don't have to call send() from within application code; rather, just link the packet into an application-layer queue.

Share this post


Link to post
Share on other sites
ok, so what cause this is a heavy packet loss?? from what I know, pakets are kept by TCP until it gets acked. if not, it will resend until it gets one.
is that right?? hmm and the buffer is supplied per socket. thx for the info hplus n frob, btw 16kb is a lot of buffer(for games)isnt it??

Share this post


Link to post
Share on other sites
16 kB is way too much, or way too little, or just the right amount, depending on what your application needs. Hence, it's a good idea to tweak it to what your application actually expects.

Backing up and filling the send buffer can happen in many ways. Packet loss is one. Lack of bandwidth is another. Slow receiving on the other end, so the receive buffer fills up is a third.

Share this post


Link to post
Share on other sites
well those 3 factors are tightly correlated! ok thx hplus 4 the info. by the way the default buffer size is 8k. well I guess I'll just disconnect those failed in send(). pretty simple, anyway, does the Nagle affect it too??

Share this post


Link to post
Share on other sites
Nagle will try to coalesce writes less than the size of an MTU. The MTU is typically in the 1.5 kB range; as soon as you fill one MTU, Nagle will not delay any data, so it shouldn't affect the backing-up of the buffer.

Of course, if you try to send large packets (many packets of size 1k, or a single packet greater than 8k) you will end up immediately blocking. Hence, why you should tweak the default buffer size to match whatever your application really needs.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!