Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!bloom-beacon!spdcc!xylogics!loverso From: loverso@Xylogics.COM (John Robert LoVerso) Newsgroups: comp.dcom.modems Subject: Re: MNP vs. uucp 'g' - my solution Message-ID: <7263@xenna.Xylogics.COM> Date: 27 Sep 89 00:25:27 GMT References: <125285@sun.Eng.Sun.COM> Reply-To: loverso@Xylogics.COM (John Robert LoVerso) Organization: Xylogics, Inc., Burlington MA Lines: 30 In an article, Bill Shannon writes: > So, what I ended up doing is writing a new uucp protocol based on > the 'g' protocol but including automatic compression of the data. > I call the new protocol 'c'. ... > Needless to say, there are some tradeoffs involved. This scheme takes > more cpu time (and more memory) than either a Telebit or MNP modem, ... There is one other possible solution to your problem. The `g' protocol, or rather, the underlying Packet Driver Protocol, contain{s,ed} code for negotiating a packet size from any of the set: { 1, 32, 64, 128, 256, 512, 1024, 2048, 4096 } I.e., if you are going to invent (and distribute?) a `g' replacement, be sure to re-allow this size negotitation! My understanding is that the code defaults to a 64 byte packet because of a bug in the `g' protocol in v7 that would cause it to crash on large packet sizes. The solution that people came up was to limit `g' rather than to fix and replace broken UUCPs. Does anyone really use v7 UUCP anymore? The bug has long since been fixed in BSD UUCP, btw; its just that the code to select a packet size other than 64 is gone. I would hope that Telebit's `g'-spoofing can understand the negotiation! (ps: see the _Packet_Driver_Protocol_ paper from Greg Chesson for details.) John -- John Robert LoVerso Xylogics, Inc. 617/272-8140 loverso@Xylogics.COM Annex Terminal Server Development Group