Communication protocol | |
Purpose | file transfer protocol |
---|---|
Developer(s) | CompuServe Information Service |
Introduction | 1979 |
Hardware | modems |
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 (which was an asynchronous version of the standard protocol) 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.
Since B protocol was designed only to work within the CompuServe, most third-party communications clients of the day were not compatible with it. Notable exceptions were Tera Term and Datastorm's ProComm Plus on the PC which featured the ability to listen for the Enquire
command on the active communications port, and ZTerm on the Mac which allowed auto-starting transfers. This development was part of a wider trend of using external communications applications in conjunction with online services.
The original version of the B Protocol was an outgrowth of an earlier bi-directional protocol introduced in 1979, adding options for including a standardized command structure in the stream. This protocol was intended for use by a custom online terminal built by Tandy, the "AgVision" or "VideoTex", but this project was abandoned after being sold for only a brief period. The AgVision system, with the modem removed, became the basis of the TRS-80 Color Computer.
The protocol was later expanded in the B Plus version, although there were two revisions of this version. B Plus focussed the overall concept primarily on supporting downloads from CompuServe, as opposed to user-to-user transfers. The following description is based on the B Plus documentation and does not explicitly refer to the earlier (and rare) B.
B Plus is a sliding window protocol with variable-sized packets between 128 and 2048 bytes and windows of one or two packets. The addition of the 1k and 2k block sizes and sliding windows were the primary changes in structure between B and B Plus. All potential problematic control characters were always quoted, a requirement because many people accessed CompuServe over non-8-bit-clean packet services such as Tymnet. B Plus also used any one of four types of error checking.
The basic packet structure consisted of five parts:
Lead-in | <DLE>B |
Sequence # | <0x30> through <0x39> |
Type | Single byte |
Body | zero to 2048 bytes |
Trailer | <ETX> Check Value |
(may be followed by <RS> ) |
The lead-in serves the same purpose as the "header" in most protocols, indicating that the data following is a B Plus packet. The sequence number is a simple way of making sure packets are received in the correct order on reception. The small number range used does not present a problem because packets even "one out of order" will trigger a re-send or abort, so there is no possibility of the "wrong 0x30" being received, ten packets later.
Characters in the Body or Trailer are "quoted". Officially only a few characters are quoted, <ETX>
, <ENQ>
, <DLE>
, <DC1>
(XON), <DC3>
(XOFF) and NAK
. Typically three other characters are quoted as well, <RS>
, <DC1>
+ 0x80 and <DC3>
+ 0x80. Characters are quoted by adding 0x40 to their ordinal value, and prefixing them with the <DLE>
character. For instance, the <ETX>
character (0x03) would be sent as <DLE>C
.
The Check Value was quoted, as were the contents it checked against, but the value inside was the check of the unquoted values. That means that Body had to be extracted and unquoted before the Check Value could be calculated on the receiving end. Four types of Check Values were allowed, the original XMODEM checksum, a slightly modified version of the cyclic redundancy check (CRC) used in XMODEM-CRC, or the CCITT CRC-16 or CRC-32. When using the CCITT CRC, the Trailer also included an optional <RS>
character at the end as a "network break" (send now), although it is not clear why this was not supported with other Trailer types.
B Plus defined several different packet types, as opposed to most protocols which included only one. These packets were used both for data transfer as well as secure delivery of commands and protocol setup information. The four types were:
Transport Parameters | + |
File Transfer | T |
Data | N |
Failure | F |
The most common packets, in terms of overall number transferred, are T packets carrying the data for a file transfer. These packets have no further semantic value and are formatted as described above. The T packets also include "subtypes", Tr for "transfer resume", TF for "transfer failure" if the resume did not match the partially downloaded file, and TI for "transfer information", which sent details on the file being transferred. Most protocols would send file information as a special "zeroth packet" in the transfer stream itself, whereas in B Plus this was handled by a separate packet type and effectively out of the transfer stream itself, although there was no real difference in practice.
The Failure packet allows the sender to indicate various problems inside the packet stream. The packet normally contains a single "known" character, but can also include an informational message following this character. The most common Failure packet is the A(bort), allowing the user to terminate transfers on request. Other failures included (C)apacity failure (out of disk space) and (M)issing file, among others.
The Transport Parameters was sent typically only once, during the initial connection phase. This packet contained a number of details in a known format that synchronized what features both ends of the connection were capable of using. It was during this phase that the type of Check Value was selected, for instance.
In addition to the normal packet types outlined above, B Plus also included separate types for sending commands to CIS via the B Plus error-corrected layer. The M packet was a single data packet, while L was also a data packet but indicated that the stream of data was now complete. This had to be indicated in this fashion because, unlike a file transfer, the amount of data being sent would not be known in advance.
The contents of these packets were free-form and were not defined in the B Plus documentation itself. However the basic concept was that the user's terminal program would respond to CIS's Interrogation Sequence (sent when the user first logged in) by starting a transfer with the M type. This stream would be used to send commands to the CIS host, which would respond by opening another transport layer stream back to the terminal program. These streams were "sequenceless", and read out in the order they were received. Errors or Failure packets caused both channels to abort.
Possibly the only user of the Transport Layer was CompuServe's own Host-Micro Interface (HMI) API. HMI defined a number of commands that could be used to drive CIS, along with the possible responses to them, bypassing the command line interface. Since error correction was being used as a side effect of being built on B Plus, the possibility of incorrectly interpreting the commands or potentially garbled responses was basically eliminated. CIS expanded HMI to allow control of most of the batch-oriented interface, including functions for e-mail, conferences and file transfers.
Transport Layer streams could not take place at the same time as file transfers, so in general terms the applications using the Transport Layer were fairly modal. For instance, CIS Navigator for the Mac, which was HMI based, allowed users to navigate CIS offline, setting up various e-mail and file transfers which would then be carried out in a single batch in order to reduce online time. The last step of the Navigator "run" would be to download files before logging off.
All protocols use the "backchannel" to send status information from the "receiver" back to the "sender". B Plus formalized this system, defining several "messages" that could be sent outside the packet structure. These included the typical DLE
followed by a sequence number in order to acknowledge the correct reception of a packet. NAK
was used to indicate an improperly received packet, which was responded to with acknowledge messages, <DLE><DLE>
. <DLE>;
paused the sender, while <DLE>+
aborted the stream.
The Enquire control sequence appears unique to B Plus. Consisting of a single <ENQ>
, the Enquire was used both to start transfers as well as restart after receiving a NAK
. In both cases the Enquire caused the receiver to reset its connection mode to the most basic possible transfer settings, and prepare for a transfer.
In computing and telecommunication, a control character or non-printing character (NPC) is a code point in a character set, that does not represent a written symbol. They are used as in-band signaling to cause effects other than the addition of a symbol to the text. All other characters are mainly printing, printable, or graphic characters, except perhaps for the "space" character.
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.
In computer networking, the User Datagram Protocol (UDP) is one of the core members of the Internet protocol suite. With UDP, computer applications can send messages, in this case referred to as datagrams, to other hosts on an Internet Protocol (IP) network. Prior communications are not required in order to set up communication channels or data paths.
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.
The File Transfer Protocol (FTP) is a standard communication protocol used for the transfer of computer files from a server to a client on a computer network. FTP is built on a client–server model architecture using separate control and data connections between the client and the server. FTP users may authenticate themselves with a clear-text sign-in protocol, normally in the form of a username and password, but can connect anonymously if the server is configured to allow it. For secure transmission that protects the username and password, and encrypts the content, FTP is often secured with SSL/TLS (FTPS) or replaced with SSH File Transfer Protocol (SFTP).
CompuServe was an American online service provider, the first major commercial one in the United States – described in 1994 as "the oldest of the Big Three information services ."
High-Level Data Link Control (HDLC) is a bit-oriented code-transparent synchronous data link layer protocol developed by the International Organization for Standardization (ISO). The standard for HDLC is ISO/IEC 13239:2002.
In the seven-layer OSI model of computer networking, the presentation layer is layer 6 and serves as the data translator for the network. It is sometimes called the syntax layer.
UUCP is an acronym of Unix-to-Unix Copy. The term generally refers to a suite of computer programs and protocols allowing remote execution of commands and transfer of files, email and netnews between computers.
Modbus is a data communications protocol originally published by Modicon in 1979 for use with its programmable logic controllers (PLCs). Modbus has become a de facto standard communication protocol and is now a commonly available means of connecting industrial electronic devices.
BinHex, originally short for "binary-to-hexadecimal", is a binary-to-text encoding system that was used on the classic Mac OS for sending binary files through e-mail. Originally a hexadecimal encoding, subsequent versions of BinHex are more similar to uuencode, but combined both "forks" of the Mac file system together along with extended file information. BinHexed files take up more space than the original files, but will not be corrupted by non-"8-bit clean" software.
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.
Real-Time Messaging Protocol (RTMP) is a communication protocol for streaming audio, video, and data over the Internet. Originally developed as a proprietary protocol by Macromedia for streaming between Flash Player and a server, Adobe has released an incomplete version of the specification of the protocol for public use.
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.
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.
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.
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.
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.