Fragmented UDP packets?
Author
I'm slightly concerned about one thing, apart from my lack of internet knowledge [grin]
I could be mistaken, but I've read that it is possible that a packet you send, even if below the MTU, might be fragmented, and sent into parts? Is that true?
Then I can see a whole messy problem coming my way.
1) Can packet, below the MTU limit, be fragmented by some kernel whim?
2) What happen if the recipient receives a packet that is too big to handle? I would think input buffers are much bigger than transmitted data (1.4k, while buffer about 10k?).
3) In case of out-of-order? Is it actually posible to re-order packets? How do you know the order the chunks are in the first place?
4) If a chunk is missing, What would happen? Is it wise to wait for the missing bit? Wouldn't that defeat teh point of UDP?
5) Now, I can understand if a packet you try to send is actually bigger than the MTU. Then it's my job to split it into smaller chunks, and deal with ordering / packet loss, but this MTU business is kinda worrying.
Also, the MTU dependent on the ISP and routing, although I don;t think a packet would be fragmented beyond that point (the packet would simply be dropped, I assume), and assuming MTUs (how do you know the MTU in the first place?) would be bad. I want to be able to bundle messages into packets of an ideal size (slightly below an MTU, usually 1400 bytes), while at the same time, avoid unexpected fragmentation totally.
Thanks for your enlightments.
EDIT : That's all about UDP. TCP is straight forward in itself.
I think the lowest packet size thats guaranteed not to be fragmented is 576 bytes. It is possible that a 1400 byte packet will get fragmented depending on the routing and the MTU's of the devices along a given route.
To be honest, im not sure what happens in the event a packet gets fragmented, and the destination only receives one fragment of the packet. I'm pretty sure this is an IP layer thing and is handled there. It has to either put the packet back together, or drop what its recieved if after some timeout it doesnt get the rest, but I dont know.
I'm sure hplus will chime in with some good info. =)
-=[ Megahertz ]=-
To be honest, im not sure what happens in the event a packet gets fragmented, and the destination only receives one fragment of the packet. I'm pretty sure this is an IP layer thing and is handled there. It has to either put the packet back together, or drop what its recieved if after some timeout it doesnt get the rest, but I dont know.
I'm sure hplus will chime in with some good info. =)
-=[ Megahertz ]=-
Lotsa questions there... lets see what I can answer. I'm not sure how much about networking you know, so just to touch up on the basics, a network can be divided into 7 layers (refered to as the OSI seven layers model): physical layer (electromagnetic waves on the wire or through the air, etc.), data link layer (e.g. Ethernet), network layer (e.g. IP), transport layer (e.g. TCP or UDP), session layer, representation layer, and application layer. Typically when talking about the Internet, session, representation, and application layer are all lumped together as application layer.
1) Yes, packets will be fragmented at the network layer (IP), but this is something you do not have to worry about since the network layer will reassemble the fragments before passing them back up to the transport layer (UDP). UDP garentees preserved message boundaries, so you never have to worry about only receiving a packet fragment :~).
2) This depends on the layer that you're talking about. If you're talking about receiving data from the transport layer, typically the API call will fail if the receiving buffer is too small. At the data link layer, the packet is divided into frames. IP is set up so that each IP fragment fits into a frame. If the IP layer receives too much data, I think the packet will be dropped. There is also a maximum limit that is possible to fit into an IP packet, but it is a number large enough that it shouldn't pose a problem. Just don't try to send a 100MB packet or anything ;~).
3) TCP performs packet reordering. If you want the details about how TCP works, there are plenty of resources online. If you want packet reordering with UDP... uhh... use TCP? Since UDP is an "unreliable" transport, you'll end up having to reinvent TCP to reorder your packets properly.
4) If you lose a datagram (UDP packet), you lose it. Gone. And you'll probably never know you missed it. If an IP fragment gets lost, the packet never gets passed up to the transport layer. If a frame gets lost at the data link layer, the fragment never gets to the IP layer, and the packet gets dropped. Again, if you need to make sure you get every datagram, use TCP.
5) Unless you're writing a network stack, your job is to send datagrams and receive datagrams. Full packets. No reordering, no splitting, no worries. send() and recv() and let the rest of the layers handle all the hard work for you.
Hope that helps
1) Yes, packets will be fragmented at the network layer (IP), but this is something you do not have to worry about since the network layer will reassemble the fragments before passing them back up to the transport layer (UDP). UDP garentees preserved message boundaries, so you never have to worry about only receiving a packet fragment :~).
2) This depends on the layer that you're talking about. If you're talking about receiving data from the transport layer, typically the API call will fail if the receiving buffer is too small. At the data link layer, the packet is divided into frames. IP is set up so that each IP fragment fits into a frame. If the IP layer receives too much data, I think the packet will be dropped. There is also a maximum limit that is possible to fit into an IP packet, but it is a number large enough that it shouldn't pose a problem. Just don't try to send a 100MB packet or anything ;~).
3) TCP performs packet reordering. If you want the details about how TCP works, there are plenty of resources online. If you want packet reordering with UDP... uhh... use TCP? Since UDP is an "unreliable" transport, you'll end up having to reinvent TCP to reorder your packets properly.
4) If you lose a datagram (UDP packet), you lose it. Gone. And you'll probably never know you missed it. If an IP fragment gets lost, the packet never gets passed up to the transport layer. If a frame gets lost at the data link layer, the fragment never gets to the IP layer, and the packet gets dropped. Again, if you need to make sure you get every datagram, use TCP.
5) Unless you're writing a network stack, your job is to send datagrams and receive datagrams. Full packets. No reordering, no splitting, no worries. send() and recv() and let the rest of the layers handle all the hard work for you.
Hope that helps
576 bytes for UDP no fragment: RFC 791 (1981).
If your application does not need larger UDP packet sizes, use 576 or less and you won't have to worry about router fragmentation issues. My main WinXP box uses 1472 for the MTU: larger packets don't cause a major issue other than reduced efficiency due to fragmentation (this would be bad for a dial-up connection). I used 768 bytes for a shipped (world wide markets) game and there were no problems (one market had routers with fragmentation issues for packets over 1000).
At the app level you don't have to worry about UDP packet fragmentation (send or receive): on send, if you exceed the OS MTU, the packets will be automatically fragmented. During receive, UDP packets will get dropped if there is a problem (timeout/checksum error, etc.): you'll never see a partial UDP packet (you may see a corrupted one, though (correct length but damaged payload (passed simple checksum test))).
If your application does not need larger UDP packet sizes, use 576 or less and you won't have to worry about router fragmentation issues. My main WinXP box uses 1472 for the MTU: larger packets don't cause a major issue other than reduced efficiency due to fragmentation (this would be bad for a dial-up connection). I used 768 bytes for a shipped (world wide markets) game and there were no problems (one market had routers with fragmentation issues for packets over 1000).
At the app level you don't have to worry about UDP packet fragmentation (send or receive): on send, if you exceed the OS MTU, the packets will be automatically fragmented. During receive, UDP packets will get dropped if there is a problem (timeout/checksum error, etc.): you'll never see a partial UDP packet (you may see a corrupted one, though (correct length but damaged payload (passed simple checksum test))).
Author
awesome. That answered everything. So all the UDP fragmenting is transparent and at the IP layer, which is good to know. For TCP, I can deal with that, since it's guaranteed in order, that's easy. just fill up the buffer.
I asked that because in Beej's tutorial, he is talking about packets being fragmented, and having to queue the data (both sending and receiving). That was for TCP, so I wondered what would hapen for UDP. But I guess, I don't have to worry. For the MTU, I'll work something out. I know the normal router size of 1482, but I guess it has to be a bit more flexible.
Ace, I'm using UDP because I want to do a net protocol similar to Quake3, which can live with packet loss and other issues inherent to UDP. But if I had to worry about fragmentation, that would thorws quite a major wobbly. TCP is too slow (too much latency waiting for stuff to arrive) for high fps games (sending entity updates every 20th of a second, so lots of traffic). TCP is fine for events (point and click, and so on). For high fps updates, it's not :)
thanks all.
I asked that because in Beej's tutorial, he is talking about packets being fragmented, and having to queue the data (both sending and receiving). That was for TCP, so I wondered what would hapen for UDP. But I guess, I don't have to worry. For the MTU, I'll work something out. I know the normal router size of 1482, but I guess it has to be a bit more flexible.
Ace, I'm using UDP because I want to do a net protocol similar to Quake3, which can live with packet loss and other issues inherent to UDP. But if I had to worry about fragmentation, that would thorws quite a major wobbly. TCP is too slow (too much latency waiting for stuff to arrive) for high fps games (sending entity updates every 20th of a second, so lots of traffic). TCP is fine for events (point and click, and so on). For high fps updates, it's not :)
thanks all.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement