3 ms·
> UDP reassembling fragments looks a whole lot like TCP There is only a tiny bit of similarity in that they are both dealing with reassembling a higher layer p
by cbsmith 11y ago
> UDP reassembling fragments looks a whole lot like TCP
There is only a tiny bit of similarity in that they are both dealing with reassembling a higher layer protocol payload from fragments split up over IP.
Let's count the ways they are different:
1. UDP does provide ordering guarantees within a UDP packet. It provides no ordering guarantees between UDP packets. Consequently, the protocol never has to worry about ordering more than 2^16 bytes of IP data (that makes the sorting algo really simple and efficient).
2. UDP doesn't have to deal with complex stalls or partial delivery of data. Either it has all the IP packets for a given UDP packet (in which case, it immediately delivers the UDP packet), or it doesn't (in which case it doesn't deliver it). If there is a UDP packet is missing a fragment, but a subsequent UDP packet is fully assembled, that one gets delivered.
3. There is no retransmission. UDP doesn't retransmit. It doesn't even guarantee deduplication. It is entirely possible that fragmented packets going different routes can end up creating an echo of multiple copies of a UDP packet being transmitted to the recipient.
The above makes UDP far simpler, and the contract application layers operate under very, very different. If you look at your typical TCP stack's logic for reassembling fragments, you'll find it far, far more complex than for UDP.
- ars 11y ago> UDP doesn't have to deal with complex stalls or partial delivery of data. Are you sure? If some fragments show up and some not, doesn't it have to wait and see if the rest show up? Maybe it doesn't have to wait for a long time (like TCP), but it does have to wait. Both point 1 and point 2 are a matter of quantity vs TCP, rather than quality. i.e. UDP+fragments is a sort of TCP-lite.
- jacquesm 11y agoThere is a reassembly time-out (typically 15 seconds). $ cat /proc/sys/net/ipv4/ipfrag_time 30 (on this machine apparently 30 seconds)
- cbsmith 11y ago> If some fragments show up and some not, doesn't it have to wait and see if the rest show up? Maybe it doesn't have to wait for a long time (like TCP), but it does have to wait. Much of the stall logic is tied in to whether to wait longer, whether to deliver partial data, whether to request a retransmit, whether you've already transmitted the data (once you reassemble a UDP packet, you can fire it and then promptly forget you ever saw it.. if defragmentation causes you to reconstruct and send the packet again, that's 100% okay!) and most importantly, what to do with an open ended amount of data that may need to be held up while waiting for that one lost fragment. The logic is simple: 1) Allocate space for UDP packet. 2) Fill in UDP fragment data as it arrives. 3) If all the data for a given packet is there, transmit it and delete all memory of the fragment. 4) If you timeout, delete all memory of the fragment. That is so, so, so much easier. If you looked at the code, you'd not think it much similar.
- cbsmith 11y agoTo clarify, first paragraph is talking about TCP stall logic. The rest is talking about UDP logic.