Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!ncar!tank!uxc!uxc.cso.uiuc.edu!osiris.cso.uiuc.edu!hamilton
From: hamilton@osiris.cso.uiuc.edu
Newsgroups: comp.dcom.modems
Subject: Re: 'g' & packet sizes & extensions
Message-ID: <10500003@osiris.cso.uiuc.edu>
Date: 31 Aug 88 22:59:00 GMT
References: <7272@bigtex.uucp>
Lines: 32
Nf-ID: #R:bigtex.uucp:7272:osiris.cso.uiuc.edu:10500003:000:1395
Nf-From: osiris.cso.uiuc.edu!hamilton    Aug 31 17:59:00 1988


james@bigtex says:
> ...
> 
> > 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.

    as i recall, i was replying to a suggestion that packet sizes greater
than 256 bytes were undesirable.  it was assumed that the uucico's involved
were to be "fixed".  i've tested at least one BSD-derivative(?) uucico that
does handle larger packets (pyramid OSx).

> > since you can always send smaller packets...
> 
> 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.

    why would a remote "desire" a packet larger than necessary?
i get it, let's go back to source code blank-padded to 80 cols/line :-)
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.

	wayne hamilton
	U of Il and US Army Corps of Engineers CERL
UUCP:	{ihnp4,seismo,pur-ee,uunet}!uiucuxc!osiris!hamilton
ARPA:	hamilton@osiris.cso.uiuc.edu	USMail:	Box 476, Urbana, IL 61801
CSNET:	hamilton%osiris@uiuc.csnet	Phone:	(217)333-8703