Hi Gavin -
   Yep..you are right on all counts.  In a nutshell, the way it works is that
when jinetd determines that a Telnet connection is to be established, it
calls a procedure, PTD_INIT (PTD stands for Pseudo Terminal Device...kinda like
pty, but not ..;-)), that does all sorts of stuff, including allocating the
device, grabbing system buffer resources and initializing the Telnet connection
with the TCP layer.  Right before PTD_INIT exits, it calls a procedure that
notifies JOB/SESSIOIN management that  a session needs to be started on this
newly created device.  After this, PTD_INIT exits and INETD is now out of the
picture.
   The feedback that the Telnet team got when doing the Telnet/iX server
design was that an extra server process, as with VT, was a BAD idea, so we
implemented the driver in a way so that it is directly callable from the
CI.  The way to view the Telnet driver is that it is a callable library that
the CI and JSMAIN have enough intelligence about in order to get and receive
data properly.  So, if you would look at a process tree for a Telnet connection,
all you would see at the bottom was the CI process.

Whew...that's my 30 second Telnet tutorial for today...have a nice Labor Day
weekend for all of you in the US and for our no-US compatriots, have a nice
weekend also.

Cheers from the blistering midwest and Lawrence, Kansas, the hottest place
in the lower 48...

Jeff B.

Gavin Scott ([log in to unmask]) wrote:
: Dave writes:
: > I've always assumed VT-MGR to be faster because it is an OS type process
: > where TELNET or FTP is running in a JOB which is dependent on the
: > job queue settings and such.

: This is only somewhat valid for the connection establishment part of the
: process.  Even though the telnet "listener" is part of INETD, once you start
: to establish a telnet connection "magic" happens and telnet is just as much
: of an "OS type process" as VT from that point on.

: You can, for example, abort the INETD job and while this will prevent new
: telnet sessions from connecting, it won't affect any which are already
: connected.

: Telnet also seems to manage not to need a separate "server" process for each
: session (unlike VT which has a VTSERVER process for each connection).  I
: *think* this means that telnet connections require one less process per user
: than VT sessions.

: G.


--
----------------------------------------------------------
Jeff Bandle
Hewlett-Packard                 email: [log in to unmask]
Commercial Systems Division     Voice: (785) 842-0369
Remote office:                  Fax:   (785) 842-0273
4701 Harvard Dr.
Lawrence, KS  66049
           Disclaimer: Comments are my own, not HP's
----------------------------------------------------------