Re: multithreaded tcp listener with IO::Socket

I don't know how many connections you need to handle simultaneously, or how often connects/disconnects are made, but you might want to look at letting inetd handle the socket. See RFC: A Simple Socket Server Using 'inetd' and A Simple Socket Server Using 'inetd'

For a situation like "heartbeat monitors", it would seem prudent to keep each monitor connection a separate process, so if one goes haywire, it won't affect the others. If your parent thread goes down, for whatever reason, you will see all monitors fail. That will cause havoc for the nurses who are trying to determine which patient needs help.

I'm not really a human, but I play one on earth. flash japh

Comment on Re: multithreaded tcp listener with IO::Socket

Replies are listed 'Best First'.
Re^2: multithreaded tcp listener with IO::Socket by Random_Walk (Prior) on May 15, 2006 at 12:58 UTC
There will probably be less than 50 clients sending heartbeats between 1 and 5 minutes apart. It has to run on Windows as well as nix so I thought to do it all in Perl. I have just hammered it with a multithreaded client and it takes a few secs to clear 100 beats. I have some retry now in the client. If it gets too much perhaps we will specify the server must be on nix and use the inet way, should not be too onerous a requirement. The heartbeat monitor itself will send its own heartbeat using IBM Tivoli events to a Tivoli Enterprise Console (T/EC) so its failure should be detected there. It will also send detected client heartbeat failures as T/EC events, records to a data warehouse and localy log them too. Cheers, R. Pereant, qui ante nos nostra dixerunt!	[reply]

Replies are listed 'Best First'.

Re^2: multithreaded tcp listener with IO::Socket
by Random_Walk (Prior) on May 15, 2006 at 12:58 UTC

There will probably be less than 50 clients sending heartbeats between 1 and 5 minutes apart. It has to run on Windows as well as *nix so I thought to do it all in Perl. I have just hammered it with a multithreaded client and it takes a few secs to clear 100 beats. I have some retry now in the client. If it gets too much perhaps we will specify the server must be on *nix and use the inet way, should not be too onerous a requirement.

The heartbeat monitor itself will send its own heartbeat using IBM Tivoli events to a Tivoli Enterprise Console (T/EC) so its failure should be detected there. It will also send detected client heartbeat failures as T/EC events, records to a data warehouse and localy log them too.

Cheers,
R.

Pereant, qui ante nos nostra dixerunt!

[reply]