Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!oliveb!olivey!jerry
From: jerry@olivey.olivetti.com (Jerry Aguirre)
Newsgroups: comp.dcom.modems
Subject: Re: TrailBlazer and UUCP
Message-ID: <28073@oliveb.olivetti.com>
Date: 29 Aug 88 20:09:27 GMT
References: <12793@mimsy.UUCP> <27022@oliveb.olivetti.com> <7708@cit-vax.Caltech.Edu>
Sender: news@oliveb.olivetti.com
Reply-To: jerry@olivey.UUCP (Jerry Aguirre)
Organization: Olivetti ATC; Cupertino, Ca
Lines: 22

In article <7708@cit-vax.Caltech.Edu> mangler@cit-vax.Caltech.Edu (Don Speck) writes:
>This problem can be sidestepped by making the new protocol upward
>compatible.  For instance, fix the packet size negotiation bugs in
>the "g" protocol, offer it as both the "g" and "G" protocol, and if
>the "G" protocol is chosen by the remote uucico (indicating that it
>too has the bug fixes), then negotiate a 128-byte or 256-byte packet
>size.  This should be simple enough to implement that it could actually
>happen.

This sounds like a great idea.  The small 'g' packet size is not optimal
for present day line speeds.  What would be even better is if the modem
could spoof the packet size negotiation and repackage the packets for
the remote end.  That way I could take advantage of larger packet sizes
even if the remote system hasn't upgraded his software.

>N.B. Packet sizes larger than the tty input buffer won't decrease the
>read() overhead any further, and big packets are inefficient for small
>files, so you don't want to negotiate any higher than 256 bytes.

So, I'll make the tty buffers bigger.  There is a problem with
reliability though.  A one byte CRC(?) per packet isn't really enough
when you get much larger packets.