UDP: Confusion with Packet and Messages

[zak100]

Hi,
I know that UDP does not preserve ordering. This means two messages sent maybe received in order different to the sending order. But how a message preserves order within itself. If it breaks the message into packets how these packets unite to form a message similar to the message sent. Or the message is not broken into packets?? Is one packet equal to one message in UDP??

Some body please guide me.

Zulfi.

 

[Jonathan Scott]

In UDP, each packet is an independent "datagram" which is equivalent to a self-contained message.

 

[Jonathan Scott]

To handle messages which require multiple packets, the normal solution is to use the TCP protocol, in which packets are numbered to ensure that they can be reassembled into the original sequence.

 

[zak100]

Okay thanks. This means in UDP we do not break the message as each message is same as a packet.

Zulfi.

 

[Routaran]

UDP is usually only used when the order of the data received at the other end is not very critical, a common use is audio/video streams. UDP is faster because it has less overhead and if you were to miss a few packets every now and then, it wouldn't matter because you won't notice the missing data within the stream. Think of it like missing one frame in a 30 frames per second video. You won't even realize it was missing.

For data transfers like documents and other files, the order and integrity of the data matters so we do not use UDP. Here TCP will be used because it is able to track if any packet fails to reach the destination.

That said, there's nothing inherently preventing you from using UDP to transfer files. a 10mb file will be broken up into several pieces and then send to the destination and then put back together. Networks now are generally very reliable and you might be able to get away with this but its not recommended. If a router in between you and the destination decides to send some packets on a different path, then the order at which they arrive will be messed up and the destination system may not be able to reassemble the file. But I suspect you can get away with this on a local network under most normal circumstances because there's only 1 path and packets will arrive in sequence.

 

[jbriggs444]

Okay thanks. This means in UDP we do not break the message as each message is same as a packet.

Pardon the late response.

A large UDP packet can be fragmented for transmission. This would typically be done by the sender based on the IP MTU (maximum transmission unit) on its egress interface. The result is a series of IP packets, each containing a fragment of the original.

Elsewhere in the IP network between sender and receiver, routers may find themselves unable to forward the resulting IP packets due to their own MTU limitations. If so, the fragments may themselves be fragmented. [Google is a rich source for discussion of the resulting issues, mostly in the context of TCP, the path MTU discovery algorithm, its failure modes and the mitigation thereof].

It is normally the responsibility of the final receiver's TCP stack to accept all of the resulting fragments, buffering up the pieces until the complete original UDP packet has been re-assembled and can be delivered to the receiving application.

In some cases, equipment in the data path (firewalls, load balancers and such) may need to make forwarding decisions based on the layer 4 content. Since all fragments other than the first will fail to contain the UDP port number, such devices are often called upon to do "transparent virtual reassembly", storing up all the packet pieces until the original UDP packet is present and then forwarding all the piece-parts as fragments once the forwarding decision has been made.

Now, back to the original question: How is order maintained among the IP fragments in a UDP datagram?

That is a function of the IP protocol. Each IP fragment contains a fragment offset field which defines where the fragment lives within the original IP packet.

When in doubt, go to the RFC. https://tools.ietf.org/html/rfc791 An oldie, but still a goodie.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

[jim mcnamara]

@jbriggs444 very good answer. Sounds like you are acquainted with jumbo frames on a really heterogeneous network with lots of old and new equipment. Or confused network admins...

 

[jbriggs444]

@jbriggs444 very good answer. Sounds like you are acquainted with jumbo frames on a really heterogeneous network with lots of old and new equipment. Or confused network admins...

I've dealt with a few VPNs, tunnels under tunnels, WCCP, Cisco APPNav, asymmetric routing and the associated MTU issues, yes.