Sign in to follow this  

UDP network layer must-haves?

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

Submitting fewer messages at a time leaves you with complete messages. Fragmenting data at a lower level (i.e. split up "binary data" agnostically of the message structure) will likely contain partial messages that can only be received by assembling fragments.

 

Insofar, doing this at application level is arguably cleaner and "better".

Share this post


Link to post
Share on other sites


Submitting fewer messages at a time leaves you with complete messages. Fragmenting data at a lower level (i.e. split up "binary data" agnostically of the message structure) will likely contain partial messages that can only be received by assembling fragments.
Insofar, doing this at application level is arguably cleaner and "better".

 

It does have the drawback that it breaks the abstraction. So now the application has to: 1) estimate packet size - meaning it must know the details of how the serialization works, 2) query the networking layer for maximum packet size and 3) add code fragmenting and defragmenting updates at various places (been there, done that).

 

It also means that any change in the networking layer might suddenly touch a whole lot more code than just the parts directly related to networking.

 

Doesn't sound ideal.

Share this post


Link to post
Share on other sites

If you really care about MTU, google "path MTU discovery" and check the "don't fragment" flag in the IP packet header.

But also note that if you have the DF flag set, and your packet is larger than the MTU along the route to the destination... your packet will get dropped. No special effort will be made to route your packet around network segments with MTUs less than what your packet size is. Edited by Washu

Share this post


Link to post
Share on other sites

if you have the DF flag set, and your packet is larger than the MTU along the route to the destination... your packet will get dropped.

 
That is the point! You can easily use binary search to find a proper MTU to use for your entire path this way. You only need to stop on some reasonable multiple, say 128 or 64, so a few packets is all you need to get there.

Start with 2048. If it works, double it. If not, halve it. Then binary search until the difference between "works" and "doesn't work" is your search granularity size (such as 128.)

Share this post


Link to post
Share on other sites

The one I built had a special file transfer transaction mechanism (the whole 'file' data block defined to not be useabale til it recieved intact other side).     Simplified ACK retransmits by using a bit flag return msg (if any were never recieved) sent after a whole pass on all the packets needed to send the 'file'  (flagged packets only would be resent)  and this repeated if necessary til entire 'file' is intact.  packets got dumped directly into the right place in a preallocated file buffer to eliminate extra block copying.

 

 

It was a while ago, but that one also had callback signals to an Application level that could cause throttling at a high level (where the App could make smarter decisions about how to handle a  data flow slowdown into the server.   This meant of course the packet driver needed some criteria to determine when to start alerting the Application layer.

Share this post


Link to post
Share on other sites

 

if you have the DF flag set, and your packet is larger than the MTU along the route to the destination... your packet will get dropped.

 
That is the point! You can easily use binary search to find a proper MTU to use for your entire path this way. You only need to stop on some reasonable multiple, say 128 or 64, so a few packets is all you need to get there.

Start with 2048. If it works, double it. If not, halve it. Then binary search until the difference between "works" and "doesn't work" is your search granularity size (such as 128.)

 

What if the path changes?

Share this post


Link to post
Share on other sites

 

What if the path changes?

 

Then you're either using a non-optimal (too small) MTU or it will drop, depending on whether the new route has a higher or lower MTU.

 

I would still go with 1280 for simplicity, or if you really want to do a MTU discovery, do your binary search between 1280 and 1500.

 

The reason being that 1280 is guaranteed by IPv6 (and every router that isn't in a museum is IPv6 capable, so it must have at least that MTU) but on the other hand you are not likely to get more than 1500 as this is what standard ethernet delivers, and there is "always some ethernet" in between you and the other computer. Unless everyone configures their cards and routers for jumbo frames, which probably won't happen.

 

Of course a granularity of 128 is way too coarse for such a small interval, especially since that would only leave the choice between 1280 and 1408. Note that 1280 is what the "start at 2048" binary search would eventually converge to, too (2048fail --->1024work ---> 1536fail ---> 1280work).

Share this post


Link to post
Share on other sites
Actually, once you've discovered the MTU, you don't use the DF bit anymore, so if the path changes, you may end up with IP fragmentation, but it will stil hopefully work well enough.

not likely to get more than 1500 as this is what standard ethernet delivers, and there is "always some ethernet" in between you and the other computer


Gigabit Ethernet and up typically supports jumbo frames, for 9,000 bytes per packet. On the other hand, ATM transmission packets are 53 bytes; 48 payload and 5 address. You're not going to avoid physical fragmentation there -- but at least that fragmentation is done on the physical layer, and "invisible" to the IP layer.

For 99.9% of games, I would suggest not worrying about it. If you're using TCP, don't worry -- just make sure you turn on TCP_NODELAY, and make sure you group your outgoing packets into a single send() call per network tick. For UDP games, pack your messages into a single UDP datagram per network tick, and because you don't want traffic to be too large (or the server will have a significant upstream bandwidth problem,) you don't want each UDP packet per player to be bigger than 1280 bytes anyway.

Share this post


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