Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!unido!gmdzi!strobl From: strobl@gmdzi.gmd.de (Wolfgang Strobl) Newsgroups: comp.windows.ms Subject: Re: Win3 + Kermit 3.01; .PIF's suggestion Message-ID: <4124@gmdzi.gmd.de> Date: 22 Feb 91 23:17:10 GMT References: <1991Feb19.210758.1519@javelin.es.com> <4113@gmdzi.gmd.de> <1991Feb21.145803.10465@javelin.es.com> Organization: GMD, Sankt Augustin, F. R. Germany Lines: 28 bgeer@javelin.es.com (Bob Geer) writes: >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. I'm using 4E on the other side, here, and it does long packets, so this obviously isn't the problem. Adaptive packet sizing should be possible to implement without changing the Kermit protocol specification, but I haven't read about it anywhere, either. I forgot one thing in my first answer, but another poster gave the hint to enlarge the value of the Comxbuffer parameter. I've enlarged the value of the Comxbuffer parameter in system.ini to 512 bytes. The default is 128. I did this to make a Trailblazer work with Kermit under Windows with 19.2 Kbaud. Did you try to play with this parameter? Wolfgang Strobl #include