[Chicago-talk] Design Question

Wiggins d'Anconia wiggins at danconia.org
Fri May 6 12:59:22 PDT 2005


Richard Reina wrote:
> Thank you Andy, Wiggins and JT for the responses thus
> far. 
> 
> 
>>connections from the client machines and hangs on to
>>them, 
> 
>  
> What do you mean by "hangs on to them"?
>

See below, the longer description should help...

> then when the
> 
>>Perl script logs the data have it call an event on
>>the server to
>>dispatch an message to each of the clients. 
> 
> 
> This act of dispatching a message to the clients is
> what pushed me into using polling.  I could not figure
> out a neat way to do get message to all these
> (stripped down) clients that run various kernel
> versions. 

Kernel versions?

 Setting up rysnc on all of them seemed
> painful and impractical.  ncftput seems too slow and
> on some of the machines unavailable. 
> 
> client -->perl->DBI--> server
> 
> seemed the fastest and most practical, although I
> admit I am having trouble conseptualizing what your
> talking about above.

Right.... so here is what I was thinking:

You have 3 pieces of software.

1. The main and probably most difficult to write is a server (again, I
would use POE). It gets started and runs in the background listening for
two types of connections. 1. connection from the phone script that
connects to the server via a socket sends it a message for the server to
issue to each of the listening clients 2. connection from various
listening clients over a socket as well. So the server keeps track of
all the connected clients that want information about events (aka phone
calls), when they establish a connection the connection remains alive
waiting for output. When an event comes into the server from the phone
script it loops over all of the connected/listening clients and sends
them the same message (using a UDP server you wouldn't have to loop or
keep track of connected clients). Since the server only comes alive when
it hears from the phone script it doesn't hog CPU either.

2. Listening client, your local PC (or whatever) connects to the server
over a socket and sits idle waiting for the server to tell it something
has happened, should be real simple and should sit idle until something
happens (no need to poll! == no CPU usage).

3. Messaging client, the phone script you already have, as the last part
of that process it connects to the server tells it what message to send
to the listening clients and then exits (similar to how a DB call works).

POE by virtue of how it operates and the wrappers it provides around the
socket stuff should make it pretty trivial to write the various
components.  Obviously you can get as complex as you want, maybe a
particular client tells the server which types of messages it wants to
hear about, or maybe certain users only have access to certain messages,
etc.

More difficult to write for sure, but from a performance standpoint it
should be much easier on the machines and more importantly the network
than polling. And it should scale very well.

Does this make a bit more sense??

http://danconia.org


More information about the Chicago-talk mailing list