Jump to content
  • Advertisement
Sign in to follow this  
AntiRush

SDLNet and sending packets (clumping)

This topic is 4157 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

I recently adopted SDLNet as a part of the small multiplayer server I'm writing. I use tcp networking and deal with many relatively small packets. I've never done any serious work with networking before and I realize that it would be very inefficient to send all of these small bits of data by themselves. This brings me to my question. With SDLNet (or any tcp implementation) do I need to clump the data on my own? That is group my discreet 'packets' together before I send them?

Share this post


Link to post
Share on other sites
Advertisement
TCP will, to some extent, re-group lots of small packets together. If you turn off Nagle's algorithm, however, it will do less of that, and start spraying small packets on the network. Thus, you have the choices of:

1) Use TCP as is. Accept the packet coalescing delay (might be around 200 milliseconds or so).
2) Turn on TCP_NODELAY (i e, turn off Nagle). No sending delay, but lots of small packets.
3) Do your own buffering of output data, and flush it at the end of each server tick, for example.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
TCP will, to some extent, re-group lots of small packets together. If you turn off Nagle's algorithm, however, it will do less of that, and start spraying small packets on the network. Thus, you have the choices of:

1) Use TCP as is. Accept the packet coalescing delay (might be around 200 milliseconds or so).
2) Turn on TCP_NODELAY (i e, turn off Nagle). No sending delay, but lots of small packets.
3) Do your own buffering of output data, and flush it at the end of each server tick, for example.


Thanks for the info. :) I'm leaning towards the third option - I'm already serializing the data and it seems like buffering would also lend itself to adding a compression algorithm. (Huffman is what I've been looking at)

This is the procedure I'm currently planning on:
Each packet that is created by the server is added to a queue. Every server tick ends by popping all the packets and adding their data to a packetbuffer. When this buffer is at the max size I want to send (or there are no more packets in the queue) a length header is added to the front and the packet is sent. (Potentially I would apply the compression before the length header is added).

Do I have any glaring mistakes here? Thanks again.

Share this post


Link to post
Share on other sites
I would send data even if the desired size hasn't yet been reached, if the oldest packet in the queue is older than X milliseconds. That way, on a connection with very little activity, you won't get very high lag.

Share this post


Link to post
Share on other sites
If you're running under Linux you could also use TCP_CORK, which might under some cases be more efficient - but it's really intended for use with sendfile() - this means that e.g. a web server can pretty much guarantee to send out some headers and a small file in a single response packet, even if it uses sendfile() to send it.

Mark

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!