Path: utzoo!attcan!uunet!husc6!rutgers!ucsd!ames!killer!bigtex!james
From: james@bigtex.uucp (James Van Artsdalen)
Newsgroups: comp.dcom.modems
Subject: Re: 'g' & packet sizes & extensions
Message-ID: <7717@bigtex.uucp>
Date: 8 Sep 88 03:43:28 GMT
References: <7272@bigtex.uucp> <10500003@osiris.cso.uiuc.edu>
Reply-To: james@bigtex.UUCP (James Van Artsdalen)
Organization: F.B.N. Software, Austin TX
Lines: 29

In article <10500003@osiris.cso.uiuc.edu>, hamilton@osiris.cso.uiuc.edu wrote:
> james@bigtex says:

> > I don't know what the design goal was, but my assumption was that when
> > the remote system sent me its desired window and packet size, that's
> > what it wanted, and nothing else.

>     why would a remote "desire" a packet larger than necessary?

I have no idea.  It doesn't matter.  If I don't use the packet size
the remote requests, the remote may crash (many seem to do so).  Since
a crashed uucico has a throughput of exactly 0, whereas whatever it
asked for may do better, I do whatever it asks for.

> i think it makes more sense that the negotiation is to set maximums.
> surely if one side has enough buffer space for 1024-byte packets,
> 64-byte ones should not cause heartburn.

You have no idea what's going on in that other uucico.  For all you
know, there's a comparison to make sure that all incoming packets have
the "right" size.  I just don't see the benefit in not doing whatever
it asks for.

It would be nice to extend 'g'.  It would be better not to break
existing ancient implementations.  Very few people have the luxury of
source to fix bugs.
-- 
James R. Van Artsdalen    ...!uunet!utastro!bigtex!james     "Live Free or Die"
Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746