Re: Dial-up Users

• Mail folder: WWW Talk Oct 93-present
• Next message: joe@mit.edu: "Re: WWW meta indexes (proposal)"
• Previous message: Marc Andreessen: "It'd be *really* nice to"
• In-reply-to: Tony Sanders: "Re: Dial-up Users "

Date: Wed, 27 Oct 1993 09:27:40 -0700 (PDT)
From: "Rob Raisch, The Internet Company" <raisch@internet.com>
Subject: Re: Dial-up Users 
To: Tony Sanders <sanders@bsdi.com>
Cc: Dale Dougherty <dale@ora.com>, www-talk@nxoc01.cern.ch
In-reply-to: <9310271538.AA01722@austin.BSDI.COM>
Message-id: <Pine.3.03.9310270939.B19968-c100000@hmmm.internet.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 27 Oct 1993, Tony Sanders wrote:

> > on systems that are not directly connected to the network.  Right
> > now, a SLIP/PPP connection is required to use a graphical browser; these
> > connections are more expensive to obtain and more difficult to install.
> > 
> > What can we do to enable communication over a serial line?  
> 
> Doing this right would basically require reinventing SLIP and TCP/IP (you
> need a reliable connection from end to end, ala tcp).  

Well, there's reliable and then there's *RELIABLE*

I have always thought that TCP/IP was a terrible solution to point to
point connectivity for small workstations.  It just isn't needed.  It's
large, cumbersome and wastes a lot of cycles.  Point to Point simply does
not require the same level of technology needed to get a message from one
side of the country to the other, reliably and over redundant paths, while
the bombs are falling.

Consider this model,

	- Host runs various "proxy" agents which manage TCP sessions with
	services out in the 'great wide.'

	- These proxies are simply 'stubs' which manage the connection and 
	feed the data into a communications manager.

	- The communications manager is a simple agent which manages a 
	reliable multiplexed channel back to the client.  The protocol 
	looks something like:

		[Channel Number]			1 octet
		[Packet Type & Data Length mod 2]	1 octet
		[Checksum]				2 octets
		[  ... Data ... ]			2 ... 1024 octets

	- On the client side, there is the other half of the communications
	manager.  It breaks each channel out and feeds it to a window.

	- The various windows (I've identified 12 different and useful types)
	take the data and display it.  Binary images, Gopher menus, WWW 
	browsers, etc.

	- So, each Internet service has a proxy agent which feeds data into
	a communications manager (CM.)  The CM multiplexes data over the wire
	to the client, where data if fed to independant windows (or User
	Interaction Agents.)

One of the issues here is the isolation of complexity.  The client side
handles only those issues which deal with the user, and the server deals
only with those issues which deal with the communications.

This is a simple model, extensible, and could be hacked up in a few days. 
I did it once, actually.  Would love to see someone take this on as a project.
(Marc? <grin>)

	</rr>