Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!pyramid!pesnta!amd!amdcad!amdimage!prls!philabs!nyit!rick
From: rick@nyit.UUCP (Rick Ace)
Newsgroups: net.unix-wizards,net.lan
Subject: Re: CPU usage of telnetd
Message-ID: <223@nyit.UUCP>
Date: Thu, 20-Mar-86 09:44:55 EST
Article-I.D.: nyit.223
Posted: Thu Mar 20 09:44:55 1986
Date-Received: Thu, 27-Mar-86 07:22:24 EST
References: <10620@amdcad.UUCP> <526@mordred.purdue.UUCP>
Organization: NYIT Computer Graphics Lab., Old Westbury, N.Y.
Lines: 84
Xref: watmath net.unix-wizards:17346 net.lan:1380

[]
cak@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