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).
Best Answer
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.
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.)