Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-unix!sri-spam!ames!ucbcad!ucbvax!topaz.rutgers.edu!hedrick
From: hedrick@topaz.rutgers.edu (Charles Hedrick)
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  Encore Annex or Bridge Terminal Server
Message-ID: <8611162326.AA03138@topaz.rutgers.edu>
Date: Sun, 16-Nov-86 18:26:11 EST
Article-I.D.: topaz.8611162326.AA03138
Posted: Sun Nov 16 18:26:11 1986
Date-Received: Wed, 19-Nov-86 22:23:32 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 30
Approved: tcp-ip@sri-nic.arpa

We use Bridge CS100's extensively.  We normally set them to be transparent.
I.e. ^O ^S ^Q get passed to the host.  We set ^\ to do both XON and XOFF
locally.  (This character doesn't seem to be needed by any of our software.
You can choose another if you prefer.)  ^S takes too long to work through
the network to be useful, so we felt we had to supply some local ability
to pause output.  But the ^S character would be a disaster, since it is
uased by Emacs for search.  The problem of terminating output (^O and ^C)
can be solved within the telnet protocol.  Bridge supports the Telnet
synch.  When the host clears its output buffer, it sends an out of
band notification to the server, with an inband mark to say where
discarding data should stop.  We implemented the host end on our
Pyramids.  ^O still ddoesn't work instantly, but it is good enough for
practical purposes.  

At some point terminal service will put a load on your Ethernet.  But
that point is several thousand users.

If your system is going to be used for heavy timesharing, the host end
of telnet will use some CPU time.  For a couple of users I wouldn't
expect to see an effect.  Also, character echo will slow down as the
system gets loaded, since telnetd has to be shceduled twice for each
character.  On our Pyramids we put telentd in the kernel, which both
removes the loading effect and removes the echo delay.  We have not
tried this on the Sun, but no doubt we will eventually.

The terminal server is a lot more flexible.  We are tending to use
that for most new terminals.  But it is more complex, and so there
are more things that can go wrong.  Where we have a machine whose
users will always be connected to that one machine, we still use
direct terminals.  But that is increasingly rare.