From root Wed Apr 23 20:52:45 1986
Relay-Version: version B 2.10.2 9/18/84; site ncr-sd.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site styx.UUCP
Path: ncr-sd!sdcsvax!ucbvax!nike!styx!fair
From: fair@styx.UUCP (Erik E. Fair)
Newsgroups: net.bugs.uucp,net.unix-wizards
Subject: Re: Satellite delays slow UUCP
Message-ID: <20586@styx.UUCP>
Date: 23 Apr 86 04:15:23 GMT
Date-Received: 23 Apr 86 20:38:20 GMT
References: <800@oliveb.UUCP>
Organization: Lawrence Livermore Laboratory, Livermore, CA
Lines: 30
Xref: ncr-sd net.bugs.uucp:366 net.unix-wizards:7587

In article <800@oliveb.UUCP> jerry@oliveb.UUCP (Jerry Aguirre) writes:

[UUCP `g' protocol over satellite link]

>The lines are clean (error corrected) and the round trip delay is
>approximately 1 second.  The UUCP is what came with 4.2BSD.
>
>The UUCP 'g' protocol seems configured around the magic number of 8
>packets of (I think) 64 bytes each.  That should be enough to keep the
>line busy until the ack for the first packet is received.
>
>Has anyone analyzed this problem and come up with a bug fix.

You are correct about the eight-packets-in-flight limit in `g' protocol.

The right thing to do is write your own protocol module for uucico,
which better fits the link layer you're using.  There is precedent:

protocol	organization	link layer
--------	------------	----------
  t		CSS (seismo)	TCP/IP
  f		CWI (mcvax)	X.25 (standard with PAD)
  x		AT&T		X.25 with VPM

You say that your satellite connection is error corrected; is it also
flow controlled? If so, the `t' protocol is probably what you want.
It's a waste to run `g' protocol over an error corrected link anyway
because the effort that `g' puts into checksumming is wasted.

	Erik E. Fair	styx!fair	fair@lll-tis-b.arpa