Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!usc!apple!voder!pyramid!csg From: csg@pyramid.pyramid.com (Carl S. Gutekunst) Newsgroups: comp.mail.uucp Subject: Re: 'g' protocol over X.25 - why not? Message-ID: <126528@pyramid.pyramid.com> Date: 10 Sep 90 23:45:35 GMT References: <6706.26e3ab4f@ccvax.ucd.ie> Organization: Pyramid Technology Corp., Mountain View, CA Lines: 29 In article <6706.26e3ab4f@ccvax.ucd.ie> ctwomey@ccvax.ucd.ie writes: >Now assuming that I have two machines linked via modems and PADs using an >X.25 connection, and the connection is such that the PADs ignore all >interpretation of characters essentially entering binary mode, why exactly >does the 'f' protocol work and the 'g' protocol not? There are really only three deciding factors in chosing between 'f' and 'g': - Transparency. 'g' needs a crystal-clear 8-bit path. There are an *amazing* number of PADs out there that cannot be configured to run 8-bit transparent, or at least not using runtime means like PAD parameters. - Throughput. For every 'g' packet sent, uucico must receive an acknowledge- ment. The window size (the number of concurrently unack'd packets allowed) is 3 for most uucico's, 7 for the newer ones. Often, the network delay to return the acknowledgement is greater than the time it takes to transmit all 7 packets. Even if you have properly raised the packet level window size above the default 2, you still tend to end up with uucico rushing out 7 packets, then snoozing until all 7 acks come in at once, then sending out 7 packets, etc. Some people on the net have done some serious tuning to improve throughput; see the other articles on this thread. - Costs. All those ACK packets and overhead of 'g' make it cost around three times as much as 'f', on text files. If you have really binary data (like the output of compress), you might get killed on all the quoting that 'f' has to do for 8-bit characters. Around here, we use the ~news/encode filter whenever shipping binary data over links known to use the 'f' protocol.