Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!lll-lcc!pyramid!csg From: csg@pyramid.pyramid.com (Carl S. Gutekunst) Newsgroups: comp.mail.uucp Subject: Re: Hardwired "g" protocol values Message-ID: <61288@pyramid.pyramid.com> Date: 3 Mar 89 07:52:31 GMT References: <60827@pyramid.pyramid.com> <455@lakart.UUCP> Organization: Pyramid Technology Corp., Mountain View, CA Lines: 18 In article <455@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes: >Reading between the lines, if I create a new "g" protocol UUCICO I'd better >keep to 64 byte packets, and a window size of 3 (I think that's how everyone >else does it). Packet size is stuck at 64, yes. Window size negotiation, on the other hand, *does* work properly, and window size 7 has become common for folks running UUCP over PC Pursuit. So if you want to do a "complete" 'g' implementation, you'll have to do variable window size. But you can also fix your window size at 3, and then only accept 3 at negotiation time. Note that reverse-engineering the 'g' protocol is *damn* hard. Few have done so without making grave sacrifices; UUPC and uuslave, for example, came out supporting only a window size of 1, and gave up under almost any error con- dition that the AT&T 'g' implementation would plow right through. Indeed, the 'g' protocol is by far the biggest stumbling block to producing a PD UUCP.