matthews@udel.EDU (John Matthews) (10/18/87)
In article <1810@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >Ok, so what does ZModem do that's fantastic? What are the advantages of ZMODEM? From what I have read so far about the protocol there seem to be a few. A few weeks ago Chuck Forsberg, the author/designer of the zmodem protocol (caf@omen.UUCP), posted a note regarding communications software for the PC that had a few interesting numbers regarding throughput. Here are a few lines from that message. >If you have a Unix/Xenix Kermit that does better than half the *throughput* >(not raw speed!) of sz's ZMODEM downloading an .ARC file to a DOS >computer at 19200 bps, please post it. (Example: 386 Xenix at 19200 bps >to an AT clone: Kermit 473 cps, ZMODEM 1809 cps on a 50k .ARC file.) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In some other note I read, some guy said he'd never gotten less than 94% throughput. I have read a little bit about this protocol and so far it sounds good. In one mode of the protocol, the sender just constantly transmits data while the receiver listens. If the receiver detects an error, it sends some sequence of characters to interrupt the sender and tell it to seek back to the position where the error ocurred and start re-sending from there. Another nice feature of this protocol is that you can re-start interrupted data transfers. I have never seen this in any other protocol. ZMODEM also uses a 32 bit CRC for detecting errors which provides a much better level of error detection. There is alot more to this protocol, but it looks like it's a million times better than xmodem. In my opinion, throughput & accuracy are the most important aspects of a communications protocol and this SEEMS to have the best of both. The one (and most important) thing about Kermit that I don't like is its high overhead. To encode a control character with the 8th bit set takes three characters. That's ridiculous, a 300% percent overhead for one byte. Another thing is its STOPPING and WAITING for an ACK packet. If you were to add up all the time that the line is sitting idle, it would be very noticeable. I am not real familiar with the sliding window mechanism of kermit, but it's not even implemented in the Unix version so how could I? If anyone wants to read more about the ZMODEM protocol, ftp the document "PD:<MISC.PROTOCOLS>ZMODEM5.DOC" from SIMTEL20.ARPA. Interested people might also want to pay attention the the group comp.dcom.modems because that's where I have seen of few related messages. Anyone that wants to mention any more about the advantages/disadvantages of this protocol, PLEASE DO. I would like to hear ALOT more about this. John Matthews 4801 Plum Run Court ARPA: matthews@udel.edu Wilmington, DE 19808 BITNET: FFO18429 AT UDACSVM (302) 454-1735 UUCP: {rutgers,seismo,ucbvax,uunet}!udel.edu!matthews CSNET: matthews%udel.edu@relay.cs.net /\ /// /\/^^\/\ I wish I were in the Rockies. /// /^/^/\/^^\ /// / / / \ \ \\\/// \///
keithd@cadovax.UUCP (Keith Doyle) (10/20/87)
In article <604@louie.udel.EDU> matthews@udel.EDU (John Matthews) writes: >There is alot >more to this protocol, but it looks like it's a million times better >than xmodem. > >In my opinion, throughput & accuracy are the most important aspects of a >communications protocol and this SEEMS to have the best of both. Ok, ya convinced me (you and a couple others). Where do I sign? :-) Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170