in reply to Re: Unusual(?) server
in thread Unusual(?) server

Forget to insert this paragraph :)

I think i must say what actualy have to do this stuff and what for this. Clients are running on a number machines (about 100), all they have to do is to know it's current state(0,1). This information controlled, calculated and what ever by the server. Periodicaly means every 1 min. Looking at this model you're see an usual client-server application. Unusual is that there are situations when server must be able instantly send new state to the client, not waiting next connection round.

Replies are listed 'Best First'.
Re: Re: Re: Unusual(?) server
by BrowserUk (Patriarch) on Nov 18, 2002 at 07:39 UTC

    Given your needs, I think that pg hit the nail on the head in his post when he suggested UDP.

    To avoid the terminology problem, lets call the single machine the collector and the 100 machines emitters.

    Have the collector listen on a single UDP socket for packets from the emitters. Each time it gets a packet it updates that emitters status in a hash with a timestamp. Inside the listen loop, have the collecter run through the list looking for an emitter with a timestamp more than a minute old. If it finds one, have it attempt a TCP connect to that emitter and request the status, if the connect fails or the status isn't recieved, raise the alarm.

    If you have the emitters send their status at say twice the frequency of the timeout period, then you allow for some packets to get dropped without raising false alarms.

    With this model, there is no need for child processes, reaping or hundreds of connections and ports. Just one listening UDP port and a low-frequency, transient TCP connection that is only used when the network gets flaky. You might benefit from making that a child process, though if you are running on a threaded perl, it would make more sense and use less resources to use a thread.

    On a threaded Perl, you could also have the verify timestamps loop run in a seperate thread using read-only access to the hash, whilst the listening loop did the updating without needing much in the way of serialisation.

    Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
    Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
    Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
    Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.

[reply]
      This is cool approach but one thing that i forgot to mention early (sorry), that client in the case of dead server must automaticaly switch to the '0' state. Only one way to do this is to remember time of the last dialog with the server and if it's more than for example 2 min, go to '0' state.
[reply]

        That's exactly what the "timestamp" and the "verify timeout loop" I mentioned are for?

        Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
        Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
        Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
        Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.

[reply]

In Section Seekers of Perl Wisdom