[2122] in Commercialization & Privatization of the Internet
Re: Trickle Down? How About Bubble Up?
daemon@ATHENA.MIT.EDU (Miles R. Fidelman)
Mon Jan 27 19:49:48 1992
From: "Miles R. Fidelman" <mfidelma@diamond.bbn.com>
Date: Mon, 27 Jan 92 19:48:46 EDT
To: com-priv@psi.com
It seems to me that dial-up IP misses the point for small users. For a
lot of applications, it is not very effective to run a PC-class
machine, behind a low bandwidth link, as a full Internet host. Rather it
is more effective to connect to a more powerful machine, that has high
bandwidth connectivity, and use it as an agent/filter.
For example, from my home Mac, I currently have two news reading
options available:
1. run a newreader on the Mac, communicating with an NNTP server
over a SLIP connection
2. log in as a dumb terminal to a network-connected unix box that
supports nn
Given that I use a 2400 baud modem, running MNP5 compression, option 2
works a lot better than option 1.
However, what would seem to be a lot more effective would be to have
a third option, as follows:
o establish a terminal session between my local machine and the
network-connected machine
o rely on the modems to provide compression and error correction
o use a very light weight protocol to allow a client program on my
machine to access one or more server processes on the network host
o split functionality between the client and server in such a way
as to minimize traffic over the low bandwidth link (e.g. run news
kill files on the server)
In short, what would seem appropriate is a more general purpose version
of something like Compuserve's Navigator, or Applelink. To flesh this
out a bit, the functions/protocols needed to support such an
environment are:
1. link and session establishment:
o start by (automatically) initiating a terminal-to-host
connection over whatever means are available (direct
dial-up, VAN, etc.)
o initiate a login session to a special account (e.g. like
UUCP does)
o negotiate for error checking, compression, encryption services
as appropriate (e.g. software compression only if one's
modem doesn't support it)
o the primary point is to minimize overhead on the low-bandwidth
link
2. control command exchange -- some form of general purpose
mechanism for forking processes, invoking programs within them, and
exchanging commands with one or more running processes -- this part
of the protocol might include a general purpose mechanism for
requesting the information needed to construct a program-specific
menu on the users PC, and then for sending menu selections back
to the server (this is where Compuserve Navigator, Applelink, and
even Prodigy, provide some good models)
3. data exchange, possibly with negotiated type conversions
performed at one end or the other of the link
4. possible extensions to the protocol would allow pre-emptive
foreground exchanges for interactive traffic, with background
support for batch-like traffic
Given these basic mechanisms, it's pretty easy to envision approaches
to split functionality between client and server, in many cases by
using only slightly modified versions of the tools normally available
on Unix boxes to provide the server functionality. For example:
o for mail: run a post-office server and POP client, but modify POP
to run directly over the serial link; possibly add some functions
that allow the client to specify remote sorting and filtering of
traffic
o for news: see above
o for file transfer: run FTP on the server, with control commands
passed to/from the client; use a light weight protocol to move
files from the server to the host, possibly in the background while
engaging in more interactive activities
o remote login is about the only activity where bits are going to
be passed straight through the server, and even then running
batch activities in the background makes sense
Anyway, any comments, responses? Any body want to step up to
developing a prototype?
Miles Fidelman
