In multiplayer, various data needs to be sent through network. Position of objects, chat data, game logic data, player inputs etc. Is it good idea to try to first collect all data that needs to be sent in a given frame and then send them together in one UDP datagram? Or should I just send each piece of data independently? Or maybe hybrid - send data that needs to be fast as soon as possible (player positions) and collect other things togehter into one packet?
Thank you
Generally large UDP packets (say larger than 1400 bytes or so, possibly less) will not survive a trip over the public internet and will end their journey when they encounter a router that refuses to fragment them. If they do get through, they have a larger chance of being lost as any fragment being lost means the entire packet is lost.
It is best to send reasonable-sized UDP packets if you don't control the network path on which the datagrams will transit over: as big as possible (to limit IP/UDP overhead) but not too big that they will get fragmented or dropped. This is why you should try and remove as many redundancies as possible from your packets and limit any protocol overhead from your serialization method.
Generally large UDP packets (say larger than 1400 bytes or so, possibly less) will not survive a trip over the public internet
Generally large UDP packets (say larger than 1400 bytes or so, possibly less) will not survive a trip over the public internet
This is not generally true.
IPv4 will fragment and reassemble the packet if it's bigger than MTU, which will generally work fine (it may increase packet loss a small bit.)
(This is, unless you manually set the "don't fragment" bit on the packet.)
IPv6 does not have routers perform IP fragmentation, but instead lets each sending end create the fragments. Well-behaved IPv6 stacks will implement MTU discovery and do the fragmentation for you.
You should be confident that, unless you're using a really crappy network implementation, a UDP packet of any size (up to the limit of 65536 bytes) will be delivered to the other end, with a slight increase in packet loss as sizes go up.
If you run on a really crappy network implementation, IP datagrams of up to 1280 bytes will always be forwardable, which leaves 1272 bytes for your UDP payload before fragmentation is even an issue.
(Back in the days, dial-up modems had a smaller MTU of typically 576 bytes; it was recommended to keep packets below that, but larger packets still worked.)
We tried sending large UDP datagrams over ipv4 between Europe and NZ over the course of a week or so a few months ago and the packets were consistently lost (100% packet loss) when they exceeded a certain size and went through fine below that size. No special configuration was done on the network stacks. I don't exactly remember the threshold but it was around 1300-1400 bytes. Now it could have just been malfunctioning equipment (I will try and replicate it tonight to see if it's still happening) but in my experience large packets, let alone 65536-byte packets, are unreliable at best over long distances. Over short distances though I assume anything should work given a decent network infrastructure.
were consistently lost (100% packet loss) when they exceeded a certain size and went through fine below that size
Well-behaved IPv6 stacks will implement MTU discovery and do the fragmentation for you.They do that for UDP, too? Seriously? Now that comes as a surprise for me.
For a change, that's a positive surprise :D
If you run on a really crappy network implementation, IP datagrams of up to 1280 bytes will always be forwardable
[...]
dial-up modems had a smaller MTU of typically 576 bytes
I think (99% certain) that it is very slightly, but not to much of a real effect, different.
The 1280 byte number comes from the minimum allowable MTU as specified by IPv6 (and 576 is the same, just for IPv4, they somehow never increased the minimum... but I might remember wrong here, it may have been much lower in the very early days, something like 60 or 80 bytes...).
However, this means that if you are being maliciously pedantic, a device which works for both IPv4 and IPv6 (as practically all routers do) might, even though it is perfectly able to forward 1280 bytes and indeed does so in IPv6 mode, too, still drop IPv4 datagrams larger than 576. And that would be perfectly compliant.
But I think no device exists which is that much deliberately fucked-up. Or maybe, who knows.
If you run on a really crappy network implementation, IP datagrams of up to 1280 bytes will always be forwardable, which leaves 1272 bytes for your UDP payload before fragmentation is even an issue.
Sorry, where does the 1272 come from?
Also, do I need to encode the length of the data (2 bytes) or is that included in the protocol header?
