[Phoenix-pm] Looking for ideas - Perl Telnet Monitor

Scott Walters scott at illogics.org
Thu Jun 30 10:06:23 PDT 2005


Ahhh... okay, this is just a fragment, but it sounds like you're having the 
standard problem of needing to monitor multiple IO handles -- in this case, at
least one user and one program launched for the user by the daemon. 

select() was designed for this, but it's painful for anything beyond trivial
applications.  All operations must be atomic and must return back to the
"select loop".  Hence things like POE were created.  POE also has an event
loop which is little more than a select loop, but you're still restricted
to atomic operations that can't block or perform additional IO operations
in response to the one that just completed and must instead schedule them
for the future.  You also don't get any variables that persist between
these atomic operations -- all of your data must be instance data or else
it's lost when you return back to the event handler.  This is only marginally
better than a plain select loop.  Perl's threads are unusable for any
case where the threads must share data or else they'd get the recommendation,
but for applications like this, I strongly advocate the Coro module.  In
fact, there are two chapters on it in _Perl 6 Now_ [blatent self-plug
alert].  

Used like this, Coro provides essentially cooperative multithreading.  You'd 
still need IPC::Open2/IPC::Open3.  Coro has a method to convert regular
file handles, such as those returned by IPC::Open2, into something that knows
how to cede the CPU rather than block on data.  

The structure would be something like this:  a listener loop accepts connections
and creates a coroutine (the command prompt) for each connection accepted.  The
command prompt accepts commands (obviously) and creates coroutines for each
command that doesn't complete instantly.  These command coroutines use 
IPC::Open2 or IPC::Open3 to open bi-directional or tri-directional pipes to 
whichever system command is to be run (use the syntax that avoids invoking the
shell!).  The command coroutines, after setting up the pipe, perform filtering
on the data, applying any coloring or highlighting.  If a -more- prompt is 
needed, a coroutine to manage (and filter) all of the command coroutines
should be created.  Coro::Channel would be used to pass text, objects, etc,
between coroutines, but ultimately, one coroutine (the command prompt) would
be reading user input and one or more (the command coroutines or the 
command-coroutine-manager-coroutine) coroutines would write to the user via
their socket.

I hope this helps.  

-scott

On  0, "Metz, Bobby W, WCS" <bwmetz at att.com> wrote:
> Yeh, I was looking at the buffer stuff last night.  Believe expect has a
> similar "problem"...that's why I canned that script...plus I hate
> expect. :)
> 
> -----Original Message-----
> From: Andrew Johnson [mailto:aj at exiledplanet.org]
> Sent: Wednesday, June 29, 2005 7:34 PM
> To: Metz, Bobby W, WCS
> Cc: phoenix-pm at pm.org
> Subject: Re: [Phoenix-pm] Looking for ideas - Perl Telnet Monitor
> 
> 
> On Wed, 2005-06-29 at 19:54 -0500, Metz, Bobby W, WCS wrote:
> > [snip]
> > IO, i.e. it looks like regular send/expect stuff to me.  Anyone out
> > there ever do anything like this or know of some easy Perl trick to
> > monitor bi-dir IO on a TTY or Net:Telnet session without completing
> > taking control from the user typing.  I'm sure the solution is staring
> > me in the face, but right now it eludes me.
> 
> bidirectional IO that _doesn't_ take control from the user typing.
> Well, no.  But you might try IPC::Open2 (I suppose you could capture
> your prog's STDIN and feed it to the telnet process, and pass back
> anything that is read from the telnet process's stdout handle).   Check
> out Chapter 16 (Interprocess Communcation), section 3.3 (Bidirectional
> Communication) of /Programming Perl/.  Since standard I/O buffering is
> probably going to "ruin your day" (the Camel's quote), you might also
> find IO::Select and the IO::Pty (avail on CPAN) module useful.
> 
> Hope this helps.
> 
> --aj
> 
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm


More information about the Phoenix-pm mailing list