Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/15/85; site mordred.purdue.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!inuxc!pur-ee!pucc-j!purdue!cak
From: cak@purdue.UUCP (Christopher A. Kent)
Newsgroups: net.unix-wizards,net.lan
Subject: Re: CPU usage of telnetd
Message-ID: <526@mordred.purdue.UUCP>
Date: Sat, 15-Mar-86 11:31:26 EST
Article-I.D.: mordred.526
Posted: Sat Mar 15 11:31:26 1986
Date-Received: Sun, 16-Mar-86 10:48:32 EST
References: <10620@amdcad.UUCP>
Organization: Department of Computer Science, Purdue University
Lines: 43
Xref: watmath net.unix-wizards:17235 net.lan:1354
Summary: telnetd is quite expensive

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).

There are fixes to TCP that can be made to buffer several characters into
one packet; this cuts the network overhead, but doesn't affect the telnetd
performance. It seems that as long as telnetd runs as a user program,
it's doomed to be expensive.

So, I say, move telnetd into the kernel! This has worked for other operating
systems, notably TOPS-20. Build a new tty-like bottom half driver that
does telnet's options negotiations, etc., and interfaces to the top half
of the tty driver; it would look like a DH, DZ, etc. telnet options would
directly affect "stty" parameters, force signals, etc. No more using ptys
for this style of remote login.

This was done in the CSNET X.25-to-IP code for X.28/X.29 PAD access; we built
a new bottom half. In some sense, the protocol was a little simpler to deal
with (didn't have to twist TCP around inside the kernel, the board made that
a bit easier) but there's no reason why this shouldn't work in principle.

Of course, it would be nice to do the same with rlogin. 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. Perhaps the getty table for rlogind ports would 
invoke a special table that understood how to interpret the initial
protocol authorization handshake, or call login with the appropriate 
arguments... yah, it seems like that might work. In fact, both rlogind
and telnetd ports could be made to understand little goodies like passing
the terminal type and that (telnet has an option for this, too, though
4.2 doesn't seem to know how to handle/use it.)

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