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.

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.

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.

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.