1

I have been reading up on UDP connections and understand that UDP transmissions are "Best Effort", maybe your data will be received, maybe it won't, and if it is, it could be out of order. What I'm struggling to find information on is, what happens if the data you are sending via UDP is large enough that it must be sent via multiple packets? For example say I have a byte stream that is sent via 3 packets:

<--data_packet_1 <--data_packet_2 <--data_packet_3

On TCP those packets are gaurenteed to be delivered and in the same order they were sent. However this is not the case in UDP. So if something happens and only two packets out of the three get sent:

<-- data_packet_1 <--data_packet_3

Is the entire byte stream which is composed of three separate packets dropped? Or will they come through and need to be handled at the application layer (ie, if byte stream does not contain required format, disregard).

  • Which application layer protocol are you talking about? – Jörg W Mittag Mar 8 '18 at 19:20
  • If TCP is doing that sending of the data via UDP, it will add headers so it can detect missing packets. When it detects a missing packet, it will request the packet to be resent, and when received, present them in the proper order to its client. These things are facilitated by the connection that TCP makes with the other end. – Erik Eidt Mar 8 '18 at 19:22
  • 4
    "I have been reading up on UDP connections" – There is no such thing as a "UDP connection". UDP is a connectionless protocol, that is pretty much its reason for existing in the first place. – Jörg W Mittag Mar 8 '18 at 19:23
  • Apologies, I know very little about what I'm talking about (as you've noticed). Should I be using the term datagram instead of packet? – nullReference Mar 8 '18 at 19:31
  • Re, "On TCP...packets are guaranteed to be delivered...in order." Actually, no. They're not. TCP delivers bytes in order. TCP packets can arrive out of order at the receiving end for exactly the same reasons that UDP packets arrive out of order. The difference is, the receiving host's TCP stack is responsible for assembling the bytes contained within those packets in the correct order, and delivering those bytes to the application as a continuous stream. In UDP, assembling the data into the correct order is the application's responsibility. – Solomon Slow Mar 8 '18 at 21:52
6

I have been reading up on UDP connections

There is no such thing as a "UDP connection". UDP is a connectionless protocol, that is pretty much its reason for existing in the first place.

So if something happens and only two packets out of the three get sent:

How do you even know that? There are no sequence numbers in UDP, every datagram stands on its own. There is no way to know that there even were supposed to be three datagrams in the first place. From the point of view of the receiver, it received two datagrams. Period.

The whole reason why UDP was invented in the first place is that there are applications where you cannot afford to wait until you get "correct" data and where you can afford to proceed with incomplete data. UDP was originally created for telephony applications, where it is more important that latency is low than it is for every sample to be correct. People are used to dropouts, clicks, and crackles from analogue telephones, what they are not used to and will not accept is waiting a second for a damaged packet to be re-transmitted.

Typically, in such an application, the higher-level application protocol will use some kind of a sequence number or timestamp, so that it can detect lost (or out-of order, which in such an application is the same thing as lost) datagrams and just insert a millisecond of silence (in an audio stream) or a blank line (in a video stream) instead. If it is a bulk-data based protocol instead of a streaming one, it might re-integrate the data from "late" datagrams into its data model instead of treating them as lost. If the application cannot live with an incomplete data model, it might request the data again. But that is an application-level decision, it has nothing to do with UDP.

For video and audio streams, for example, there is a specification by SMPTE, the professional organization for broadcast video and audio, called SMPTE 2022-7 Seamless Protection Switching, which (simplified) specifies how to send the same video / audio stream data at the same time across multiple streams, and how the receiver can reconstruct the original stream out of those multiple identical streams. Broadly speaking, the datagrams are time-stamped and the receiver takes the first datagram from whichever stream that has the correct timestamp. (It is much more complex than that in reality, of course.) It is a way of improving reliability by using network redundancy instead of re-transmission. In other words, you waste half the bandwidth, but you gain reliability and get to keep low latency and jitter. (In a real-world application, you would arrange it such that the different streams are sent by different network ports at the transmitter and received by different network ports at the receiver, taking different routes through the network and being transmitted through different switches and different cables, etc. to get maximum redundancy.)

  • This really helped clear some things up for me. Greatly appreciated! – nullReference Mar 8 '18 at 20:04
1

The application layer needs to be able to handle out of order packets or missing packets. But in UDP (at least in the implementations that I've worked with), you don't tend to treat it as a byte stream. It's more of a single message or payload. It's up to the application to open the payload and do stuff with it, which may be putting it aside and matching it up with other payloads from the same data set or discarding data that is irrelevant.

  • Would there ever be an instance where only part of a payload would be received? For example if I send "Hello World" via UDP to a server, could it ever occur that only "Hello W" would be recieved? Or would it be all or nothing? – nullReference Mar 8 '18 at 19:33
  • @nullReference It depends. That's a small enough message to fit into a single UDP datagram. A datagram as a whole is either received or not received. However, if you split that into multiple datagrams, then it may come out of order or be incomplete. – Thomas Owens Mar 8 '18 at 19:43
  • That depends on what you mean by "payload". UDP datagrams contain a length and a checksum, so if a UDP datagram became corrupted, you could detect it. However, even writing and checking the checksum may be too slow for some applications (in order to write the checksum, you have to know the entire content, but the checksum is in the header, so you cannot start sending the content and add the checksum later, likewise, you cannot check the checksum until you have received the whole datagram). For that reason, UDP-lite exists, which allows to forego the checksum and even the length. – Jörg W Mittag Mar 8 '18 at 19:45
  • 2
    In UDP, a truncated datagram would be discarded by the UDP stack before it even reaches the application. In UDP-lite, a truncated datagram would be passed to the application to deal with as it pleases. Modern audio and video codecs have sophisticated ways to conceal bad data, it is much better for them to receive part of a datagram or a datagram with a couple of corrupt bits than lose the entire datagram (several thousand bits worth of data). – Jörg W Mittag Mar 8 '18 at 19:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.