From: mah@parrot.prv.univie.ac.at (Michael Haberler)
Subject: Re: Speaking of terminal servers...
Reply-To: mah@ic.co.at
Organization: Vienna University
Date: Sun, 27 Sep 1992 10:18:52 GMT

In article <TOM.92Sep23075758@amber.ssd.csd.harris.com>, tom@ssd.csd.harris.com (Tom Horsley) writes:
|> I have seen a few notes from people who said they are using high speed
|> modems hooked to terminal server boxes (presumably connected to ethernet).
|> 
|> I suspect a configuration like this may be what I wind up with some day, but
|> I am operating from a state of absolute ignorance about how terminal servers
|> work. I have lots of questions someone may be able to answer (it is always
|> more fun to ask the net than to do something obvious like talk to the
|> manufacturer :-).


We're an Internet service provider and are switching from direct 
Unix serial ports to Livingston Portmaster terminal servers for UUCP,
dialup and leased line [compressed](SLIP|PPP). We've checked several 
vendors, but I can only comment on the Livingston product based on
operational experience. You might also check comp.dcom.servers for
a more focused forum.

|>    * What does a terminal server look like to the host machine (in this case
|>      it will be a U**x workstation)? Does it just look like someone
|>      initiated a telnet session into the workstation?

Several options here:
	- telnet/rlogin session
	- a direct connect to a specific port on a given host
	  (for instance, this is useful if you want to connect a program
	  on the host without going through the overhead of a second
	  demon process and pseudo tty's)
	- a Livingston proprietary protocol for which they offer
	  host software for most interesting platforms and on which I'll
	  comment lateron
	- a device emulation mode. A given port on the server appears as
	  a Unix device. This is useful e.g. for dialout via cu or uucp,
	  or connecting printers and so forth.

|>    * How does the workstation use a modem connected to a terminal server
|>      to dial out? Do I initiatiate some sort of telnet session to the server?

	We dont do that (dialin only) but Unix device emulation probably is
	the easiest solution. In that case no telnet session is needed,
	and stty/ioctl operations as needed by most communications software
	is transparently forwarded and executed in the terminal server.

|>    * If the server is just running telnet sessions, how do I do things
|>      like transmit or recieve binary files which might trigger the telnet
|>      escape character?

	Either encode with uuencode or atob, essentially going through 
	the process one would use for mail. Or use Kermit or a similar
	program. In the case of uucp, we use the `Livingston mode' which
	doesnt have this problem, since it also looks like a Unix tty
	which can be set to raw mode but doesnt have Telnet-style inband
	signaling.

|> 
|>    * Do terminal servers support the RTS/CTS flow control which most high
|>      speed modems use? Can I just connect the modem and server at 58K baud
|>      and let the flow control deal with varying connection speeds?

	You dont want to even look at terminal servers which dont do
	bidirectional RTS/CTS. We have Zyxels connected at 57600 baud
	and Worldblazers at 115KBaud. It makes a substantial difference
	if you can keep the compression pipe in the modems under
	pressure at all times. Given that Zyxels go up to 16800 at the link
	and a compression of 4:1 is not unrealistic with certain data 
	stream types, you want to connect modems at at least 57600, and
	faster if possible. With 38400 Baud and compressible streams 
	you wouldnt fully utilize the link.

	Hardware flow control becomes essential once you use compression
	(V42bis, MNP5) in the modem. XON/XOFF doesnt cut it because 
	you need a transparent data path for dialup IP and terminal
	traffic (end-to-end xon/xoff flow control). You *might* get away
	without any flow control iff your only using uucp, as long as
	the uucp windowsize times the packet length doesnt exceed the
	modem buffering capability. 

	A second factor is that RTS/CTS isnt prone to flow control
	deadlock due to a lost XON character (ever noticed that HP printers
	have a `reliable XON/XOFF mode' which repeatedly sends XON's in
	case the host missed one?)


|>    * Is there anything about a terminal server which would prevent me from
|>      being able to use the Fax and voicemail features of the spiffy new
|>      modems being made today? (Obviously I need software to support it on
|>      the host machine, but would the terminal server also need special
|>      software?).

	I'll make up an example: Netfax and Zyxel modems on a terminal
	server. Yes, you could dial out in fax mode, I think. You'd have 
	make sure the server/modem data rate is high enough so a transmit
	underrun doesnt occur in Fax mode. I have no empirical data 
	on this, but I'd feel comfortable starting at 38400 Baud and RTS/CTS
	flow control. 


|>    * Who makes nice reliable and reasonably priced terminal servers (I would
|>      only need something like 4 to 8 ports, nothing big).


No recommendation, but factors to watch for:

I'd check if you really need LAT support. Some companies tacked on 
Telnet support only as an afterthought. You might be better off with a 
company which focuses on what you need.

Several products are outright naive in their dialup IP support, and thus
were unusable for us.

Behaviour under high load/many small packets, working RTS/CTS under any
weather condition, and high-speed I/O on several ports simultaneously
are things I'd keep in mind. 

In our situation the configuration options for the dialup/login sequence
are very important; you dont want to change all your customer's config files
just because you plug a terminal server in between.

Cisco,Datability, Livingston, Xylogics, Xyplex and lots of other companies
make terminal servers. Again, comp.dcom.servers might get you more 
information.


I have no relation to Livingston except as a satisfied customer.

Michael Haberler

-- 
Michael Haberler 			mah@eunet.co.at
EUnet Austria Ltd
A-1010 Vienna, Austria, Schottenring 33
Tel: +43 (1) 346184                             fax: +43 (1) 3104462
Newsgroups: comp.dcom.modems,comp.sys.apple2