Re^3: How to answer a UDP broadcast

Well then part of my post stands, and that is you cannot listen on a Broadcast UDP socket, you need to open another one. My advise is to add to your protocol specification a dedicated "hello" reply port and always listen to broadcast responses on that port instead of the current set up (reply on the source port).

Another alternative which gets my vote is to have a central tracking server that new servers register with and recieve back a list of all currently live servers. This tracker would also periodically have to ping the other servers to make sure that they are still functioning and handle goodbyes, but would prevent the issues that udp packetloss can cause (always use TCP for talking with this tracker, heck the 'ping' could just be a "hi/hello" going down the inital socket).

Comment on Re^3: How to answer a UDP broadcast

Replies are listed 'Best First'.
Re^4: How to answer a UDP broadcast by mje (Curate) on Jun 19, 2007 at 21:13 UTC
I think your first statement is the one that answers my problem - "you cannot listen on a broadcast UDP socket". A "central tracking server" is certainly one way to go but I was trying to avoid a single point of failure. I was not really bothered which sub-server handled the sub-requests and was even prepared to queue them to another server if the first had gone away - the unreliable udp part was only to ferret out possible sub-servers and after that I'd been using reliable tcpip and connect to guarantee the jobs were handed out and dealt with. Anyway the key point I think you are saying is "you cannot listen on a Broadcast UDP socket" - this is the overriding fault in the existing system regardless of possible better solutions. Thnaks for the pointers.	[reply]
Re^5: How to answer a UDP broadcast by Trizor (Pilgrim) on Jun 19, 2007 at 22:56 UTC
Well if you don't want a single point of failure there are other methods that you can use such as several redundant trackers. The code hits the primary one and if it finds it ok it updates it and then the tracker informs however many backups that it has been told about. If it doesn't find the primary one it fails over to another down the list and so on. Then when the primary ones come back online they get the current state from the backups. While you may not care which sub-server handles the request, you may care if your broadcast gets dropped heaing out from the machine and the new subserver is placed under the impression that it is alone.	[reply]