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

Metz, Bobby W, WCS bwmetz at att.com
Thu Jun 30 06:33:27 PDT 2005


Ah, to clarify a bit...

Users all telnet from local server to remote devices.
User interface is X-Term from local server.
Certain user commands on remote device will be matched to kick-off other
scripts, output to be displayed in second X-Window opened for that
purpose.
Certain remote device responses return via telnet to user will have
X-Term control sequences added to highlight or colorize certain
keywords.

Hope that clarifies things a bit.  I wasn't real clear last night.

Bobby


-----Original Message-----
From: phoenix-pm-bounces at pm.org [mailto:phoenix-pm-bounces at pm.org]On
Behalf Of Scott Walters
Sent: Wednesday, June 29, 2005 11:27 PM
To: Victor Odhner
Cc: phoenix-pm at pm.org
Subject: Re: [Phoenix-pm] Looking for ideas - Perl Telnet Monitor


Hi,

I'm not in any condition to really comment on this, but being
an old MUD player, I've seen a goodly number of telnet emulators
written -- and MUD "front end" clients written. "telnet" has its
own RFC describing operations (negotiate about window size, etc).
It seems like you either want to implement the RFC with a 
front end or else you're really trying to do something more
interesting. But I'm not clear on which case is the case.

-scott

On  0, Victor Odhner <vodhner at cox.net> wrote:
> Metz, Bobby W, WCS wrote:
> 
> >During the session I want to spawn other tools ...
> >
> I think you are stuck with having your client process every
> byte of input that passes through. I've done that sort of thing
> but always at the remote end, i.e., using "system" calls to the
> system that my agent was running on. Doing it on the remote
> host system is what IPC::Open2 seems to be about, but I gather
> you want to run your client program on a local PC, and have it
> participate in a dialog with a remotely-connected host.
> 
> You could write a client that accepts inputs from the user, and
> if no special commands are recognized, just sends them on to
> the telnet line. But it would scan the input line and if a special
> command or macro were recognized, it could enter a dialog
> either with the telnet session or with the user to execute special
> functions. In some cases you might want two separate client
> processes, one to send user input to the remote end, and another
> to pass remote responses back to the user's screen. That is a
> common design for "terminal emulator" type apps.
> 
> One trick in this process is that you need to know when you
> have a prompt from the remote system, so you know when you
> can send; but some of the time you won't care because you can
> carry on a full-duplex conversation, using two separate (but
> cooperating) processes, and send whenever you want to.
> 
> Something like this can't be fully general, since there will be
> some program out there on the remote host that will produce
> or expect a dialog that your program will manage to mess up.
> But if you intend to control only a limited set of remote
> operations, well, the fewer of them you want, the easier it
> gets. For example, if you want to allow arbitrary command-line
> operations but no screen-controlling software such as vi or
> curses, then it can be really easy.
> 
> This can get tricky if the remote processes are trying to control
> the screen -- either you have to make that totally transparent, or
> you have to understand a fair amount of what's going on so you
> won't mess up screen positioning and cursor control but still
> can distinguish commands that should be handled by your client.
> 
> Operations like changing screen color, etc., if they were things
> the remote system knew how to do, could be done by issuing
> commands to that system and then passing back the formatted
> results transparently; but otherwise, you could filter the stuff
> received via telnet and superimpose your own formatting on it.
> That's what a terminal emulator does on a PC when it's
> presenting a terminal window combined with other objects on
> the same screen, and maybe also watching for strings that
> would prompt scripted responses by the client.
> 
> Finally, if it's OK for the user to be conscious of your client
> sitting in the middle of the dialog, then the user can use special
> commands or keystrokes to put your client into transparent
> mode to run something like vi, and then back into participating
> mode to use macro commands, switch among remote systems,
> etc.
> 
> Good luck,
> 
> Vic
> 
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm
_______________________________________________
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