Path: utzoo!mnetor!uunet!husc6!hao!gatech!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uxc.cso.uiuc.edu!hamilton
From: hamilton@uxc.cso.uiuc.edu
Newsgroups: comp.mail.uucp
Subject: Re: Packet size & number of windows
Message-ID: <173700001@uxc.cso.uiuc.edu>
Date: 27 Jan 88 20:42:00 GMT
References: <13668@pyramid.pyramid.com>
Lines: 25
Nf-ID: #R:pyramid.pyramid.com:13668:uxc.cso.uiuc.edu:173700001:000:1306
Nf-From: uxc.cso.uiuc.edu!hamilton    Jan 27 14:42:00 1988


csg@pyramid says:

> You *cannot* increase the packet size beyond its current limit of 64. Although
> the protocol supports packets up to 4096, no UUCP version in use to date has
> buffers to handle anything bigger than 64. So if you increase the packet size
> and buffer sizes on your end, you will core dump the uucico on the other end.

     i've been hacking the ibm-pc version of uupc.  i read greg chesson's
description of the 'g' protocol, and got the notion that if i send INITB(3)
instead of INITB(1), the protocol will use 256-byte packets instead of
64-byte ones.  so i tried it.  between a pc/at and a pyramid(!) 90x.  pyramid
uucico always sends INITB(1), so my cico sends 64-byte packets.  however,
pyramid uucico does notice and honor my segment size parm; it uses 256-byte
data packets for file transfers to me.  unfortunately, it also sends 256-byte
"SY", etc, messages (it packages them as a 64-byte "short data" packet within
a 256-byte block).  it uses my INITB parameter as BOTH a minimum and maximum
seg size.

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