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).

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.

I'm not 100% clear on what you want but I've got a thought that might work. If the broadcast includes the senders address, then the recieving server could initiate a TCP connection to the broadcaster in response. The sender would then only accept the first connection and refuse the others so that if multiple servers replied you would just deny their connections.

I'm picturing 1 computer deciding it needs job A done. So it broadcasts out saying it needs a type A server. Each type A server then replys with a TCP connection. Each type A server could have a built in delay before replying, so the primary would reply immediatly and backups a random number of seconds later. In this way the client just accepts the first connection and proceeds with its needs.

You might want to consider using Net::UPnP for this task. Universal Plug and Play devices broadcast their existence and capabilities in UDP, advertising existing services (like web servers) and sending status messages. It seems exactly like what you are trying to do.

Oh, and each node broadcasts and listens on the same socket. Sorry, Trizor.

Thanks, I'll look into upnp.