Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re^2: How to answer a UDP broadcast

by mje (Curate)
on Jun 19, 2007 at 19:50 UTC ( #622092=note: print w/replies, xml ) Need Help??


in reply to Re: How to answer a UDP broadcast
in thread How to answer a UDP broadcast

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.

Replies are listed 'Best First'.
Re^3: How to answer a UDP broadcast
by Trizor (Pilgrim) on Jun 19, 2007 at 20:41 UTC

    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.

        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.

Re^3: How to answer a UDP broadcast
by eric256 (Parson) on Jun 20, 2007 at 00:11 UTC

    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
Re^3: How to answer a UDP broadcast
by idsfa (Vicar) on Jun 20, 2007 at 14:40 UTC

    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
      Thanks, I'll look into upnp.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://622092]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (3)
As of 2020-07-05 14:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?