I was reading about UDP and TCP. TCP is a stream-oriented, connection-oriented protocol and always delivers the segments in order to the application layer.
But UDP being connectionless, does it also always deliver the datagrams to the application layer in order?
No. While UDP does deliver packets reliably 98-99% of the time, without duplicating packets 99.9% of the time, and in-order 99.9% of the time, there is absolutely no guarantee for either of these (in fact you are expected to be prepared for all of these), and reality verifiably doesn't look 100% perfect all the time.
UDP does very little more than raw IP. Datagrams are fired and forgotten (unless the application explicitly does something extra). They make it through a router, or they don't. Eventually, they arrive at the other end, possibly in a different order -- or they don't, for known and for unknown reasons. Rarely, they're duplicated for unknown and unpredictable reasons, and the two packets may take different routes, arriving in either order, and even after later datagrams.
Normally, UPD just works, but every now and then, there's packet loss, that's an unavoidable truth. Usually this happens in bursts (so you don't randomly lose one out of a hundred packets, but you get a few thousand of them 100% reliably, and then suddenly an intermediate router gets a hiccup on a full queue, and you lose a dozen packets).
If a datagram arrives, and if its checksum is good, and if there is space remaining in the receive buffer, it is placed in the receive buffer. Otherwise it is dropped (datagrams already in the buffer remain there).
An application using UDP must be prepared to deal with any and all of this.
Each time the receiving application performs a read/receive, a complete datagram -- if there is one -- is removed from the receive buffer, and gone forever thereafter (even if you've only read half of it). Never anything more, never anything less. Applications must also be prepared to deal with this.
If you want ordering, you must put in an explicit counter of sorts, and implement it yourself. If you want reliability, you must implement it (with some sort of ACK/NACK scheme).
Conversely from TCP, UDP does not guarantee a reliable or ordered delivery of the packets.
As the RFC states:
This protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP)
Indeed, if you look at the UDP header there is nothing such as Sequence Number or Acknowledgment Number.
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| | |
| Length | Checksum |
+--------+--------+--------+--------+
Note also that using UDP does not mean that an ordered delivery of packets to the application layer cannot be achieved.
Indeed, UDP can be used in conjunction with an upper layer protocol that adds additional information, such as the sequence number.
See, e.g., RTP which is a Session layer protocol (OSI model) or Application layer (TCP/IP model).
