[comp.dcom.modems] Protocol spoofing in terminal servers

david@ms.uky.edu (David Herron -- a slipped disk) (12/21/89)

I had an odd thought the other day that's in the same general direction
as doing SLIP out of a terminal server ...

How'z'about spoofing various protocols inside the terminal server?

You would get all the same benefits by doing this that trailblazers
get from spoofing protocols.  That is .. translating the protocol-being-
spoofed into something which works well on the intervening medium.

In this case the problem, as I see it that is, is that if you do
a kermit through a terminal server you're often sending tiny 1-5
character packets through the net.  If you could fix things so lots
of those small packets would coalesce into larger ones then the
impact on the network would lessen greatly.  Throughput should also
dramatically improve..

comments?
-- 
<- David Herron; an MMDF guy                              <david@ms.uky.edu>
<- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<- 
<- New official address:  attmail!sparsdev!dsh@attunix.att.com

news@bbn.COM (News system owner ID) (12/22/89)

In article <13531@s.ms.uky.edu> david@ms.uky.edu (David Herron -- a slipped disk) writes:
< How'z'about spoofing various protocols inside the terminal server?

Hmmm.  Maybe, but it would depend on a lot of other things...

< In this case the problem, as I see it that is, is that if you do
< a kermit through a terminal server you're often sending tiny 1-5
< character packets through the net.  If you could fix things so lots
< of those small packets would coalesce into larger ones then the
< impact on the network would lessen greatly.  Throughput should also
< dramatically improve..
< -- 
< <- David Herron; an MMDF guy                              <david@ms.uky.edu>

One problem with this is: how does the terminal server figure out
where the eg. Kermit packets are going?  For instance, I could be
telnetting to a modem-server, and going back out onto phone wires from
there (don't laugh -- it's a quite effective way of using a set of
outgoing or bidirectional modems).

Also, even if I was just telnet-ing/rlogin-ing to a local host, how do
you set up the secondary connection?  Do you want to let your terminal
server setup FTPs without passwords (I don't).  What if I have done
something like this:

	program_foo | kermit -s -


On the other hand, terminal servers could be (and are) made to detect
higher rates of IO and do more reasonable things as a result.
Actually, if you follow the Telnet RFCs correctly, this will all work
out right.

And, of course, the serial-line-transfer protocols should be smart
enough to handle this sort of thing with some amount of grace.  Kermit
with windowing is (but windowing c-kermit is still in pre-alpha
development).  Mearly setting up the packet size as large as you can
get away with helps greatly.

	-- Paul Placeway; MacKermit coord and serial hacker in general
	   <pplaceway@bbn.com>

bob@MorningStar.Com (Bob Sutterfield) (12/22/89)

In article <13531@s.ms.uky.edu> david@ms.uky.edu (David Herron -- a slipped disk) writes:

   How'z'about spoofing various protocols inside the terminal server?
   ...If you could fix things so lots of those small packets would
   coalesce into larger ones then the impact on the network would
   lessen greatly.

Encore does just this with their Annex terminal server.  Part of the
BSD terminal driver is implemented in the Annex and part in the
Multimax, with optimized exchanges betwixt the two.  Also, they have
some special hooks for GNU Emacs so that most of the redisplay and
character-oriented stuff stays on the terminal server rather than
traversing the net.

Annices also do normal telnet, rlogin, BIND, etc. so they're useful
with non-Encore machinery.  They just get particularly interesting
when you're using them with a Multimax.

njs@scifi.UUCP (Nicholas J. Simicich) (12/22/89)

Typically, dial-up modems are so much slower than lans (at least in my
experience) that the limiting factor is the modem.  I'm using an RT as
a terminal server, and I've written a simple program to allow me to
uucp through that rt to any system which runs uucpd.  I find that
using this arrangement (which splits the uucp load away from the
serial line management load) gives me higher throughput than a modem
attached directly to the other machine.  The lan seems insignificant.
Itis difficult to load it significantly at 1.5-3 kb/sec.

This was RT-135 to Trailblazer to Trailblazer to RT-115 to 4 mb/sec
token ring to RT-135.

The program is simple, and just transmits whatever odd sized package
it happens to recieve to the other end.
-- 
Nick Simicich --- uunet!bywater!scifi!njs --- njs@ibm.com (Internet)

prc@erbe.se (Robert Claeson) (12/23/89)

In article <BOB.89Dec21182227@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:

> Encore does just this with their Annex terminal server.  Part of the
> BSD terminal driver is implemented in the Annex and part in the
> Multimax, with optimized exchanges betwixt the two.  Also, they have
> some special hooks for GNU Emacs so that most of the redisplay and
> character-oriented stuff stays on the terminal server rather than
> traversing the net.

Actually, the protocol that does this is not only useable with Gnu Emacs.
It is a quite generic protocol for remote screen updates (ie, the terminal
servers handles cursor movement, function key processing and most screen
updates, and only notifies the host application in large chunks about what's
happening. Currently, however, Gnu Emacs (18.44 or some similar older version)
is the only application that the LEAP (Local Editing Accelerator Protocol)
protocol has been implemented in.

-- 
          Robert Claeson      E-mail: rclaeson@erbe.se
	  ERBE DATA AB