MEGAlink

Last updated
MEGAlink
Communication protocol
Purpose file transfer protocol
Developer(s)Paul Meiners
Introduced1987;34 years ago (1987)
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.

Contents

History

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. [lower-alpha 1] 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 [1] - a review article in 1988 shows only PowerComm and one other program supporting it. [2]

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.

Description

XMODEM

XMODEM is a simple protocol, and that is the primary reason for its popularity. [3]

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. [4]

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. [4]

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. [4] 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. [5]

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. [5]

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. [5]

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. [5]

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. [5]

32-bit CRC

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. [5]

Notes

  1. ↑ XMODEM required 8-bit clean links, which the major online services did not always support.

Related Research Articles

The Transmission Control Protocol (TCP) is one of the main protocols of the Internet protocol suite. It originated in the initial network implementation in which it complemented the Internet Protocol (IP). Therefore, the entire suite is commonly referred to as TCP/IP. TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network. Major internet applications such as the World Wide Web, email, remote administration, and file transfer rely on TCP, which is part of the Transport Layer of the TCP/IP suite. SSL/TLS often runs on top of TCP.

Trivial File Transfer Protocol (TFTP) is a simple lockstep File Transfer Protocol which allows a client to get a file from or put a file onto a remote host. One of its primary uses is in the early stages of nodes booting from a local area network. TFTP has been used for this application because it is very simple to implement.

ZMODEM is a 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.

XMODEM is a simple file transfer protocol developed as a quick hack by Ward Christensen for use in his 1977 MODEM.ASM terminal program. It allowed users to transmit files between their computers when both sides used MODEM. Keith Petersen made a minor update to always turn on "quiet mode", and called the result XMODEM.

YMODEM is a file transfer protocol used between microcomputers connected together using modems. It was primarily used to transfer files to and from bulletin board systems. YMODEM was developed by Chuck Forsberg as an expansion of XMODEM and was first implemented in his CP/M YAM program. Initially also known as YAM, it was formally given the name "YMODEM" in 1985 by Ward Christensen, author of the original XMODEM.

Punter (protocol)

Punter is a protocol for file transfer developed in the 1980s by Steve Punter. There are various types of Punter such as PET Transfer Protocol (PTP), C1 and C2.

Charles Alton "Chuck" Forsberg developed two data transmission protocols popular for uploading and downloading files from dial-up bulletin board systems in the 1990s. He received a Dvorak Award for Excellence in Telecommunications in 1992 for developing ZMODEM. He was also the project engineer on the Tektronix 4010-series graphics terminals.

Nagle's algorithm is a means of improving the efficiency of TCP/IP networks by reducing the number of packets that need to be sent over the network. It was defined by John Nagle while working for Ford Aerospace. It was published in 1984 as a Request for Comments (RFC) with title Congestion Control in IP/TCP Internetworks.

Protocol spoofing is used in data communications to improve performance in situations where an existing protocol is inadequate, for example due to long delays or high error rates.

Binary Synchronous Communication is an IBM character-oriented, half-duplex link protocol, announced in 1967 after the introduction of System/360. It replaced the synchronous transmit-receive (STR) protocol used with second generation computers. The intent was that common link management rules could be used with three different character encodings for messages. Six-bit Transcode looked backwards to older systems; USASCII with 128 characters and EBCDIC with 256 characters looked forward. Transcode disappeared very quickly but the EBCDIC and USASCII dialects of Bisync continued in use.

SEAlink is a file transfer protocol that is backward compatible with XMODEM but features a sliding window system for improved throughput. SEAlink was written in 1986 as a part of the SEAdog FidoNet mailer written by System Enhancement Associates, creators of the famous ARC program. It was licensed with a simple "give credit" requirement, but nevertheless was not very widely used except in FidoNet mailers. SEAlink, and most other XMODEM enhancements, were quickly displaced following the introduction of ZMODEM.

ZMax is a file transfer protocol developed in 1990-1991 by Mike Bryeans who also developed Tmodem.

The Microcom Networking Protocols, almost always shortened to MNP, is a family of error-correcting protocols commonly used on early high-speed modems. Originally developed for use on Microcom's own family of modems, the protocol was later openly licensed and used by most of the modem industry, notably the "big three", Telebit, USRobotics and Hayes. MNP was later supplanted by v.42bis, which was used almost universally starting with the first v.32bis modems in the early 1990s.

The B protocol, or CIS B, is a file transfer protocol developed for the CompuServe Information Service, and implemented in 1981. The protocol was later expanded in the QuickB version and later the enhanced B Plus version. It was a fairly advanced protocol for its era, supporting efficient transfers of files, commands and other data as well, and could be used in both directions at the same time in certain modes. These advanced features were not widely used, but could be found in a small number of client-side packages.

SMODEM

Smodem refers to a bidirectional protocol for file transfer used between modems and the DOS program in which the protocol is implemented, both of which were developed by a Finnish company named Arisoft. It was mainly used in bulletin board systems because it could transfer files in both directions at the same time and allowed users to chat with each other with AriSoft's GroupChat software. Other popular bidirectional protocols such as BiModem, HS/Link and HydraCom also offered a chat option with the operator, but not with the system's other users.

A sliding window protocol is a feature of packet-based data transmission protocols. Sliding window protocols are used where reliable in-order delivery of packets is required, such as in the data link layer as well as in the Transmission Control Protocol (TCP). They are also used to improve efficiency when the channel may include high latency.

In data networking, telecommunications, and computer buses, an acknowledgement (ACK) is a signal that is passed between communicating processes, computers, or devices to signify acknowledgement, or receipt of message, as part of a communications protocol. The negative-acknowledgement signal is sent to reject a previously received message or to indicate some kind of error. Acknowledgements and negative acknowledgements inform a sender of the receiver's state so that it can adjust its own state accordingly.

BLAST, like XMODEM and Kermit, is a communications protocol designed for file transfer over asynchronous communication ports and dial-up modems that achieved a significant degree of popularity during the 1980s. Reflecting its status as a de facto standard for such transfers, BLAST, along with XMODEM, was briefly under official consideration by ANSI in the mid-80s as part of that organization's ultimately futile attempt to establish a single de jure standard.

Janus is a file transfer protocol for use on bulletin board systems (BBSs). It has the relatively rare feature that it is fully bidirectional, allowing the protocol to upload and download files at the same time. It was written by Rick Huebner in 1987; Huebner had previously written a ZMODEM module for the Opus-CBBS system.

This article provides information about the communications aspects of Universal Serial Bus, USB: Signaling, Protocols, Transactions.

References

Citations

  1. ↑ Bigley & Tapamila 1987, p. 63.
  2. ↑ Review 1988.
  3. ↑ Christensen 1982.
  4. 1 2 3 Forsberg 1985.
  5. 1 2 3 4 5 6 Meiners 1987.

Bibliography

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.