Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!umigw!mthvax.cs.miami.edu!wb8foz From: wb8foz@mthvax.cs.miami.edu (David Lesher) Newsgroups: comp.sys.ibm.pc Subject: Re: XMODEM,YMODEM,ZMODEM,KERMIT Which is best and why? Keywords: ZMODEM, KERMIT Message-ID: <1388@umigw.MIAMI.EDU> Date: 3 Jan 90 02:52:04 GMT References: <1990Jan2.070518.1822@csusac.csus.edu> <1578@clmqt.marquette.Mi.US> <1990Jan2.175320.10597@csusac.csus.edu> Sender: news@umigw.MIAMI.EDU Reply-To: wb8foz@mthvax.cs.miami.edu (David Lesher) Lines: 34 >Has anyone else had problems like I illustrated in my previous post? If so, >perhaps we can isolate it and create a fix for certain environments. I will >post my findings...time to go fire up the datascope! Well, ISTM the problem with ZMODEM and multiple boxes betwixt and between isn't ACKS or quacks, it's dropped data. Since ZMODEM does not sit around every 'n' bits and wait for a grunt back, it overflows those routes with FUBAR flow control. In theory, you get everything out that you put in. In practice, if the buffers are small, and the flowcontrol either too slow or too stupid, you lose stuff. Now since X,Y and Kermit all {send, wait, send, etc} there is time for the buffers to empty. ZMODEM sees no reason to waste this time. There is a Gandolf/Decserver path to mthvax. If I attempt use it with text, it drops the ends of full pages. Pages with lots of short lines and s are no problem. Sure enough, ZMODEM bitches constantly if I attempt to use this path. But it does go through, intact. IMHO, you can't blame ZMODEM for the valid assumption that what goes in, must come out. You can blame the people who designed and/or implementated the hardware. -- A host is a host & from coast to coast...wb8foz@mthvax.cs.miami.edu no one will talk to a host that's close..............(305) 255-RTFM Unless the host (that isn't close)......................pob 570-335 is busy, hung or dead....................................33257-0335