Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!milano!bigtex!james
From: james@bigtex.uucp (James Van Artsdalen)
Newsgroups: comp.dcom.modems
Subject: Re: 'g' & packet sizes & extensions
Message-ID: <7272@bigtex.uucp>
Date: 30 Aug 88 23:01:51 GMT
References: <10500001@osiris.cso.uiuc.edu>
Reply-To: james@bigtex.UUCP (James Van Artsdalen)
Organization: F.B.N. Software, Austin TX
Lines: 25

In article <10500001@osiris.cso.uiuc.edu>, hamilton@osiris.cso.uiuc.edu wrote:

> what would it hurt to negotiate a huge *max* packet size (say, 1024+),

Probably won't work.  Most uucps seem to crash when you negotiate anything
other than 64.

> since you can always send smaller packets.  every packet carries a size
> field; if the code is written correctly, packets only as large as needed
> will be sent.  i modified my uupc to do this, but when my uucp neighbor
> sent me 256-byte "HY" messages, i took it out again.

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.  It can't tell what window size I'm
really using of course, but I wouldn't shocked if sending smaller
packet sizes crashed the remote.

It would be better to add a new protocol to solve these problems,
something with a real CRC instead of a simple checksum and much lower
overhead (preferably streaming).  Also worth the effort is that
ability to continue aborted transfers (this involves changing the
transaction protocol, not the packet protocol).
-- 
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