{"history":[],"article":{"id":"7d342962-7ce9-4f80-bd51-c92a85880ebf","title":"B protocol","slug":"b-protocol","content":":::summary\n**Title:** B protocol \n**Purpose:** [file transfer protocol](https://bliptext.com/articles/file-transfer) \n**Developer:** [CompuServe Information Service](https://bliptext.com/articles/compuserve-information-service) \n**Date:** 1979 \n**Hardware:** [modems](https://bliptext.com/articles/modem) \n:::\n\n# \nThe **B [protocol](https://bliptext.com/articles/protocol-computing)**, or **CIS B**, is a [file transfer](https://bliptext.com/articles/file-transfer) [protocol](https://bliptext.com/articles/protocol-computing) developed for the [CompuServe Information Service](https://bliptext.com/articles/compuserve-information-service), and implemented in 1981.\nThe protocol was later expanded in the **QuickB** version (which was an asynchronous version of the standard protocol) and later the enhanced **B Plus** version.\nIt 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.\nThese advanced features were not widely used, but could be found in a small number of client-side packages.\nSince B protocol was designed only to work within the CompuServe, most third-party communications clients of the day were not compatible with it.\nNotable exceptions were [Tera Term](https://bliptext.com/articles/tera-term) and [Datastorm](https://bliptext.com/articles/datastorm-technologies-inc)'s [ProComm Plus](https://bliptext.com/articles/procomm-plus) on the PC which featured the ability to listen for the Enquire command on the active communications port, and [ZTerm](https://bliptext.com/articles/zterm) on the Mac which allowed auto-starting transfers.\nThis development was part of a wider trend of using external communications applications in conjunction with online services.\n\n# Description\nThe 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.\nThis protocol was intended for use by a custom online terminal built by [Tandy](https://bliptext.com/articles/tandy-corporation), the \"AgVision\" or \"VideoTex\", but this project was abandoned after being sold for only a brief period.\nThe AgVision system, with the [modem](https://bliptext.com/articles/modem) removed, became the basis of the [TRS-80 Color Computer](https://bliptext.com/articles/trs-80-color-computer).\nThe protocol was later expanded in the B Plus version, although there were two revisions of this version.\nB Plus focussed the overall concept primarily on supporting downloads from CompuServe, as opposed to user-to-user transfers.\nThe following description is based on the B Plus documentation and does not explicitly refer to the earlier (and rare) B.\n\n## Packet structure\nB Plus is a [sliding window](https://bliptext.com/articles/sliding-window) protocol with variable-sized packets between 128 and 2048 bytes and windows of one or two packets.\nThe addition of the 1k and 2k block sizes and sliding windows were the primary changes in structure between B and B Plus.\nAll potential problematic [control characters](https://bliptext.com/articles/control-characters) were always [quoted](https://bliptext.com/articles/escape-character), a requirement because many people accessed CompuServe over non-8-bit-clean packet services such as [Tymnet](https://bliptext.com/articles/tymnet).\nB Plus also used any one of four types of error checking.\nThe basic packet structure consisted of five parts:\nThe lead-in serves the same purpose as the \"header\" in most protocols, indicating that the data following is a B Plus packet.\nThe sequence number is a simple way of making sure packets are received in the correct order on reception.\nThe 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.\nCharacters in the Body or Trailer are \"quoted\".\nOfficially only a few characters are quoted, , , , (XON), (XOFF) and NAK.\nTypically three other characters are quoted as well, , + 0x80 and + 0x80.\nCharacters are quoted by adding 0x40 to their ordinal value, and prefixing them with the character.\nFor instance, the character (0x03) would be sent as C.\nThe Check Value was quoted, as were the contents it checked against, but the value inside was the check of the unquoted values.\nThat means that Body had to be extracted and unquoted before the Check Value could be calculated on the receiving end.\nFour types of Check Values were allowed, the original [XMODEM](https://bliptext.com/articles/xmodem) [checksum](https://bliptext.com/articles/checksum), a slightly modified version of the [cyclic redundancy check](https://bliptext.com/articles/cyclic-redundancy-check) (CRC) used in [XMODEM](https://bliptext.com/articles/xmodem)-CRC, or the CCITT CRC-16 or CRC-32.\nWhen using the CCITT CRC, the Trailer also included an optional character at the end as a \"network break\" (send now), although it is not clear why this was not supported with other Trailer types.\n\n## Packet types\nB Plus defined several different packet types, as opposed to most protocols which included only one.\nThese packets were used both for data transfer as well as secure delivery of commands and protocol setup information.\nThe four types were:\nThe most common packets, in terms of overall number transferred, are T packets carrying the data for a file transfer.\nThese packets have no further semantic value and are formatted as described above.\nThe 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.\nMost 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.\nThe Failure packet allows the sender to indicate various problems inside the packet stream.\nThe packet normally contains a single \"known\" character, but can also include an informational message following this character.\nThe most common Failure packet is the A(bort), allowing the user to terminate transfers on request.\nOther failures included (C)apacity failure (out of disk space) and (M)issing file, among others.\nThe Transport Parameters was sent typically only once, during the initial connection phase.\nThis packet contained a number of details in a known format that synchronized what features both ends of the connection were capable of using.\nIt was during this phase that the type of Check Value was selected, for instance.\n\n## Transport Layer\nIn 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.\nThe M packet was a single data packet, while L was also a data packet but indicated that the stream of data was now complete.\nThis had to be indicated in this fashion because, unlike a file transfer, the amount of data being sent would not be known in advance.\nThe contents of these packets were free-form and were not defined in the B Plus documentation itself.\nHowever the basic concept was that the user's terminal program would respond to CIS's [Interrogation Sequence](https://bliptext.com/articles/compuserve-interrogation-sequence) (sent when the user first logged in) by starting a transfer with the M type.\nThis 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.\nThese streams were \"sequenceless\", and read out in the order they were received.\nErrors or Failure packets caused both channels to abort.\nPossibly the only user of the Transport Layer was CompuServe's own **Host-Micro Interface** (HMI) [API](https://bliptext.com/articles/application-programming-interface).\nHMI defined a number of commands that could be used to drive CIS, along with the possible responses to them, bypassing the [command line interface](https://bliptext.com/articles/command-line-interface).\nSince 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.\nCIS expanded HMI to allow control of most of the batch-oriented interface, including functions for e-mail, conferences and file transfers.\nTransport 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.\nFor instance, **CIS Navigator** for the [Mac](https://bliptext.com/articles/apple-macintosh), 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.\nThe last step of the Navigator \"run\" would be to download files before logging off.\n\n## Control sequences\nAll protocols use the \"backchannel\" to send status information from the \"receiver\" back to the \"sender\".\nB Plus formalized this system, defining several \"messages\" that could be sent outside the packet structure.\nThese included the typical DLE followed by a sequence number in order to acknowledge the correct reception of a packet.\nNAK was used to indicate an improperly received packet, which was responded to with acknowledge messages, .\n; paused the sender, while + aborted the stream.\nThe Enquire control sequence appears unique to B Plus.\nConsisting of a single , the Enquire was used both to start transfers as well as restart after receiving a NAK.\nIn both cases the Enquire caused the receiver to reset its connection mode to the most basic possible transfer settings, and prepare for a transfer.","current_revision":null,"created_by":"kACnuQmH5k9Nr5VNVEpVeg7XpvUmMctD","created_at":"2025-01-26T07:28:19.621Z","updated_at":"2025-01-26T07:28:19.621Z","search_vector":"'b':1 'protocol':2","search_content":" \n**Title:** B protocol \n**Purpose:** [file transfer protocol](https://bliptext.com/articles/file-transfer) \n**Developer:** [CompuServe Information Service](https://bliptext.com/articles/compuserve-information-service) \n**Date:** 1979 \n**Hardware:** [modems](https://bliptext.com/articles/modem) \n \n\n# \nThe **B [protocol](https://bliptext.com/articles/protocol-computing)**, or **CIS B**, is a [file transfer](https://bliptext.com/articles/file-transfer) [protocol](https://bliptext.com/articles/protocol-computing) developed for the [CompuServe Information Service](https://bliptext.com/articles/compuserve-information-service), and implemented in 1981.\nThe protocol was later expanded in the **QuickB** version (which was an asynchronous version of the standard protocol) and later the enhanced **B Plus** version.\nIt 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.\nThese advanced features were not widely used, but could be found in a small number of client-side packages.\nSince B protocol was designed only to work within the CompuServe, most third-party communications clients of the day were not compatible with it.\nNotable exceptions were [Tera Term](https://bliptext.com/articles/tera-term) and [Datastorm](https://bliptext.com/articles/datastorm-technologies-inc)'s [ProComm Plus](https://bliptext.com/articles/procomm-plus) on the PC which featured the ability to listen for the Enquire command on the active communications port, and [ZTerm](https://bliptext.com/articles/zterm) on the Mac which allowed auto-starting transfers.\nThis development was part of a wider trend of using external communications applications in conjunction with online services.\n\n# Description\nThe 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.\nThis protocol was intended for use by a custom online terminal built by [Tandy](https://bliptext.com/articles/tandy-corporation), the \"AgVision\" or \"VideoTex\", but this project was abandoned after being sold for only a brief period.\nThe AgVision system, with the [modem](https://bliptext.com/articles/modem) removed, became the basis of the [TRS-80 Color Computer](https://bliptext.com/articles/trs-80-color-computer).\nThe protocol was later expanded in the B Plus version, although there were two revisions of this version.\nB Plus focussed the overall concept primarily on supporting downloads from CompuServe, as opposed to user-to-user transfers.\nThe following description is based on the B Plus documentation and does not explicitly refer to the earlier (and rare) B.\n\n## Packet structure\nB Plus is a [sliding window](https://bliptext.com/articles/sliding-window) protocol with variable-sized packets between 128 and 2048 bytes and windows of one or two packets.\nThe addition of the 1k and 2k block sizes and sliding windows were the primary changes in structure between B and B Plus.\nAll potential problematic [control characters](https://bliptext.com/articles/control-characters) were always [quoted](https://bliptext.com/articles/escape-character), a requirement because many people accessed CompuServe over non-8-bit-clean packet services such as [Tymnet](https://bliptext.com/articles/tymnet).\nB Plus also used any one of four types of error checking.\nThe basic packet structure consisted of five parts:\nThe lead-in serves the same purpose as the \"header\" in most protocols, indicating that the data following is a B Plus packet.\nThe sequence number is a simple way of making sure packets are received in the correct order on reception.\nThe 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.\nCharacters in the Body or Trailer are \"quoted\".\nOfficially only a few characters are quoted, , , , (XON), (XOFF) and NAK.\nTypically three other characters are quoted as well, , + 0x80 and + 0x80.\nCharacters are quoted by adding 0x40 to their ordinal value, and prefixing them with the character.\nFor instance, the character (0x03) would be sent as C.\nThe Check Value was quoted, as were the contents it checked against, but the value inside was the check of the unquoted values.\nThat means that Body had to be extracted and unquoted before the Check Value could be calculated on the receiving end.\nFour types of Check Values were allowed, the original [XMODEM](https://bliptext.com/articles/xmodem) [checksum](https://bliptext.com/articles/checksum), a slightly modified version of the [cyclic redundancy check](https://bliptext.com/articles/cyclic-redundancy-check) (CRC) used in [XMODEM](https://bliptext.com/articles/xmodem)-CRC, or the CCITT CRC-16 or CRC-32.\nWhen using the CCITT CRC, the Trailer also included an optional character at the end as a \"network break\" (send now), although it is not clear why this was not supported with other Trailer types.\n\n## Packet types\nB Plus defined several different packet types, as opposed to most protocols which included only one.\nThese packets were used both for data transfer as well as secure delivery of commands and protocol setup information.\nThe four types were:\nThe most common packets, in terms of overall number transferred, are T packets carrying the data for a file transfer.\nThese packets have no further semantic value and are formatted as described above.\nThe 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.\nMost 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.\nThe Failure packet allows the sender to indicate various problems inside the packet stream.\nThe packet normally contains a single \"known\" character, but can also include an informational message following this character.\nThe most common Failure packet is the A(bort), allowing the user to terminate transfers on request.\nOther failures included (C)apacity failure (out of disk space) and (M)issing file, among others.\nThe Transport Parameters was sent typically only once, during the initial connection phase.\nThis packet contained a number of details in a known format that synchronized what features both ends of the connection were capable of using.\nIt was during this phase that the type of Check Value was selected, for instance.\n\n## Transport Layer\nIn 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.\nThe M packet was a single data packet, while L was also a data packet but indicated that the stream of data was now complete.\nThis had to be indicated in this fashion because, unlike a file transfer, the amount of data being sent would not be known in advance.\nThe contents of these packets were free-form and were not defined in the B Plus documentation itself.\nHowever the basic concept was that the user's terminal program would respond to CIS's [Interrogation Sequence](https://bliptext.com/articles/compuserve-interrogation-sequence) (sent when the user first logged in) by starting a transfer with the M type.\nThis 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.\nThese streams were \"sequenceless\", and read out in the order they were received.\nErrors or Failure packets caused both channels to abort.\nPossibly the only user of the Transport Layer was CompuServe's own **Host-Micro Interface** (HMI) [API](https://bliptext.com/articles/application-programming-interface).\nHMI defined a number of commands that could be used to drive CIS, along with the possible responses to them, bypassing the [command line interface](https://bliptext.com/articles/command-line-interface).\nSince 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.\nCIS expanded HMI to allow control of most of the batch-oriented interface, including functions for e-mail, conferences and file transfers.\nTransport 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.\nFor instance, **CIS Navigator** for the [Mac](https://bliptext.com/articles/apple-macintosh), 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.\nThe last step of the Navigator \"run\" would be to download files before logging off.\n\n## Control sequences\nAll protocols use the \"backchannel\" to send status information from the \"receiver\" back to the \"sender\".\nB Plus formalized this system, defining several \"messages\" that could be sent outside the packet structure.\nThese included the typical DLE followed by a sequence number in order to acknowledge the correct reception of a packet.\nNAK was used to indicate an improperly received packet, which was responded to with acknowledge messages, .\n ; paused the sender, while + aborted the stream.\nThe Enquire control sequence appears unique to B Plus.\nConsisting of a single , the Enquire was used both to start transfers as well as restart after receiving a NAK.\nIn both cases the Enquire caused the receiver to reset its connection mode to the most basic possible transfer settings, and prepare for a transfer.","revisionCount":0},"hasMore":false,"nextCursor":null}

History