[RESOLVED] Multiple UDP Recievers?

My Problem:
I'm using a Socket (SocketType DGram, ProtocolType UDP, Bind to a LocalIP and LocalPort) to recieve messages from a broadcast. The code used was provided by Shaggy Hiker
This is working as planned, however the amount of messages sent on that broadcast con be huge (my benchmark 4K+ messages every 4 seconds) and I have no control over that.

My Question:
Is it possible to have more then one Socket on that port in order to accept messages on a secondary socket when the first is actually blocked?

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.

Thanks for the insigths, I'm just trying anything to get more speed. So I can drop that attempt.

As for UDP, being unreliable. Yes, to loss of messages is no problem, the problem is the huge number that is coming in.

However I migth be checking on the wrong spot. I do the benchmarking just on my single system, using another application to produce those message and send them onto the port I'm listening to. Since its on the same system te messages could be coming in faster then over a real network.

Yeah, they might. If possible, try testing on a system with two different computers sending. 1000 messages/sec would mean the processing has to be 1ms per message at a minimum, which doesn't seem impossible. However, on a noisy system, the actual throughput may be significantly lower.

It's an interesting question, though. I don't even have a sytem I could test it on, realistically.

Thanks for the feedback. I'm closing this one.

Quote:

---

Originally Posted by Shaggy Hiker

... 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 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.
...

---

I don't believe either of those statements is true.
If you have an application listening to a given UDP port, e.g. 3000, if a second application tries to bind to the same port it will fail.
There is a socket option (which I've read Winsock doesn't support), to allow multiple listeners on the same port, but when you do that, which application gets a particular message appears to be random. You might expect intuitively, that all the applications bound to the port would get a copy of the message, but a single UDP packet is only delivered to one of the listeners, not all of them, and I don't know if there is a scheme to how a given listener is selected for a given packet. You would think if all applications don't get a copy, then perhaps it would "round-robin" the distribution to evenly spread the packets among the listeners, but that didn't seem to be the case when I wanted to do stuff along these lines seven years ago.

p.s. On further reading, it does seem the SO_REUSEADDR is now functional on winsocks, and Shaggy Hiker's code is setting that option, so all applications using Shaggy Hiker's class should be able to connect to the same port, but if the Remote Host/Port is not unique, I think there may still be the issue of how the messages are distributed. I guess I would have to test it again, to see how it behaves these days. A lot of my network connections are between a mix of Linux and Windows based operating systems, and it is possible there is a difference it how the packets are handled.

As Shaggy stated the used listener is as lean as possible. After some more digging I found that the listener is NOT the believed bottleneck, it's the next step i.e. the parsing of the messages.
I need to put that into an own thread, however the start of such a thread for each message-recieved is not the best solution. I would need a "thread" already waiting for event/call/whatever, but that will be another question/thread.

@Passel: I didn't work that out, there is a thread over in the Networking section about that. I needed to have multiple apps communicating over UDP on a port, even if the two ends of the communication happened to be on the same physical box (there were several apps, some on different systems, some on the same). Aside from that, I haven't worked with this for a couple years, now, and my memory on it all is a bit fuzzy. It was working, though, with multiple apps listening at the same port on the same machine. Not exactly the default situation.