in reply to How to answer a UDP broadcast

Datagram sockets aren't two way. Are you sure you're stuck with UDP? Its not good for 2 way traffic, because to do the opposite of what you just did (sending or recieving) you need to open a new Socket. You also cannot listen on a broadcast socket.

My advise would be to use TCP unless there are multipule things that need to listen to the broadcast. TCP was meant for 2 way confirmed communication, and you will find that your life of network communication will be made much easier.

Also as a matter of style mixing confess and die and ways of checking for success (using an inline or vs assigning and then checking if it's not defined) generally makes the code more difficult to read.

Replies are listed 'Best First'.
Re^2: How to answer a UDP broadcast
by mje (Curate) on Jun 19, 2007 at 19:50 UTC
    OK, further explanation required. In actual fact there are multiple servers running and they have different purposes depending on how they started. Each server is both a server and a client. The idea behind the code is that when a server starts it broadcasts to find other servers on the localnet and locates the servers serving different purposes - some of these could be on the same machine. A server processing type A requests may decide to process it itself or pass it on to a dedicated type A server (hence each server is both a server and a client wrt to the code posted). All the code is trying to do is locate services on the localnet - the only two-way communication is to broadcast to find servers and receive their primary purpose. So there are multiple "things" that need to listen for the broadcast and respond. After the servers are located TCP/IP commns is used to queue jobs on the relevant servers i.e. the broadcast is only being used to locate services - after that jobs are queued via tcpip to listening servers. The actual code is not exactly what is posted - it was a cut down version to demonstrate the problem.
[reply]

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

[reply]
        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]

      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.


      ___________
      Eric Hodges
[reply]

      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.

      The intelligent reader will judge for himself. Without examining the facts fully and fairly, there is no way of knowing whether vox populi is really vox dei, or merely vox asinorum. — Cyrus H. Gordon
[reply]
        Thanks, I'll look into upnp.
[reply]

In Section Seekers of Perl Wisdom