Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!orca!javelin.es.com!bgeer
From: bgeer@javelin.es.com (Bob Geer)
Newsgroups: comp.windows.ms
Subject: Re: Win3 + Kermit 3.01; .PIF's suggestion
Message-ID: <1991Feb21.145803.10465@javelin.es.com>
Date: 21 Feb 91 14:58:03 GMT
References: <1991Feb19.210758.1519@javelin.es.com> <4113@gmdzi.gmd.de>
Reply-To: bgeer%javelin@dsd.es.com
Organization: Evans & Sutherland Computer Corp., Salt Lake City, Utah
Lines: 24

>>2)	Kermit 3.01 starts a download with 2000 byte packets for the
>>first couple of data xfers (large .gif's), then the packet size drops
>>into the low hundreds for the remainder of the xfer.  (Using a
>>USRobotics Courier 2400 external.)  No errors are listed on the
>>download display.  So, why?  Why doesn't it stick to the large packet
>>size?
strobl@gmdzi.gmd.de (Wolfgang Strobl) writes:
>Perhaps because the other side doesn't like long packets? What kermit
>is on the other side? Long packets are a protokol extension of kermit.
>If one of both sides doesn't implement it, kermit falls back to 
>short packets (i.e. packets shorter than 96 bytes).

The Kermit on the sending side is "C-Kermit, 4F(095) 31 Aug 89,
SUNOS4.x".  The first 2-4 incoming packet sizes are 2000, & then the
size starts varying in the few hundreds of bytes range, like some kind
of adaptive packet sizing is going on.  So far, I haven't been able to
find any info on varying packet sizes in what documentation I have
available.

-- 
<> Bob `Bear' Geer <>               bgeer@javelin.sim.es.com              <>
<>      Alta-holic <>   speaking only for myself, one of my many tricks   <>
<> Salt Lake City, <>    "We must strive to be more than we are, Lal."    <>
<>          Ootah  <>           -- Cmdr. Data, learning schmaltz          <>