Client-Server Discovery Service on localhost

1k Views Asked by At

I have an application that I want to extend to always be publishing data out to a socket so that when key events happen to any custom application that wants to listen for the packets can process them.

My inclination is to send packets over UDP on localhost from the server to all known clients which would involve the clients sending messages to a known server address such as 127.0.0.1:12345, subscribing using their own address 127.0.0.1:54321, and the server then sends out a copy of the packet to each active subscriber every time an event happens.

I see a few problems that need solving here:

  1. Servers could possibly be in contention and try to bind the same "known" server port at 127.0.0.1:12345

  2. Clients need to be made aware of every available server publishing messages so that the user can select which server they are interested in listening to

  3. Server would need to periodically ask each client if they were still listening since this would be UDP

There has to be a better way! Is there any way I can write the network communications in a manner that allows clients to all share the same port(then there wouldn't need to be a client-server handshake)? What if I wanted to extend this across a LAN, how can I easily publish this information to machines interested(inclination is multicast but is that the cleanest approach, how can I make multicast work when some or all clients exist on localhost)?

1

There are 1 best solutions below

4
On

Every solution has its pros and cons so there is no better way to do it. In the end you might gain most by using a specific library for inter-application messaging like ZeroMQ or RabbitMQ instead trying to reinvent the wheel by writing your own code to implement subscriber/publisher and multicasting patterns

EDIT: To answer your questions just in case you decide to reinvent the wheel:

1) There is no other way than having a single server per unique {Protocol, IP, Port} tuple. Either allow one server to wear several hats or have one port per server.

2) You will need a server registry for this to work. An alternative can be a broadcast message that user sends requesting servers to identify themselves.

3) Yes - you would need a keepalive to know if the user is still there. Alternatively, user can periodically contact the server to say that I am still here.