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