If i have two systems (A and B) running on LAN(INTRANET) which are directly connected. There are no routers in the middle. In this case, if system A sends a few UDP packets every few milliseconds to system B:

Is it possible that system B receives the packets in a different order?

Please note that I'm not asking whether to use TCP or UDP. I'm interested in whether the above scenario will have packets out of order - I'm aware that UDP packets are not guaranteed to arrive in order.

  • 1
    Most probably they'll arrive in order. But as Patrik says, it isn't guaranteed, so don't rely on it. – ugoren Apr 3 '13 at 10:37

Yes it is possible.

This could be hardware and driver dependent, and might be very different depending on what other types of packets are being sent over the line at the same time.

How are internal packet buffers handling the incoming send requests? You can't know. It could be using parallel buffers that fill up in odd ways. Since the spec doesn't have a guarantee, there would be no reason for the implementer to bother keeping things in sync (esp. considering the speed gains with lack of overhead).

A windows box might decide to send a NTP time update request and a network share scan, and then while in the middle of that, dropbox could make a request for local folders. Now any data in buffers are suspect.

You could send millions of packets and not experience this issue. But it is a possibility. The chances of it happen may be small, but it will happen.

The only real way to guarantee that these aren't going to cause problems is if you are running your own OS and have explicit knowledge on how the hardware performs and have the driver source code and the UDP api's source code.


UDP packets are not guaranteed to arrive in order. You should use TCP for this.

  • 14
    They aren't even guaranteed to arrive. – Jörg W Mittag Apr 3 '13 at 10:40
  • there is however a maximum delay on when they arrive – ratchet freak Apr 3 '13 at 11:17
  • @ratchetfreak True, so in some scenarios using sleep based on the worst or at least average arrival time of the packets to the target system can provide a reliable way of sequentially receiving the packets. – rbaleksandar Nov 20 '17 at 8:54

They don't have to arrive at all nor in order.

I assume you're hoping that this is not the case due to the simplicity of the setup but there is still an underlying bus system and things like both computers trying to send at the same time can happen.

Of course it won't with switched ethernet but you will have to destroy several layers of abstraction to answer your question in any other way than "maybe not".


Yes, it might be that the application on system B receives the UDP packets in a different order than they were sent by the application on system A. If both systems are connected to the same network segment, the likelihood of it occurring is small, but will never be negligible.

What also can happen is that packets get lost, for example because there was a collision between two packets on a switch or hub connecting the systems.


It is possible. I have observed such behaviour on direct connection (no hub or switch) between two machines. In my case it happened only when application sent datagrams one after another without any delay between them. In this case it would happen with high probability (over 1/30). I should note that this behaviour was hardware dependent - It would occur only on one particular line of Kontron's computers. Also it would occur only when application went datagrams as fast as possible - after artifially delaying next datagram for 1 millisecond I could not observe this any longer.


In the software world, we deal with certainties and statistically impossible scenarios before deciding to use a given solution. Whether the packets can/will arrive reliably and what you plan on doing to handle that contingency, has everything to do with whether or not you should use that solution.

Anyways, no they will not arrive in order (or at all) and if you use it, you have to deal with it in your transport layer(s)--like the way RTP does it or something of that nature.


Though order or arrival is not guarranted by the specification, in your context I see no device that could reorder the packets or destroy them (provided that no other network traffic is present).

Just in case, you can build up a test that you run during a couple of hours and that sends packets with an incrementing sequence number in the body and that fails as soon as the sequence number of a received packet does not match the number of packets received so far.

  • 2
    -1. The question was not "Is it likely?" The question was "Is it possible?" To paraphrase Dijkstra in this context, testing can only be used to show that packets CAN be dropped or arrive out of order, not that they will NEVER be dropped and NEVER arrive out of order. – John R. Strohm Apr 3 '13 at 15:06
  • @JohnR.Strohm - What in the OP's case makes out of order packets possible? Anyway, testing is the most widely used technique to gain trust in software. Any theory vanishes in front of facts. – mouviciel Apr 3 '13 at 15:25
  • 1
    Read all of the other answers, that talk about buffering strategies. Imagine for a moment that system A's protocol stack implements Shortest Packet First scheduling, rather than First Come First Served scheduling. Imagine that the test process emits a very long packet, followed by a very short one. If something causes the long packet not to be transmitted immediately, then A's stack will see the short packet as well, and will, in accordance with its scheduling policy, send it first, and hold the long packet. B will the receive the packets in reverse order. – John R. Strohm Apr 3 '13 at 18:04
  • 1
    @JohnR.Strohm - Actually, your comment is a better answer than some others and I would be glad to upvote it. – mouviciel Apr 3 '13 at 18:43

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