Are UDP packets sent over a single socket guaranteed to be sent in order?

Question

I realize it's a bad idea to rely on the UDP protocol to provide any sort of ordering guarantees and TCP should be used instead. Please refrain from answers suggesting I use TCP.

I am debugging some legacy networking code and was wondering what are the ordering guarantees provided by the socket interface. The setup I have consists of a linux box running Debian talking to an embedded device over a direct ethernet cable. The embedded device cannot fit an entire TCP stack and even if it did, the legacy stack is too old to refactor.

Specifically, if I have a NIC configured with the default single pfifo_fast , and I am sending packets over a single socket, using a single thread, and they all have the same ToS , under these conditions, am I guaranteed that all my packets will be sent over the wire in the order I send them?

This is the behavior I observe in practice but I haven't found any standard, POSIX or otherwise that guarantees this behavior and I would like to make sure this is in fact supported behavior under the environments and assumptions I listed above.

In contrast, if I send my packets over two separate sockets I observe that they are not sent over the NIC in the same order I sent them from the application code. It's clear that the kernel is reserving the right to re-order packets sent over separate sockets, but refrains from doing so when using a single socket.

As I understand it, calling send() on a socket places the packet into the appropriate queue for the NIC synchronously. The existence of a queue suggests to me a notion of order (otherwise a list would be a more appropriate name for the data structure). Whether or not such ordering guarantees exist, I am interested in some sort of documentation or specification stating so.

Answer 1

There's no guarantee of this behavior because in the general case it would be irrelevant, as user207421 mentioned. POSIX, or even Linux for that matter, wouldn't guarantee that behavior because it necessarily constrains the implementation for an extremely uncommon case. Reordering packets for various reasons is common, and allowing Linux to do that for performance or other reasons (eg packet filtering or QoS) improves throughput.

Even if the sender did guarantee this behavior, the receiver could still experience an overfull buffer or temporary network hardware issue that would prevent the packet from being received properly, so any guarantee on the sending side would still be meaningless. You just can't rely on in-order delivery of UDP packets without a higher-level protocol on top, no matter what.

If you need in-order retrieval and retries but can't use TCP, look at QUIC for an example of how to do it. You may (or may not) want to implement the crypto portion, but the protocol layering may be helpful.