Re^4: How to answer a UDP broadcast

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.

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]