I don't believe it would even help, though I haven't fully tested that. You can have any number of UDP listeners on a port and socket on one system, though you may not be able to in one application. I used that code (or its predesessor) in multiple apps on the same computer. I just don't think that two listeners can be set up so that one gets the message when the other is busy. I think they would all get EVERY message.

On the other hand, UDP messages are called unreliable because there is no guarantee that any particular message gets through. Message collision anywhere along the line could cause any particular UDP packet to be dropped, and any UDP-based system should be tolerant of losing a few (or else you have to implement some kind of receipt acknowledgement message).

Another point that you may have already seen is that I was doing no more than stuffing the messages onto a queue in the fastest means possible (Array.Copy, in my case, as the payload was a byte array). The thread that was listening was doing nothing more than that. Other threads dequeued the data and dealt with it. That meant that the listener was blocking as little as possible. I was also using two different ports on some systems, one for upstream and a different one for downstream. That probably wasn't worth doing, and wouldn't even make sense in most cases. I just happened to have two distinct sets of messages that could be on the different ports. I had a lot of messages, but nowhere near what you are talking about.