3 ms·
> 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
by 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.