Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!ucsd!ucsdhub!hp-sdd!hplabs!hpda!hp-sde!hpfcdc!hpfclp!diamant
From: diamant@hpfclp.SDE.HP.COM (John Diamant)
Newsgroups: comp.windows.x
Subject: Re: X Terminals & SLIP
Message-ID: <9740039@hpfclp.SDE.HP.COM>
Date: 12 Jul 88 02:48:41 GMT
References: <8807072305.AA03109@devnull.sun.com>
Organization: HP SDE, Fort Collins, CO
Lines: 50

> The experts I talked to were unanimous that SLIP is not the right answer;
> here are a selection of the reasons they gave:

Many of the points you make below are good, but there are a few corrections.
It seems to me that SLIP is the best thing we have at the moment, but that we
should look for better alternatives for the future.

> 1)	There are a number of incompatible versions of SLIP.  The RFC1055
> 	"generic" version does not cover compression,  which would be important
> 	for X terminals.

I think 4.3BSD SLIP is close to a defacto standard, though certainly there are
incompatible versions, and this is a problem.  Compression is definitely a
problem, though it can be handled in hardware (for instance Telebit
Trailblazers do hardware data compression if requested).  It's not clear that
compression is really that big a win during interactive use of X.  It will
probably only help during transfers of large bitmaps or significant other
amounts of data.  The handshake will slow things down in interactive response.
> 
> 2)	SLIP connections need a separate network number - this fills up
> 	the route daemon tables.

This is not true.  It is implementation dependent.  Cisco Systems has an
implementation on their ethertip that allows all SLIP connections to be on
the same network/subnet as the ethertip.

> 3)	SLIP connections need statically assigned network and host numbers
> 	- this makes it impossible to have a pool of dial-in lines.  I know
> 	that UC Davis has hacked around this,  but once again this isn't
> 	RFC1055 "standard".

Not impossible, just difficult.  Cisco also handles this situation, by telling
you which address was assigned to you upon connection.  They also will work
with bootp to allow a machine to ask for its own address.  This isn't that
big of a problem.

> 4)	SLIP does no error checking.  

Good point.

> 5)	SLIP does not support an Ethernet-like packet type field to permit
> 	extensions (for example,  extensions for compression,  ISO protocols,
> 	and so on).

Yup.


John Diamant
Software Development Environments
Hewlett-Packard Co.		ARPA Internet: diamant@hpfclp.sde.hp.com
Fort Collins, CO		UUCP:  {hplabs,hpfcla}!hpfclp!diamant