0

Requirements (Can not be modified)

I have a windows forms application. When this application runs, it listen to a UDP port.

Users can loggin to windows and open the same application and run it, and then switch windows user without logging out and open the same application and run it.

Problem

The two applications are listening to the same port by using 

SocketOptionName.ReuseAddress

as shown in this thread. But only one can get the data.

Question

There is some way so that the application of another user can read the data?. otherwise, can I listen somehow an event that notifies me about the windows user switch?

Edit

Here is the code used for setting up the listener

IPEndPoint localEndPoint = new IPEndPoint(localAddress, listenPort);
UdpClient udpListener = new UdpClient();
udpListener.ExclusiveAddressUse = false;
udpListener.Client.SetSocketOption(SocketOptionLevel.Socket,SocketOptionName.ReuseAddress, true);

udpListener.Client.Bind(localEndPoint);
IPEndPoint ep = new IPEndPoint(IPAddress.Any, 0);
byte[] answer = udpListener.Receive(ref ep);
Community
  • 1
  • 1
Oscar Castiblanco
  • 1,626
  • 14
  • 31
  • Why not just have them bind on different ports? Whatever they're talking to should send replies to whatever port sent them the datagrams, so the application should work regardless. – David Schwartz Feb 06 '13 at 12:31
  • It is a requirement and can not be modified. I posted the question to discuss a possible solution, not the requrements Sorry. – Oscar Castiblanco Feb 06 '13 at 12:38
  • You listed it under `Problem`, not `Requirements`. I'm not suggesting you change the requirements, I'm suggesting you fix the problem. If the application doesn't try to bind to a specific port and simply takes an available one, there will be no issue. (Is this a broadcast/multicast application?) – David Schwartz Feb 06 '13 at 12:40
  • Yes but I am listening at the port. If for each windows user i create a new port, I will have to go to the client and register the ports for each of the users so that he can send the messages. This is not possible. – Oscar Castiblanco Feb 06 '13 at 12:44
  • You don't have to register anything to send messages. Just send them to the server. The server should send its replies to whatever IP and port sent it the messages. Only one end needs a well-known port. If you really do want the very same datagram to be received by more than one socket, you need broadcast or multicast. – David Schwartz Feb 06 '13 at 12:49
  • But I don't want to send messages. I just listen to messages. The application never starts the communication, it only listens for data and print it, that is all, not even a response is needed. – Oscar Castiblanco Feb 06 '13 at 12:58
  • Ahh, so then you need to use broadcast or multicast. You need the very same datagram to go to more than one socket. – David Schwartz Feb 06 '13 at 13:00
  • Actually broadcast or multicast is something regarding the sender. I just receive so I receive data from IPAddress.Any – Oscar Castiblanco Feb 06 '13 at 13:04
  • You have a sender that just sends datagrams to a fixed IP and port over which you have no control? Then you'll need to go to a multiplexer design where a multiplexer you control listens for those datagrams and does the right thing with them. See my answer. – David Schwartz Feb 06 '13 at 13:07

1 Answers1

1

One option is to switch to a broadcast/multicast design. This is the only direct way to allow the very same datagram to go to more than one socket.

Alternatively, go to a master/client design. Try to bind to the port. If you can, great, you're the master. If you fail, see if there's a master and connect to it.

Pick a second port for the master to use to communicate with clients. Follow this logic.

  1. Try to open the port. If you succeed, you are the master. Also listen on the master port.

  2. If you fail, open a random port. Send a "register client" datagram to the master.

  3. The master must listen for "register client" datagrams on the master/client port. If it receives one, it should add the source IP and port to its list of clients. It must repeat all datagrams it receives on the main port to each of its clients.

  4. Non-masters should repeat "register client" datagrams at a defined interval. The master should drop any client that hasn't sent a "register client" datagram in sufficiently long, say twice the defined interval.

One ugly bit -- if the master might quit, some client will have to promote itself to master. You may just want to go with a dedicated master if you can run it on the machine.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
  • It is an interesting solution, but as you said it would require a dedicated master. I still have the possibility of listening for a windows event that tells me if the active user was changed. I will have to compare the solutions, but thanks :D – Oscar Castiblanco Feb 06 '13 at 13:25