-1

I ran into this a while ago and a discussion I recently had reminded me that I don't know how to solve it...
Suppose that you have a server and client communicating through UDP.
Your client listens on a UDP port X and receives the server packets.
Then a 3rd party process is started and it is also listening on the UDP port X.
Now it might read the packets meant to be received by my client and remove them from the queue and my client won't receive them at all.

Or even worse, if the clients send UDP messages to the server so it will assign them TCP ports to connect to. The server still has to connect to a constant UDP port X which the clients know, even if it's in use or else nobody will be able to connect to it.

How can I prevent it?

Idov
  • 5,006
  • 17
  • 69
  • 106
  • 1
    according to the answers here (http://stackoverflow.com/questions/1694144/can-two-applications-listen-to-the-same-port), two applications connecting to the same port is only possible if both are written in a way to allow that... – codeling Sep 14 '12 at 11:30
  • ok, fine. So let's say the clients send UDP messages to the server so it will assign them TCP ports to connect to. It still has to connect to UDP port X whether or not it's in use. it's even worse, it will cripple the server. – Idov Sep 14 '12 at 11:38
  • Either you didn't carefully read the answers in the linked question, or I don't understand your problem at all... – codeling Sep 14 '12 at 11:43
  • My server receives UDP messages from the clients. It sends them a TCP port number to connect to and using that TCP port they will communicate from now on. My server must have the ability to listen to a UDP port which somebody else is already listening to, because otherwise if somebody is already listening to that port, the server won't be able to receive the messages from the clients. Now, if another process also starts listening on that port - it might get my messages instead of me. – Idov Sep 14 '12 at 11:48
  • I didn't get from your question that your problem is with the **server** listening to a UDP port ;); but why would your server need the ability to listen to a UDP port somebody else is listening to? – codeling Sep 14 '12 at 11:58
  • not on purpose... some other process running on the same machine, listening to the same port. – Idov Sep 14 '12 at 12:01
  • somebody already listening to that port should be a problem already, because that running application then can see all your packets as well! what does it matter if such second program on the same port starts before or after your server? – codeling Sep 14 '12 at 12:02
  • it doesn't matter... So there is nothing that can be done? – Idov Sep 14 '12 at 12:07
  • it's still not clear to me at which point in time you exactly want to prevent whom from doing what. as i said preventing applications from listening to your port **after** you start your program doesn't really make sense, so if you have a proper use case please **update your question**. I won't answer in this comment thread anymore, it's far too long already as it is (which is a pretty clear indicator of how unclear the question is, also that nobody else cared to comment) – codeling Sep 14 '12 at 12:10

2 Answers2

2

All the processes that want to share the port have to set SO_REUSEADDR. If they don't, the first to bind to the port gets it and the others fail. So, (a) don't set SO_REUSEADDR, and (b) be the first to bind to the port. If you're not the first, you will get a bind error.

user207421
  • 305,947
  • 44
  • 307
  • 483
1

Only unicast UDP packets can be 'stolen', what actually happens is the IP stack will only deliver to the first bound application.

The solution is administrative: be the first application executed to bind to the required port.

Steve-o
  • 12,678
  • 2
  • 41
  • 60