UDP network layer must-haves?

Started by
26 comments, last by hplus0603 10 years, 7 months ago

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.

--------------------------------------------[size="1"]Ratings are Opinion, not Fact
Advertisement

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?

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).

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.
enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement