| MEGAlink | |
| Purpose: | file transfer protocol |
| Developer: | Paul Meiners |
| Based On: | XMODEM |
| Hardware: | modems |
MEGAlink is a file transfer protocol for modem-equipped microcomputers written by Paul Meiners in 1987. Like many protocols of the era, MEGAlink is an expanded version of the seminal XMODEM. While it was a relatively simple and high-performance system, it remains relatively obscure because it was overshadowed by ZMODEM, which had been released a year earlier and saw rapid uptake.
XMODEM was introduced in 1977 as what its author described as a "quick hack". It had a number of rather obvious problems, which became more annoying as modem speeds increased during the early 1980s. Through this period, a number of new file transfer protocols for BBS users appeared in order to address issues in the original XMODEM. Many of these had minor problems of their own, or were limited to certain applications, which limited their use. XMODEM remained extremely popular throughout this period, as it was one of the few protocols that was universally supported.
In 1986, Chuck Forsberg released ZMODEM, a radically improved file transfer protocol that offered many new features, high performance, and ran on services that corrupted XMODEM transfers. The only downside to ZMODEM was that it was very complex, which made it difficult or impossible to implement on some machines, especially the large installed base of systems like the Commodore 64.
MEGAlink was introduced as part of Meiners' GT PowerComm terminal emulator to address this issue. It offered high performance, similar to that of ZMODEM, while being much simpler to implement. In spite of this attractive combination of features, MEGAlink never became popular, and few other terminal emulators appear to have added support - a review article in 1988 shows only PowerComm and one other program supporting it.
The move from 8-bit to 16-bit computers was taking place at the same time that MEGAlink was being introduced, and by the late 1980s any benefits in terms of simplicity had been mooted. ZMODEM went on to be almost universal.
XMODEM is a simple protocol, and that is the primary reason for its popularity.
The file to be sent is broken up into 128-byte chunks that form the payload data of its packets. A 3-byte header consisting of the SOH character and two 8-bit integers is added in front of the data and a 1-byte checksum at the end, making the overall packet 132 bytes long. The protocol is triggered by the receiver, who sends a NAK character to start the transfer, waits for a packet in response, and then sends ACK if the packet was received correctly, or NAK if it wasn't.
Because the phone system has a certain amount of latency, it takes some time for the ACK or NAK to travel back through the lines and trigger the sending of the next packet. At 300 bit/s this represents a short time compared to the time needed to send the packet of data, so this can be ignored. At 2400 bit/s, common latencies mean as much as 50% of the available time is being wasted waiting for replies.
A wide variety of solutions were offered to address this problem. One is to make the packet size larger so the latency represents a smaller fraction of the time needed to send a packet. This was used in a number of protocols, notably YMODEM. Another solution is to use a sliding window that allows multiple packets to be sent without needing an ACK for every one, as used in WXMODEM and others.
MEGAlink is essentially a combination of features from prior attempts to improve XMODEM performance. The most basic change was to expand the packet size from 128 bytes to 512. This not only reduces the relative effects of latency, but also increases the amount of data compared to extraneous information like the header and footer bytes, improving its channel efficiency.
MEGAlink deliberately avoided the sliding window solution, eliminating the need to send an ACK at all. The sender would simply continue to send packets until, if ever, an NAK was received. The NAK was sent with two following bytes, the first containing the packet number where the error occurred, and the second as a two's complement of that number. The sender would then restart the transfer from that point.
In order to quickly re-send data when required, the sender had to maintain a data buffer of the file's data so it could rapidly rewind to that point. Machines of the era had small amounts of memory, 64 kB was not uncommon, so large buffers were not easily arranged. To address the fact that the sender might not have enough memory to send very long streams, MEGAlink allowed the sender to request an ACK at any point, which would allow it to clean out its buffer when needed.
To do this, the sender sent an ASCII RS (Record Separator) character. If the receiver sees an RS instead of the expected SOH at the start of the next packet, it immediately sends a reply consisting of an ACK and the packet number and inverse as in the case of the NAK. The sender can then remove any data prior to that packet from its buffer. For example, GT PowerComm used a buffer large enough for 32 packets, and sent an RSs request every 16 packets or so.
Other changes to the protocol are more minor. To allow operation over some networks, like PC Pursuit, XON and XOFF characters were escaped with a DLE and then XORed with 64. This required any DLE in the original data to be escaped in the same fashion.
The original version of MEGAlink used 16-bit cyclic redundancy check (CRC), as was the case for many other XMODEM offshoots. Like those versions, the receiver indicated it was capable of receiving CRCs by sending an initial C instead of a NAK to begin the transfer. MEGAlink was later modified to support 32-bit CRCs as well, which it did by starting packets with an EM instead of SOH. The "zero packet", containing file information, was always sent with a standard SOH and 16-bit CRC, only the following data packets used the EM format.