Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!mailrus!b-tech!zeeff From: zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) Newsgroups: comp.org.usenix Subject: Re: USENIX Board Studies UUCP Message-ID: <9X+#8^@b-tech.uucp> Date: 6 Dec 89 22:31:23 GMT References: <37014@apple.Apple.COM> Reply-To: zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) Organization: Branch Technology, Ann Arbor, MI Lines: 29 In article <37014@apple.Apple.COM> fair@Apple.COM (Erik E. Fair) writes: >In the referenced article, zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >> >>All we really need is for vendors to fix the larger packet sizes >>code in uucp so that acks will fit in small reverse channels. Telebit > >A UUCP ACK is 6 bytes. My understanding is that the telebit "reverse >channel" allows for 11 bytes. Why doesn't it work the way you expect? >Could it be the small standard window size (2 to 3 packets), or the >small outbound packet size (64 bytes)? (rhetorical questions, don't It's the small packet size. 11 bytes how often? On a percentage basis: 6/64 ~= 10% which is too big for a trailblazer or HST reverse channel. 6/512 = 1% which should fit. >There is no "bug" here; UUCP g-protocol was not engineered to use these >half-duplex pseudo-full-duplex modems. If you can't fix UUCP, you fix Whether it was engineered for it or not, uucp using 'g' can support larger packet sizes which, with a fixed ack size, are what these modems need to avoid reversing the channel. If fact, large packets even work on some versions of uucp (I've tried it). Telebit did a smart thing and is being rewarded for it. It doesn't mean that other solutions should be neglected. -- Jon Zeeff Branch Technology