Talk:ZMODEM

Untitled

The key improvement in ZMODEM was the introduction of sliding window support for improved performance.

This is technically incorrect, while ZMODEM supports using a sliding window, the preferred ZMODEM transfer method uses no window what-so-ever. What this means is that if a transfer occurred without error, the receiver would send no ack's to the sender during the entire transfer process, and the sender would simply send continuously as fast as the channel would accept the data. That is why ZMODEM is known as a "streaming protocol, there is no stop in the data flow unless an error is detected.

This method was what made ZMODEM so fast on Telenet's X.25 network (no returning ACK's if no errors) and allowed it to achieve to within a fraction of a percent of Ymodem-G in speed, while allowing for error recovery if needed.

Note this paragraph from http://www.omen.com/zmdmev.html:

For ZMODEM, I decided to forgo the complexity of SuperKermit's packet assembly scheme and its associated buffer management logic and memory requirements. ZMODEM uses the actual file position in its headers instead of block numbers. While a few more bytes are required to represent the file position than a block number, the protocol logic is much simpler. Unlike XMODEM, YMODEM, SEAlink, Kermit, etc., ZMODEM cannot get "out of sync" because the range of synchronization is the entire file length.

And this paragraph from the same document:

ZMODEM normally sends data non-stop and the receiver is silent unless an error is detected. When required by the sender's operating system or network, the sending program can specify a break signal or other interrupt sequence for the receiver to use when requesting error correction.

The fact that ZMODEM uses the actual file length and file position means that when an interrupted download is restarted, the download restarts where it left off. Previously, with XMODEM and YMODEM, the part of the blocks of the file that were downloaded before interruption were deleted when the download was restarted. As a SysOp of a BBS for eight years, I can testify that this was a quantum leap in file downloads.

66.92.173.100 (talk) 22:38, 5 September 2010 (UTC)

yes,but isn't it normal today? ~2025-31994-56 (talk) 19:05, 3 February 2026 (UTC)