Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!texbell!nuchat!steve
From: steve@nuchat.UUCP (Steve Nuchia)
Newsgroups: comp.org.usenix
Subject: Re: USENIX Board Studies UUCP
Keywords: protocols
Message-ID: <16695@nuchat.UUCP>
Date: 23 Nov 89 16:09:48 GMT
References: <287@usenix.UUCP> <1624@crdos1.crd.ge.COM> <1989Nov16.182104.23746@utzoo.uucp> <92074@pyramid.pyramid.com>
Reply-To: steve@nuchat.UUCP (Steve Nuchia)
Organization: Houston Public Access
Lines: 36

In article <92074@pyramid.pyramid.com> romain@pyramid.pyramid.com (Romain Kang) writes:
>reading).  Likewise, SLIP is not engineered for hostile environments,
>and it has been already pointed out that the traditional TCP suite
>(SMTP, FTP, and NNTP) requires unacceptable dead time.

SLIP as it stands isn't suitable for hostile environments, but perhaps
a SLIP2 with link-level compression + error detection + retransmission
would work better, and could be written after "release 1.0".  I agree
completely with the idea expressed by another writer that the startup
and negotiation protocol needs to be nailed down first, but would add
that the transfer request and file spec protocol and the remote execution
control file semantics need to be nailed down in the same standard.

As far as dead time goes, a suitable amount of parallelism should
keep even the fastest links busy.  No reason not to allow each end
to keep several sessions going, at least one of which should be
blasting data at any given time.  The ability to keep the channel
busy is the primary reason for going to a multiplexed protocol.

This may require minor or major changes to the protocols -- for
instance NNTP could queue the article for the uucp module once
it determined that the remote wanted it, then continue negotiating.
This is the sort of thing that would be worked out over time.

The most important thing, in my view, is to get a package out that
is in source form and capable of interoperating with existing
TCP/IP and UUCP applcations without too much grief.  Having it
out there will enable a renaisance of experiments with the high
and low level protocols and a year from now we will know the
answers to some of the questions appearing here.  If we try to
answer all the questions first we're wasting everybody's time.
-- 
Steve Nuchia	      South Coast Computing Services      (713) 964-2462
"Man is still the best computer that we can put aboard a spacecraft --
 and the only one that can be mass produced with unskilled labor."
					- Wernher von Braun