Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site styx.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!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: Tue, 22-Apr-86 23:15:23 EST
Article-I.D.: styx.20586
Posted: Tue Apr 22 23:15:23 1986
Date-Received: Thu, 24-Apr-86 05:57:49 EST
References: <800@oliveb.UUCP>
Organization: Lawrence Livermore Laboratory, Livermore, CA
Lines: 30
Xref: watmath net.bugs.uucp:747 net.unix-wizards:17770

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