CPU usage of telnetd

[Rick Ace]

[]
cak at purdue.UUCP (Christopher A. Kent) writes:

> Sure enough, telnetd is expensive. So is rlogind. I wish I had the time to
> do this, but I don't, so I'll pass on the idea and perhaps someone will
> do the world a favor and implement it.
> 
> First, why it's so expensive: because each packet (potentially one per
> character!) causes at least 2 context switches, and crosses the user/system
> boundary 4 times (socket->telnetd, telnetd->pty, pty echo->telnetd, telnetd->
> socket).

Indeed.  rlogin is expensive too.  Consider what happens when a user
types *one* character on an rlogin connection:  an agent process on the
client system wakes up, reads the character, and writes it out to a socket;
an agent (rlogind) awakens on the server, reads the character from its
socket, and feeds it to the pty; the tty driver on the slave end of the
pty devours the character and echoes it; the server agent awakens again
to read the echoed character from the pty and write it to the socket;
an agent process on the client (rlogin) awakens to read the character
from the socket and write it to the user's terminal.  Whew, that's a total
of four (two on the client plus two on the server) context switches!

> [discussion about moving these funtions into the kernel]

> Of course, it would be nice to do the same with rlogin.

We did.

>							  The only problem
> that I see there is that rlogind does some work involving the file system
> during protocol startup; telnetd doesn't. (I'm talking about checking
> hosts.equiv and so on.) I don't see right off how to make that happen
> from inside the kernel.

You negotiate the connection in user-mode in rlogin and rlogind.  Once
the connection has been established, rlogin does an ioctl to bind
the user's tty with the TCP socket, and rlogind does a complementary
ioctl to bind its TCP socket with its pty; from now until the connection
breaks, all character switching is done exclusively within the kernel.
The rlogin (sans child) and rlogind agent processes still exist;
however, their roles have been reduced to negotiating the connection
and awaiting (via kernel sleep()) its termination... the per-character
context switches are gone.

Since the protocol is unchanged, it's possible for a kernel-rlogin
client to interoperate with a vanilla 4.2bsd rlogind and vice-versa.

> If you do this, please let the world know so it can be farmed back into
> 4.4BSD (;-). And so I could have it for my systems!
> 
> Cheers,
> chris

World, you are hereby notified.  I've made a set of mods for 4.2bsd to
implement kernel-switched rlogin connections, both the client and
server ends.  We've been using them for several months now.  If there
is sufficient interest, I'll pursue making a public distribution.
Although I haven't seen 4.3bsd (anyone know what's happening here?),
the 4.2 mods shouldn't be too hard to install in 4.3.

PURISTS BEWARE:  This facility requires a few small hooks in ttyinput(),
sbwakeup(), tty_pty.c, and maybe one or two other places that aren't
on the tip of the tongue.  If this disgusts you, mail your flames to
/dev/null and proceed to the next posting :-).  From a pragmatist's
perspective, a modicum of smut in one's kernel is a small price to
pay for more responsive rlogin connections, fewer context switches
(and on Vaxes, fewer cache flushes), and happier users.

I asked Mike Karels if he had any interest in this stuff, but they
are contemplating an implementation of streams or a stream-oid
facility in 4.4 that would obviate the need for my specialized hack.
(DISCLAIMER:  The ideas expressed in this paragraph are purely
speculative and should not be interpreted as facts or even rumors
about future Berkeley software releases.)

-----
Rick Ace
Computer Graphics Laboratory
New York Institute of Technology
Old Westbury, NY  11568
(516) 686-7644

{decvax,seismo}!philabs!nyit!rick