Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!uunet!ispi!jbayer
From: jbayer@ispi.UUCP (Jonathan Bayer)
Newsgroups: comp.sys.ibm.pc
Subject: Re: XMODEM,YMODEM,ZMODEM,KERMIT Which is best and why?
Keywords: ZMODEM, KERMIT
Message-ID: <1270@ispi.UUCP>
Date: 3 Jan 90 15:30:51 GMT
References: <1990Jan2.070518.1822@csusac.csus.edu> <1578@clmqt.marquette.Mi.US> <1990Jan2.175320.10597@csusac.csus.edu>
Organization: Intelligent Software Products, Inc.
Lines: 43

scott@csusac.csus.edu (L. Scott Emmons) writes:

>In article <1578@clmqt.marquette.Mi.US> scott@clmqt.marquette.Mi.US (Scott Reynolds) writes:

>I 'spose I didn't make it very clear in my post, but yeah, the problem with
>Zmodem that I have found likely _isn't_ the protocol itself (which, IMHO, is
>the best one yet), but rather is with the setup of our computer network
>network. [sic -- we have a network of networks, if you will].  I still find it
>strange that ACKfull protocols work where Zmodem doesn't -- Apparantly some
>boxes (X.25 networks, for example) barf on ACKs...which is why Kermit was
>(according to my sourcs) invented (it uses no ACKs).  It seems to me that
>Zmodem should work anywhere that any other protocols do...but I'm not familiar
>with the mechanics of Zmodem.

>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!


The problem isn't Z-modem, it is the hardware.  Somewhere in the network
a buffer is being overflowed and data is being lost.  This happens
because Z-modem is a streaming protocol, meaning that it sends
continously until either there is an error or the file is finished.  

There is already a fix.  sz has some options, the "-l" and the "-L". 
Copying from the manual pages:

	  L N  Use ZMODEM sub-packets of length	N.  A larger N (32 <=
	       N <= 1024) gives	slightly higher	throughput, a smaller
	       N speeds	error recovery.	 The default is	128 below 300
	       baud, 256 above 300 baud, or 1024 above 2400 baud.
	  l N  Wait for	the receiver to	acknowledge correct data every
	       N (32 <=	N <= 1024) characters.	This may be used to
	       avoid network overrun when XOFF flow control is
	       lacking.



JB
-- 
Jonathan Bayer		Intelligent Software Products, Inc.
(201) 245-5922		500 Oakwood Ave.
jbayer@ispi.COM		Roselle Park, NJ   07204