From: mrapple@quack.sac.ca.us (Nick Sayer)
Subject: Re: UUCP 'g' must die 
Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.
Date: Fri, 16 Oct 1992 04:55:06 GMT

gerg@netcom.com (Greg Andrews) writes:

>Last time I looked, it was one of the things you could adjust in one
>of the Systems/Devices/Dialers/Whatever files.  Have you asked about
>this in comp.mail.uucp, or talked with Ian about it?

Well, I found a compiler directive that did it, but it made all
my uucp neighbors gag.

>>I'll stipulate your calculations, but they are merely academic
>>unless you can get the damn thing to USE large packets.

>So is a different protocol.  Useless if the other guy doesn't have it too.

That also is true. So we can agree that a change of one sort or
another is necessary. I think a new protocol is necessary, you
think 'g' can be fixed.

>>>IMHO, we don't need to throw 'g' away.  We just need to write better
>>>implementations, like SVR4 and Taylor.
>>
>>IMHO, The likelyhood of fixing the problem is higher with a replacement
>>protocol. One strongly designed so that hopefully lazy implementers
>>can't make do with getting it 'close' like so many have with 'g'.

>Lazy implementors can be just as lazy with a new protocol as with an
>old one.

Not if the protocol is designed properly.

>However, I don't see this as a crucial issue.  Your uucp
>neighbors will have to get new code and compile it anyway.  Whether it's
>a better implementation of 'g' or a new implementation of something else,
>they'll still have to go through the same amount of work.

This is a telling remark. We agree that the work MUST be done. And we
agree that it's the same amount of work either way. My point is that
if we design a protocol properly, it will be impossible to make
a substandard implementation. The problem with g is that most of the
implementations out there are woefully inadequate. They choose piss-poor
defaults and don't allow those defaults to be adjusted. This argues
for a new protocol designed to make that sort of crap impossible.

>Either way,
>you'll be faced with the same incompatibility problems if their uucico
>can't do the same things yours can.  You'll have to back down to the same
>Lowest Common Denominator:  64-byte/packet 'g'.

The first two words of that paragraph are the most important.

>I'll agree that in 1992, standing on the shoulders of others, you can build
>a protocol that can run as fast or faster than 'g' without most of its
>shortcomings.  However, when your protocol hits the streets, the end users
>are going to have the same problems compiling it and using it with their
>neighbor sites as they would have with an improved implementation of 'g'.

There will, however, be one advantage: A properly designed replacement
protocol would ALWAYS be maximally efficient with ANY implementation
of the same protocol. A reimplementation of 'g' will have a fairly high
probability of falling back to the same 64x3 shit we've been putting
up with all this time.

>If I were trying to get the attention of Unix vendors, should I advocate a
>new protocol, or a better 'g'?

Vendors either do what their customers demand or they're not vendors
for very long (just ask Wang). If the net created a new de-facto
uucp standard it would be a foolish vendor that didn't compile it in.

>Being vendors, they'll worry that the market
>would take a different direction than the one they choose. 

We have to assure them that's not the case. How? By making it a reality
without them. How do we do that? The same way we've done all along.
Stop talking and start doing. The vendors will go with the prevailing
wind. If you build it, they will come.

>That's my viewpoint.  You can design a better protocol, but you can solve
>the throughput issues and be more compatible with the future and the past
>by writing a better version of 'g'.  I'd rather improve 'g' than create a
>new protocol.

It is an equal amount of effort to improve 'g' as start over. You get
the same fallback to 64x3 if you improve 'g' or start over (since if you
start over you still have 'g' to fall back onto). The only difference
at all between the two approaches is that with a proper protocol
spec, you can eliminate the problem of implementations that don't
measure up to the specification working well enough to please the
vendor's QA team, but not well enough to be actually useful, which is
the situation with which 'g' presents us. Everyone can talk 64x3,
but nobody implements anything BESIDES 64x3, therefore when you attempt
to use 1024x7, the uucico on the other end loses its mind, despite
it being perfectly within spec.

That's what's truly wrong with 'g'. It tolerates poor implementation.
A better protocol would tolerate only full implementation, and that
full implementation would be maximally efficient.

-- 
Nick Sayer <mrapple@quack.sac.ca.us> | "Happy Happy Joy Joy Happy Happy Joy Joy
N6QQQ @ N0ARY.#NOCAL.CA.USA.NOAM     |  Happy Happy Joy Joy Happy Happy Joy Joy
37 19 49 N / 121 57 36 W             |  Happy Happy Joy Joy Happy Happy Joy Joy
+1 408 249 9630, log in as 'guest'   |  Happy Happy Joy Joy Joy"
Newsgroups: comp.dcom.modems