   UDP optimal packet size
  I'm trying to make sure I understand everything UDP related while writing some networking code.  Correct me if I'm wrong on any of this:1) Minimum MTU: 576 bytes (including the 32 bytes of IPv4 and UDP header).2) Standard MTU: ~1500 (anything higher will most likely get fragmented).3) Once a packet is fragmented, it can only be reassembled at the destination (by some net layer before UDP).4) Optimal packet size:4a) The smaller the packet, the lower the latency, and less dropped packets.4b) The bigger the packet, the higher bandwidth more dropped packets (This doesn't make perfect sense to me, is it because of the packet header?).5) If a UDP packet is fragmented, the destination must receive all fragments or the packet will be considered dropped and not received by my app.6) If a UDP packet is received corrupt (and can not be fixed) it will be considered dropped and not received by my app.I'm networking a pretty simple top-down shooter, 1v1.  My plan is to send the ship's position/velocity/whatever and the client's timing/ping in every packet.  So each packet will have a minimum of ~60 bytes.  After that data I'll include created objects, collision msgs, and sporadic object updates.What I'm getting at is: the packet will range from 60 bytes to ~1000 bytes per update (depending on the current events of the game).  I'm planning on capping the packet size to 1000 bytes because I somewhat remember ready about some irregularities causing larger packets to get dropped in some cases.  Are there any packet sizes I should avoid for any reason?  Ignoring the security issues, is it okay if one of my messages is a zero byte packet?  I read that CS and Starcraft used standard packet sizes (~130-160 bytes) per update.  Is there any reason to not vary in packet size?   
  UDP doesn't fragment;  It just gets dropped.   ;Quote:Original post by Anonymous PosterUDP doesn't fragment;  It just gets dropped.You are anonymously wrong.http://solipsis.netofpeers.net/wiki2/index.php/UDP_FragmentationThe page goes on to say that the common max UDP packet size is 8192 and it is possible for a router to block MTU discovery, thus, UDP could be dropped instead of fragmented.  I guess I'll probably limit packet size to 576.   ;  The overhead for a UDP packet is 20 bytes for the IPv4 header, and 8 bytes for the UDP header == 28 bytes.Other than that, your original write-up seems pretty reasonable. Note that the UDP checksum algorithm is pretty naff, and you would do well to add your own CRC for your packet data to decide whether it's valid. If you do a CRC of the data plus some shared secret, perhaps using a strong hash instead of CRC, then you get quick and easy authentication out of the same algorithm!;Quote:Original post by hplus0603Note that the UDP checksum algorithm is pretty naff, and you would do well to add your own CRC for your packet data to decide whether it's valid.Serious ? I've been using UDP over the Internet for quite some time and never received any invalid or corrupted packet. What algorithm is used for the checksum ? And what's the probability for it to fail ?Y.;  The UDP checksum algorithm is just that - an actual check sum!It turns out that most links are pretty reliable, and use additional (stronger) checking (and sometimes correcting) algorithms, so the chance of getting a corrupt packet is small in reality, but it could still happen. Much more often, you'll get dropped or re-ordered packets because of router queuing.;  You also might consider if the App is across a LAN or the Internet (or other like satellite -- reply delay hell).LANs generally are more reliable (???)  so the larger packets (1500) dont cause the resends and you can make use of the lower  header/packet  overhead.One author mentioned piggybacking the data from the previous send on every packet (was unreliable UDP)  to eliminate most resend needs.Data packing to minimize the data size may also have benefits (if you find significant improvement with smaller packet sizes).   ;  just incase you dont have a packet diagram - there soo cool.http://www.sans.org/resources/tcpip.pdf   ;  msdn says this:Quote:It is generally inadvisable for a broadcast datagram to exceed the size at which fragmentation can occur, which implies that the data portion of the datagram (excluding headers) should not exceed 512 bytes.Broadcast of course, but I think im gonna limit mine to 512 anyway.;Quote:Original post by blaze02I'm networking a pretty simple top-down shooter, 1v1.  My plan is to send the ship's position/velocity/whatever and the client's timing/ping in every packet.  So each packet will have a minimum of ~60 bytes.  After that data I'll include created objects, collision msgs, and sporadic object updates.You can probably compress that down a bit, just by using standard compression methods - E.g. pack a float into 1 or 2 bytes instead of 4.   