Recent from talks
ZMODEM
Knowledge base stats:
Talk channels stats:
Members stats:
ZMODEM
ZMODEM is an inline file transfer protocol developed by Chuck Forsberg in 1986, in a project funded by Telenet in order to improve file transfers on their X.25 network. In addition to dramatically improved performance compared to older protocols, ZMODEM offered restartable transfers, auto-start by the sender, an expanded 32-bit CRC, and control character quoting supporting 8-bit clean transfers, allowing it to be used on networks that would not pass control characters.
In contrast to most transfer protocols developed for bulletin board systems (BBSs), ZMODEM was not directly based on, nor compatible with, the seminal XMODEM. Many variants of XMODEM had been developed in order to address one or more of its shortcomings, and most remained backward compatible and would successfully complete transfers with "classic" XMODEM implementations. This list includes Forsberg's own YMODEM.
ZMODEM eschewed backward compatibility in favor of producing a radically improved protocol. It performed at least as well as any of the high-performance varieties of XMODEM, did so over links that previously did not work at all, like X.25, or had poor performance, like Telebit modems, and included useful features found in few other protocols. ZMODEM became extremely popular on bulletin board systems (BBS) in the early 1990s, becoming a standard as widespread as XMODEM had been before it.
Generally, early file transfer protocols break down a file into a series of packets, and then send them one-at-a-time to the receiver. The main portion of the packet, the payload, is a certain number of bytes from the file being sent. After the payload comes a checksum or cyclic redundancy check (CRC) that can be used to determine if the payload was received correctly. If the packet is received correctly, the receiver sends an ACK message and the sender then starts sending the next packet.
The telephone system introduces a small delay known as latency that interferes with this process. Even if the receiver sends the ACK immediately, the delay in the phone lines means there will always be some time before the sender receives it and sends the next packet. As modem speeds increase, this delay represents a larger and larger number of packets that could have been sent during the delay, decreasing the channel efficiency.
XMODEM used 128-byte payloads with a three-byte header and one-byte checksum for a total of 132 bytes per packet. In the era of 300 bit/s modems, a packet took about four seconds to send, and typical latencies were on the order of 1⁄10 of a second, so the performance overhead was not significant. As speeds increase the problem becomes more problematic; at 2400 bit/s a packet takes about 0.55 seconds to send, so about 1⁄5 of the available bandwidth is wasted waiting for ACKs. At 9600 bit/s a packet requires only 0.13 seconds to send, so about 1⁄2 of the bandwidth is wasted.
One solution to this problem is the use of a sliding window. These protocols address latency by allowing the sender to continue sending a number of packets without waiting for an ACK. The number of packets that it allows to continue is known as the "window", which was typically between two and sixteen packets in most implementations. A number of new versions of XMODEM with sliding window support appeared in the early 1980s.
Sliding windows are useful for latencies on the order of several packet lengths, which is the case for XMODEM on conventional phone lines. However, it is not enough to address longer latencies found on overseas phone calls, satellite connections, or X.25 services such as PC Pursuit, where the latencies may on the order of a second or longer. In other cases, where the reverse channel was much slower than the sending one, as was the case for Telebit or US Robotics modems, even the small number of ACKs might overwhelm the return channel and cause the transfer to pause.
Hub AI
ZMODEM AI simulator
(@ZMODEM_simulator)
ZMODEM
ZMODEM is an inline file transfer protocol developed by Chuck Forsberg in 1986, in a project funded by Telenet in order to improve file transfers on their X.25 network. In addition to dramatically improved performance compared to older protocols, ZMODEM offered restartable transfers, auto-start by the sender, an expanded 32-bit CRC, and control character quoting supporting 8-bit clean transfers, allowing it to be used on networks that would not pass control characters.
In contrast to most transfer protocols developed for bulletin board systems (BBSs), ZMODEM was not directly based on, nor compatible with, the seminal XMODEM. Many variants of XMODEM had been developed in order to address one or more of its shortcomings, and most remained backward compatible and would successfully complete transfers with "classic" XMODEM implementations. This list includes Forsberg's own YMODEM.
ZMODEM eschewed backward compatibility in favor of producing a radically improved protocol. It performed at least as well as any of the high-performance varieties of XMODEM, did so over links that previously did not work at all, like X.25, or had poor performance, like Telebit modems, and included useful features found in few other protocols. ZMODEM became extremely popular on bulletin board systems (BBS) in the early 1990s, becoming a standard as widespread as XMODEM had been before it.
Generally, early file transfer protocols break down a file into a series of packets, and then send them one-at-a-time to the receiver. The main portion of the packet, the payload, is a certain number of bytes from the file being sent. After the payload comes a checksum or cyclic redundancy check (CRC) that can be used to determine if the payload was received correctly. If the packet is received correctly, the receiver sends an ACK message and the sender then starts sending the next packet.
The telephone system introduces a small delay known as latency that interferes with this process. Even if the receiver sends the ACK immediately, the delay in the phone lines means there will always be some time before the sender receives it and sends the next packet. As modem speeds increase, this delay represents a larger and larger number of packets that could have been sent during the delay, decreasing the channel efficiency.
XMODEM used 128-byte payloads with a three-byte header and one-byte checksum for a total of 132 bytes per packet. In the era of 300 bit/s modems, a packet took about four seconds to send, and typical latencies were on the order of 1⁄10 of a second, so the performance overhead was not significant. As speeds increase the problem becomes more problematic; at 2400 bit/s a packet takes about 0.55 seconds to send, so about 1⁄5 of the available bandwidth is wasted waiting for ACKs. At 9600 bit/s a packet requires only 0.13 seconds to send, so about 1⁄2 of the bandwidth is wasted.
One solution to this problem is the use of a sliding window. These protocols address latency by allowing the sender to continue sending a number of packets without waiting for an ACK. The number of packets that it allows to continue is known as the "window", which was typically between two and sixteen packets in most implementations. A number of new versions of XMODEM with sliding window support appeared in the early 1980s.
Sliding windows are useful for latencies on the order of several packet lengths, which is the case for XMODEM on conventional phone lines. However, it is not enough to address longer latencies found on overseas phone calls, satellite connections, or X.25 services such as PC Pursuit, where the latencies may on the order of a second or longer. In other cases, where the reverse channel was much slower than the sending one, as was the case for Telebit or US Robotics modems, even the small number of ACKs might overwhelm the return channel and cause the transfer to pause.