Stars of Shareware: DFÜ und Kommunikation

home *** CD-ROM | disk | FTP | other *** search

/ Stars of Shareware: DFÜ und Kommunikation / SOS-DFUE.ISO / programm / texte / bplus.doc < prev next >

Wrap

Text File | 1993-11-18 | 84.1 KB | 2,913 lines

The CompuServe B Plus Protocol November 18, 1993 by Russ Ranshaw 11/18/93 04:14 PM 2 The CompuServe B Plus Protocol Table of Contents A. Introduction..........................................3 B. Notation..............................................4 C. B Plus Packets........................................5 1. B Plus Packet Structure..........................5 2. Quoting of characters............................7 3. Check Value......................................9 a) Standard B Protocol Checksum................9 b) XMODEM-Style CRC-16.........................9 4. B Plus Packet Types.........................10 a) Packet Type `+': Transport Parameters......10 b) Packet Type `T': File Transfer.............13 e) Optional `T' Packets........................16 D. B Plus Control Sequences..............................20 1. Enquire..........................................20 2. Positive Acknowledge.............................21 3. Wait.............................................21 4. Negative Acknowledge.............................21 5. Panic Abort......................................21 D. Negotiation of Transport Parameters...................23 F. Terminal Program States...............................25 G. Wait for Acknowledge..................................26 H. Packet Send Ahead.....................................29 I. Implementation Considerations.........................31 1. Port Parameters..................................31 2. Time-Out.........................................31 3. Packet Size......................................33 4. Controlling Excessive Retransmissions............33 5. Flow Control.....................................34 J. B Plus Transport Layer................................35 K. Initiation of Master Mode.............................36 L. Supporting the Various B Protocol Versions............38 M. Check Value Calculation...............................40 N. Interrogation.........................................47 Index....................................................51 2 3 A. Introduction The CompuServe B protocol was developed in 1981 to provide support for a special purpose Vidtex terminal manufacturers by the Tandy Corporation. It was the outgrowth of proposed Bi-Sync oriented protocol, but with a differnt packet structure and provision for more than even and odd packets. The file transfer capability was added in 1982 to replace the CompuServe A protocol with a more robust protocol which was in keeping with the over-all B Protocol design. Some of the underlying assumptions made in designing the B Protocol were due to the capabilities of personal computers which were available at the time. Such machines were generally limited in the amount of available memory, 64 kilobytes being a large capacity. Other factors, such as the lack of a true UART for data communications, resulted in the send/wait nature of the protocol where only a single protocol packet at a time was sent. The explosive growth of the Personal Computer industry has given us a plethora of machines, most of which have far exceeded the early limitations of memory and communication ability. This growth has been accompanied by a multitude of file transfer protocols, such as XMODEM, KERMIT, and ZMODEM. CompuServe, realizing the need for enhancement, has developed the B Plus Protocol to meet the increasing demands being made upon its communication network and host computers, and to provide added utility for its large family of users. As the name implies, B Plus is an extension of the B Protocol. In particular: o Larger data packets (up to 2k]. o Optional use of modified XMODEM CRC-16, CCITT CRC-16 and CCITT CRC-32 cyclic redundancy check methods. o Provide a unique end-of-packet marker to improve network performance. o Extensions to the standard control character quoting. o Provision to allow partial transfers to be resumed at a later time. o Provision of a mechanism to exchange transport and application parameters. 3 4 B. Notation Throughout the remainder of this document the following notation conventions will be used: o Protocol elements are enclosed within angle brackets. For example: <DLE> specifies the ASCII code for Data Link Escape. o The C-language notation for hexadecimal values will be used. Thus, the <DLE> character will also be shown as 0x10. Two entities (computers) are involved in a B Plus session. The term "Initiator" is used to refer to the entity which initiates the session. "Responder" refers to the entity which receives the initiate command. CompuServe host computers will always be the Initiator in any communication established with them. For further information regarding Host support, see Section "K. Initiation of Master Mode". 4 5 C. B Plus Packets 1. B Plus Packet Structure B Plus Protocol packets consist of five parts as follows: o Lead-in <DLE> <B> o Sequence <0x30 through 0x39> o Type <Single byte> o Body <zero to 2048 data bytes> o Trailer <ETX> <Check Value> (may be followed by <RS>) The Sequence is incremented by one for each successfully transmitted packet. It wraps from its high value (0x39) to its low value (0x30. The Sequence, Type, all Body data, and <ETX> are included in the Check Value. Note that <Body> and <Check Value> are Quoted (Sec. C2), and that the Check Value is computed on the actual data bytes rather than their quoted replacements (the quoting <DLE> is not included). Hence, if the character 0x13 is to be sent, it is sent as <DLE> <S> but the value 0x13 is included in the Check Value. If Standard Checksum is used, <Check Value> consists of a quoted byte. If the XMODEM CRC-16 is used, <Check Value) is transmitted as two quoted bytes with the most significant byte appearing first. By performing the CRC calculation on the XMODEM CRC-16 value, the result will be 0x0000 if no errors occurred. If CCITT CRC-16 is used, <Check Value> is transmitted as two quoted bytes, low-order first. CCITT CRC-32 is transmitted as four quoted bytes, from low to high order. Note that the CCIT CRC values are transmitted as their complemented values. If the remote supports either of the CCITT CRC types, then the <RS> (0x1E) follows the Check Value. This character is to be used as "break character" for network forwarding purposes. It has no other implications for the B Plus Protocol. Note that any B Plus implementation must not depend on the presence of <RS> to work. Likewise, all B Plus implementions must function properly if <RS> is sent by the remote, even if the given implementation does not use <RS> itself. 5 6 A sample B Plus packet, sent using the Standard Checksum, is as follows: <DLE> B 7 T D A S . C <ETX> 0x2A 0x10 0x42 0x37 0x54 0x44 0x41 0x53 0x2E 0x43 0x03 0x2A where Lead-in = <DLE> B Sequence = 7 Type = T Body = DAS.C Trailer = <ETX> 0x2A If the packet was sent using the XMODEM CRC-16 option, the Check Value would be 0x57 0xFF instead of 0x2A. 6 7 2. Quoting of characters The B Plus Protocol quotes certain ASCII control characters. The default set of quoted characters is: o <ETX> 0x03 o <ENQ> 0x05 o <DLE> 0x10 o <DC1> 0x11 o <DC3> 0x13 o <NAK> 0x15 If B Plus is in effect, the following characters are added to the default quoting set: o 0x1E (<RS>) o 0x91 (<DC1> + 0x80) o 0x93 (<DC3> + 0x80) The quoting mechanism uses the <DLE> character to prefix the quoted character. The quoted character with 0x40 added follows the <DLE>. For example, <ETX> is quoted as: <DLE> C 0x10 0x43 B Plus also provides a means for the Initiator and Responder to establish a different set of quoted characters. This set may consist of any or all characters in the ranges 0x00 through 0x1f and 0x80 through 0x9f. Quoted characters in the 0x80 through 0x9f range are sent as: <DLE> ((char and 0x1f) + 0x60) Hence, 0x93 is quoted as: <DLE> s 0x10 0x73 7 8 When receiving protocol data, the program should be capable of decoding any quoted character, regardless of the set of quoted characters in use. This must be accomplished as follows: Get a character. If the character is <DLE> then Get next character. If character is less than 0x60 then character = character and 0x1f else character = (character and 0x1f) + 0x80 8 9 3. Check Value Each B Plus packet contains a Check Value to allow detection of transmission errors. The B Plus Protocol supports four Check Value methods as follows: a) Standard B Protocol Checksum. The Standard Checksum is calculated as follows: o The checksum is initialized to zero. o For each byte that is to be checksummed: - The old checksum is rotated left 1, with the old bit 7 becoming bit 0 in the rotated value. - The new byte is added to the rotated checksum. - If addition of the new byte causes a carry, then one is added to the new value. b) XMODEM-Style CRC-16. B Plus implementations may optionally specify that the defacto standard XMODEM CRC-16 be used as a check value. The only departure is that the CRC-16 value is initialized to 0xffff instead of zero. The XMODEM CRC-16 is transmitted in the order of high byte through low byte. c) CCITT CRC-16 and CCITT CRC-32 These are industry standard cyclic redundancy check values. They are transmitted in the order of low byte throuth high byte. 9 10 4. B Plus Packet Types The following Packet Types are the minimum required to support the B Plus Protocol: o `+': Transport Parameters o `T': File Transfer o `N': Data o `F': Failure a) Packet Type `+': Transport Parameters. This is the B Plus Transport Parameters Packet. It describes an entity's Transport capabilities. The Transport Parameters Packet is always sent with all characters in the ranges 0x00 through 0x1f and 0x80 through 0x9f quoted, and using the Standard Checksum. The Body of the <+> packet is a series of bytes as follows: WS WR BS CM DQ TL Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 DR UR FI where: WS = Window Send. 0x00 implies that a single packet at a time can be sent, 0x01 two packets. The default is 0x00. RS = Window Receive. 0x00 implies that the entity cannot receive other than a single packet at a time (that is, requests the other entity to use WS = 0x00); 0x01 implies two packets. The default is 0x00. BS = Block Size. This specifies the maximum size of the <Body> divided by 128. Thus 0x04 represents 512 bytes and 0x16 is 2048 bytes. The value 0x00 implies the default size of 512 bytes. CM = Check Method. 0x00 Standard checksum 0x01 Modified XMODEM CRC-16 0x02 CCITT CRC-16 0x03 CCITT CRC-32 CompuServe urges the use of one of the CRC methods instead of the Standard checksum, as they are more robust in detecting transmission errors. The most secure is CCITT CRC-32, at the expense of additional bytes in each packet. 10 11 DQ = Data Quoting Level. This parameter is part of an interim version of the B Plus Protocol. It has been superseded by the eight byte Quoting Set in Parameters Q1 through Q8 (below). For historical purposes, the Quoting Levels are: 0x00: 0x00 0x03 0x05 0x10 0x11 0x13 0x15 0x01: 0x03 0x05 0x10 0x11 0x13 0x15 0x02: 0x03 0x05 0x10 0x11 0x13 0x15 0x91 0x93 0x03: 0x00 through 0x1f and 0x80 through 0x9f If a Parameters packet contains Q1-Q8, the DQ must be ignored and the quoting set established from must be used. TL = Transport Layer. The Initiator sets the TL parameter to 0x01 when it is running an application that must run under the Transport Layer. If the Responder's half of the application also utilizes the Transport Layer, it must also set the TL parameter to 0x01. The default value is 0x00. More information is in Section "J. B Plus Transport Layer." Q1-Q4 A mask indicating which characters in the range 0x00 through 0x1f the entity wants quoted. The mapping of bits to characters is: Bit: 7 6 5 4 3 2 1 0 ----- ---- ---- ---- ---- ---- ---- ---- ---- Q1: 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 Q2: 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f Q3: 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 Q4: 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f CompuServe Hosts currently use: Q1 Q2 Q3 Q4 0x14 0x00 0xd4 0x02 Q5-Q8 Same as Q1-Q4 for the range 0x80 through 0x9f. CompuServe Hosts currently use: Q1 Q2 Q3 Q4 0x00 0x00 0x50 0x00 11 12 DR Download Resume. 0x00 : Download Resume not supported 0x01 : Supports `Tr' Packet 0x02 : Supports `Tr' and `Tf' Packets 12 13 FI File Information. This parameter specifies the level of extended file handling supported. 0x00 = No extended file handling 0x01 = `TI' (File Information) Packet These are the currently defined Transport Layer Parameters. CompuServe reserves the right to define additional parameters at any time. Programs must be capable of accepting any number of parameters. Received parameters beyond the known ones must be ignored. If fewer Transport Parameters are received than the entity understands, then any beyond the last received parameter must be treated as if it was provided as 0x00, which must be its default value. See Section "F. Negotiation of Transport Parameters" for details on deciding what level of capabilities each entity is to use. b) Packet Type `T': File Transfer. The File Transfer Packet consists of three fields as follows: <Direction> <Data type> <File name> 1) Function. `D' = Download (Initiator -> Responder) `U' = Upload (Responder -> Initiator) `C' = Close. End of Upload or Download (Note: Additional "T" packets are defined later.) 2) Data type. `A' = 7-bit ASCII data. (Allows for End of Line conversion.) `B' = 8-bit Binary data. `I' = Image data. (This is hardware specific data and usually consists of some embedded header which describes the remainder of the file. It is always 8-bit binary data.) 3) File Name. This field is variable length and specifies the name of the file to be transferred. 13 14 A sample File Transfer packet using CRC Check Method is: <DLE> B 7 T D A S . C <ETX>0x57 0xff 0x10 0x42 0x37 0x54 0x44 0x41 0x53 0x2e 0x43 0x03 0x57 0xff 14 15 which specifies: o `T': File Transfer o `D': Download to the Responder o `A': This is an ASCII file o `S.C': The file name Note that there are no guidelines as to what the Responder is to do with the File Transfer packet. In particular, the implementor is free to locally verify the request, permit the file name to be changed, etc. If the Responder does not wish to comply with the request made in the File Transfer packet, a Failure Packet must be returned to the Initiator. c) Packet Type `N': Data. This is a data packet. The data being transferred is broken up into a series of <N> packets. There may be zero to the negotiated data block size. A count of zero does not imply end of file. d) Packet Type `F': Failure. This is the general Failure Packet. A Failure Packet may be sent at any time; the value of the <Sequence> field is ignored. The first character of the <Body> indicates the general nature of the failure, and the remainder may be a printable ASCII message further describing the condition. The following standard failures must be supported: `A': Abort. Usually sent if the user requests that the terminal program cease transferring data. `C': Capacity failure. Out of memory or disk. `E': Processing error. Any error other than described by another Failure Packet. `I': I/O error occurred. `M': File requested for Uploading is Missing (not found). `N': Unimplemented Packet Type was received. `S': Protocol Sequence Number failure. `r`: Transfer Resume failure. 15 16 When a Failure Packet is received, it must be acknowledged and the transfer aborted. Similarly, when a Failure Packet is sent, the sending entity must wait for the acknowledge to arrive. In addition, the entity which sends the Failure Packet must ignore all other packets while waiting for the acknowledgment to arrive. Once the Failure Packet is successfully transferred, both entities are expected to leave protocol mode. e) Optional `T' Packets. Several "T" Packets may optionally be supported. The support for these packets is specified by the DR, UR, and FI Transport Parameters. 1) Packet `Tr' : Download Resume. When the Responder receives the "TD" (Download Request) packet and the specified file already exits, it may attempt to resume the download which was aborted during a prior session. In order to do this, both entities must specify Transport Parameter DR > 0x00. If the Responder attempts the resumption, a `Tr' Packet is returned to the Initiator as follows: <DLE> B <Sequence> T r <Length> <crc> <ETX> <Trailer> where: <Length> = current number of bytes in Responder's existing file. <crc> = cyclic redundance check value of all existing data in Responder's file. Note that <crc> is evaluated utilizing the same algorithm as employed for packets. If the Standard Checksum is being used, then XMODEM CRC-16, initialized to -1, is used. Both <Length> and <crc> are transmitted as an ASCII decimal string and are both followed by at least a single space. The Initiator will perform the same <crc> calculation over <Length> bytes and compare the resulting CRC-16 values. If the calculated and `Tr' values agree, downloading continues with `N` Packets and Responder appends the data to the existing file. If the files match exactly, a `TC' (Transfer Close) packet is sent. 16 17 If the <crc> values do not match, or the Initiator's file be shorter than <Length> bytes, the Initiator's response depends on the value of the DR Transport Parameter: 0x01 - A `Fr' (Failed Resume) Packet is sent 0x02 - A `Tf' (CRC Failed) Packet is sent Some operating environments complicate Download Recovery. Since the Initiator has no knowledge of any data transformations, such as Carriage Return and Line Feed mappings, the Responder must take any such transformations into consideration when calculating <length> and <crc>. Under some environments, it is probably simpler to maintain this information during the download and preserve it in a file (Apple Macintosh (TM) for example.) 2) Packet `Tf' : Failed CRC The `Tf' packet is sent when a Resume request fails due to CRC failure. It will be sent only if the Responder and Initiator both specify Transport Parameter DR > 1. It implies that the transfer is to continue from the beginning of the file. Sample packet exchanges for transfer resumption: Initiator Responder Comments --------- --------- ----------------- DR = 0x01 or 0x02: TD ---------------> Download Request <--------------- Tr Resume Download N ---------------> CRC matched ... TC ---------------> End of transfer DR = 0x01: TD ---------------> Download Request <--------------- Tr Resume Download Fr ---------------> Resume failed DR = 0x02: TD ---------------> Download Request <--------------- Tr Resume Download Tf ---------------> CRC mismatched <--------------- ACK Transfer entire N ---------------> Data ... TC ---------------> End of transfer 17 18 3) Packet `TI' : File Information. The `TI' Packet is transmitted by the File Sender, provided that both entities have their Transport Parameter FI > 0x00. It is used to convey specific data concerning the file as it exists on the Sending entity. The format of the `TI' Packet is as follows: <Lead-in> <Sequence> T I <data type> <compression > <file length> <creation date> <creation time> <modification date> <modification time> <true name length> <true name> <Trailer> where: <data type> : A = ASCII, B = Binary. <compression> : Specifies how the file is compressed during transmission (has nothing to do with the content of the file). 0x00 = not compressed (other values reserved for future use by CompuServe) <file length> : Current length of the file being sent. (Actual number of file data bytes being sent, not the number of compressed bytes). This value is passed for display display or media check only. <zone> : Minutes offset from UCT of Sender. <creation date> : Date the file was created. ASCII decimal string, yyyymmdd <creation time> : Time of day the file was created. ASCII decimal string, seconds since midnight. <modification date> : Date the file was last modified. Same format as <creation date>. (`0' if unknown) <modification time> : Time of day the file was last modified. Same format as <creation time>. (`0' if unknown) <true name length> : Number of bytes in <true name>. (This is a single binary byte.) <true name> : The actual file name with any device, directory, or other ancillary information removed. 18 19 It is not necessary that all fields be transmitted. A sample TI packet (file information only) is: "A?55387 300 19880422 52480 0 0 ?BPLUS.DOC" | | | | 0x00 EST 7:18 PM 0x09 19 20 D. B Plus Control Sequences The B Plus Protocol defines several Control Sequences in addition to packets. Control Sequences are used to manage the progress of the B Plus Session. 1. Enquire The Enquire Control Sequence consists of the single character: <ENQ> 0x05 It is sent in one of two circumstances: o The Responder is in terminal mode and the Initiator wants to synchronize its <Sequence> number, and to tell the Responder to set up for normal B Protocol. When the <ENQ> is received, the Responder must: > Prepare for 512 byte data blocks > Prepare for Standard Checksum > Initialize its Sequence to 0x30 > Transmit the string: <DLE> + + <DLE> 0x30 > Return to terminal mode. Note: The terminal program definitely should NOT enter B Protocol mode when the <ENQ> is received. Note: It is possible that some remote implementations of B Plus require longer time-outs. This is supported by including an "R" in the <ENQ> response as follows: <DLE> + + R <DLE> 0 The presence of the "R" causes the host to double its time-out values. o The entity sending the packet has received a Negative Acknowledge, or timed out while waiting for an Acknowledge. The response to an <ENQ> during a B Plus session is a Positive Acknowledge. 20 21 2. Positive Acknowledge When a correctly checked and sequenced packet is received, a Positive Acknowledge is transmitted. This consists of: <DLE> Sequence where Sequence is the Sequence number of the last validly received packet. 3. Wait The Wait Control Sequence informs the receiving entity that the sending entity requires additional time to process what it has received. Wait is sent as: <DLE> ; 4. Negative Acknowledge When the receiving entity receives a packet with an unexpected <Sequence>, improper checksum or times out, it sends a Negative Acknowledge to the other entity. This consists of the single byte: <NAK> 0x15 When the sending entity receives a NAK, it initiates a Re synchronization Process by sending two <ENQ> characters and waiting until it receives two identical Positive Acknowledgments. 5. Panic Abort The B Plus Protocol recognizes a series of four <DLE> characters as a panic abort. The need for such a facility can arise if the Responder computer becomes locked up during a transfer, and it is necessary to reboot. Since <DLE> is really control-P, sending it is a very simple procedure. In addition, the Initiator recognizes the sequence: <DLE> + while waiting for a Positive Acknowledge as being incorrect, and will abort the transfer. This can happen as above, but before the operator can press control-P the Initiator sends an <ENQ> during a down-load to find out what is happening. The Responder, now in terminal emulation mode, responds 21 22 with: <DLE> + + <DLE> 0 and the Initiator will abort cleanly. For this reason it is essential that any B Plus implementation observe the rules for <ENQ>: If in terminal mode, send <DLE> + + <DLE> 0; otherwise send <DLE> Sequence. 22 23 D. Negotiation of Transport Parameters The Initiator begins a B Plus protocol session by sending: <ENQ> while the Responder is in terminal mode. The Responder sets itself up for: o Standard Checksum o Default Quoting o 512 byte data block o Sets its Sequence to 0x30 (`0') o transmits the sequence: <DLE> + + <DLE> 0 o returns to terminal mode. The Initiator, detecting the `<DLE> + +', sends a Transport Parameters Packet using Standard Checksum and quoting of 0x00 through 0x1f and 0x80 through 0x9f. When the Responder properly receives this packet, it must transmit a Transport Parameters Packet indicating its own parameter settings. Once the Initiator Acknowledges the Responder's Transport Parameters Packet, each entity then establishes its operating configuration based on the minimal matching parameters. In particular, the Initiator and Responder each choose the minimum of: Own Other's Parameter Parameter WS WR <- Note the cross-comparison of WR WS <- these parameters. BS BS CM CM TL TL DR DR UR UR FI FI and the inclusive-or of the Quoting Sets. For example, if the Initiator sends the sequence: 0x01 0x01 0x08 0x01 0x01 0x00 0x14 0xd4 0x00 0x00 <- Quoting Set 0x00 0x00 0x00 0x00 <- 0x01 0x00 0x00 <- DR UR FI 23 24 and the Responder returns: 0x00 0x01 0x04 0x00 0x01 0x00 0x54 0xd4 0x00 0x00 <- Quoting Set 0x40 0x50 0x00 0x00 <- The following parameters are used by both entities: Parameter Initiator Responder WS 0x01 0x00 Initiator sends 1 packet ahead. WR 0x00 0x01 Responder sends 1 packet and waits for Positive Acknowledge BS 0x04 0x04 Both use 512 byte data body CM 0x00 0x00 Standard Checksum The following characters will be quoted when transmitted by either entity: 0x01 0x03 0x05 0x10 0x11 0x13 0x15 0x81 0x91 0x93 SOH ETX ENQ DLE XON XOFF NAK SOH XON XOFF This would be the quoting used for a Responder having a modem which treats the 0x01 as "Escape to command mode" and in addition responds to flow control characters (0x11 0x13 0x91 0x93). Since the Responder did not transmit the DR, UR, and FI parameters, the initiator sets them to 0x00. The next packet transmitted will be expected to obey the negotiated Transport Parameters. 24 25 F. Terminal Program States This section describes the expected state transitions for a terminal program which supports the B Plus Protocol. Current State Event Action Next State ------------------------------------------------------------ Terminal <ENQ> Rcvd. Return: Terminal <DLE> + + <DLE> 0 Set up for normal B Protocol <DLE> Rcvd. None. DLE_Seen <Other> Process as an ASCII char. Terminal ------------------------------------------------------------ DLE_Seen <B> Rcvd. None. Get_First_Packet <other> Rcvd. None. Terminal ------------------------------------------------------------ Get_First_Packet Receive the Packet Valid packet : <+> Process Transport Terminal Parameters; set up for B Plus if successful exchange <T> Invoke Transfer Terminal Process <other> Return Failure Terminal Packet N ------------------------------------------------------------ 25 26 G. Wait for Acknowledge The Wait for Acknowledge procedure is the work-horse of the B PLUS Protocol. It is implemented as a Finite State Automaton having thirteen states as follows: State Description ---------------- ---------------------------------------- S_Get_DLE Wait for <DLE> from Responder. S_DLE_Seen Get character following the <DLE>. S_DLE_B PLUSSeen Receive Packet Sequence Number. S_Get_Data Receive data portion of packet. S_Get_Check Receive check value. S_Get_CRC Receive CRC. S_Verify_CRC Compare received to calculated CRC. S_Verify_CKS Compare received to calculated checksum. S_Verify_Packet Check for failure packet; verify packet sequence number. S_Send_NAK Count error; send <NAK> to Responder. S_Send_ACK Send ACK sequence to Responder. S_Send_ENQs Count error; Send two <ENQ> characters to Responder. S_Resend_Packets Retransmit packet(s) to Responder. The State Transition table follows: State Event Action Next State ---------------- ------------ ----------------- ----------- S_Get_DLE <DLE> ... S_DLE_Seen <NAK> ... S_Send_ENQ <ENQ> ... S_Send_ACK <ETX> ... S_Send_NAK timeout ... S_Send_ENQ other ... S_Get_DLE S_DLE_Seen <digit> Release Packet return success -or- If <ENQ> sent S_Resend_Packets else S_Get_DLE <B> ... S_DLE_B PLUSSeen <;> ... S_Get_DLE <ENQ> ... S_Send_ACK timeout ... S_Send_ENQ other ... S_Get_DLE S_DLE_B PLUSSeen <ENQ> ... S_Send_ACK <char> Save <char> Intit Check Value S_Get_Data timeout ... S_Send_NAK 26 27 S_Get_Data <ETX> ... S_Get_Check timeout ... S_Send_NAK <ENQ> ... S_Send_ACK <char> Add <char> to check value Store <char> in buffer S_Get_Data S_Get_Check <char> If Check Method is CRC_16 S_Get_CRC Checksum S_Verify_CKS timeout ... S_Send_NAK S_Get_CRC <char> Add <char> to Received CRC S_Verify_CRC timeout ... S_Send_NAK S_Verify_CRC ... If Received CRC = Calc. CRC S_Verify_Packet else S_Send_NAK S_Verify_CKS ... If Received CKS = Calc. CKS S_Verify_Packet else S_Send_NAK S_Verify_Packet ... If Saved <char> = expected Seq number Return size -or- If Packet Type = `F' Return size If duplicate packet S_Send_ACK else S_Send_NAK S_Send_NAK ... Count Receive Error If too many errors Return failure If not Aborting then Send <NAK> S_Get_DLE S_Send_ACK ... IF not Aborting then Send ACK sequence S_Get_DLE S_Send_ENQ ... Send <ENQ><ENQ> S_Get_DLE S_Resend_Packets ... Send all un-ACKed packets. S_Get_DLE 27 28 Note: "Aborting" means that a Failure Packet has been sent. If Failure Packet has been sent, all outstanding packets are assumed to be ACKed. 28 29 H. Packet Send Ahead One of the most useful features of the B Plus Protocol, from the user's point of view, is its ability to send more than one packet ahead of receiving the acknowledgment of the oldest one. This improves through-put by overlapping the I/O performed on both the Initiator and Responder computers, including the time required for the Responder computer's acknowledgment to arrive at the Initiator and wake up the Initiator's application program. The Packet Send Ahead is accomplished by keeping a set of buffers in memory, one for each permitted outstanding packet. Each buffer contains the corresponding packet's <Sequence>, count, and the data itself. In addition a counter of outstanding packets (i.e., not yet ACKed) is maintained and incremented whenever a packet is sent for the first time. Two indices into the set of buffers are used to keep track of the Send Ahead status. One keeps track of which buffer holds the oldest packet and the other which buffer may be filled with new data. When a packet is about to be sent, the outstanding count is checked to see if the maximum number of outstanding packets has been reached. If so, a routine (GetACK) is invoked which waits for the ACK to arrive for the oldest outstanding packet. Several possibilities exist: o The oldest packet is ACKed. In this case, move the Oldest Outstanding index to point to the next oldest packet and decrement the outstanding packet count. o Some other packet in the buffer pool has been ACKed. This implies an ACK has been missed. Move the Oldest Outstanding index to point to the buffer following the received ACK, and decrement the Outstanding Count accordingly. o A NAK is received. Retransmit all packets which are outstanding. If the Outstanding count is still at the maximum, stay in GetACK. Finally, a procedure is necessary which calls GetACK until either a failure occurs or the Outstanding count is zero. The Send Ahead Process proceeds as follows: Receiver's 29 30 Packet Sequence Buffer Outstanding Response 1 `1' 0 1 ... 2 `2' 1 2 ... 3 GetACK ACK `1' `3' 0 2 ... 4 GetACK ACK `2' `4' 1 2 ... 5 GetACK ACK `3' `5' 0 2 ... (Last) GetACK ACK `4' 1 ... GetACK ACK `5' 30 31 I. Implementation Considerations 1. Port Parameters The CompuServe B Plus Protocol requires that the communication path provide for 8-bit data. This is frequently referred to as "8N1" port parameters. Often terminal programs operate in "7E1" mode (7 bits, even parity), necessitating a shift from 7E1 to 8N1 when entering B/B Plus mode. However, such shift in parameters is often difficult to accomplish, particularly in today's multitasking and LAN environments. With buffered port I/O, it is difficult to make the parameter shift without compromising data already in the buffer. It is highly recommended that a terminal program initialize its port to 8N1. If necessary, the 7E1 can be accomplished by software in the terminal emulation code. This can be done by providing a simple routine which the terminal emulation program uses to obtain input from the host. The routine simply strips off the parity bit by "anding" with 0x7f. Similarly, output to the port from the terminal program can append a parity bit as needed. This can be done by a simple 256 byte table, or using the parity test instruction provided in some microprocessors. 2. Time-Out A per-character time-out of ten seconds should be used. Using anything less can result in a loss of good control over the exchange of packet and control sequences. If conditions over a switched network degrade sufficiently, a small time out can lead to excessive retransmissions of data. On the other hand, longer time-out values will result in a more sluggish detection of protocol breakdown. The receiving entity should be silent when a time-out occurs. That is, a <NAK> should not be sent when a time-out occurs while receiving a packet. The reason is that under severely degraded network loading it may happen that it takes longer for the sending entity's data to arrive than the receiving entity's time-out interval. This can lead to many kinds of situations in which there is excessive retransmission of data. The question to be answered by the implementor is: "Am I more concerned about how fast I can shut down the transfer when the sending entity goes away than I am about getting the transfer to occur regardless of how long it takes?" If the answer is that response to a vanished sender is more important, then send a <NAK> when a time-out occurs. 31 32 If getting the job done is more important, then don't send the <NAK> on time-out. 32 33 3. Packet Size The following chart shows the percentage of housekeeping overhead for various packet sizes (not including quoted characters): Packet Data Packet Transmission Time Size Size Useful Overhead 300 1200 2400 9600 ---- ------ ------ -------- ---- ---- ---- ---- 128 135 94.8 % 5.2 % 4.5 1.1 0.6 0.2 256 263 97.3 % 2.7 % 8.8 2.2 1.1 0.3 384 391 97.7 % 2.3 % 13.0 3.3 1.6 0.4 512 519 98.7 % 1.3 % 17.3 4.3 2.2 0.5 640 647 98.9 % 1.1 % 21.6 5.4 2,7 0.7 768 775 99.1 % 0.9 % 25.8 6.5 3,2 0.8 896 903 99.2 % 0.8 % 30.1 7.5 3.8 0.9 1024 1031 99.3 % 0.7 % 34.4 8.6 4.3 1.1 2048 2055 99.6 % 0.03 % 68.5 17.1 8.6 2.1 At first glance it might seem reasonable to always use the largest data packets. However, consideration should be given to the amount of time required to recover from a transmission error. For example, using 1024 byte data packets at 300 baud, over a minute of excessive transmission time would result (two packets) each time an error occurred. Experience shows that keeping the packet transmission time to between four and five seconds results in a reasonably comfortable recovery time. So, for best over-all performance, the following packet sizes are recommended: Baud Size ---- ---- 300 128 1200 512 2400 1024 9600 2048 (with 4 or 5 packet send-ahead) 4. Controlling Excessive Retransmissions Over a very noisy link the send-ahead nature of B Plus might cause the performance to degrade due to retransmission of packets. To circumvent this degradation, the following heuristic is recommended: Initialize SA_Error_Count to zero. If packets are retransmitted, increment SA_Error_Count by 3. If SA_Error_Count is greater than or equal to 12, drop out of Send-Ahead mode (i.e., revert to send and wait mode). When a packet is ACKed, and SA_Error_Count is greater than zero, decrement SA_Error_Count by one. 33 34 The values (increment by 3, limit of 12, decrement by 1) can be varied in accord with the implementor's experience, perhaps being established by user-definable parameters. 5. Flow Control When sending data to a CompuServe node, the sender may be told to stop sending. This can happend if the system (host and/or network) is too busy to support the full data rate in use. If the terminal program does not honor the flow contol, lost data and excessive retrnnmissions are likely to result. If B Plus being used, the terminal program may also flow control its incoming data stream. 34 35 J. B Plus Transport Layer Some distributed applications (that is, applications in which the Initiator and Responder each perform some of the work) require that blocks of information be exchanged. Running such applications over normal communication channels can cause loss or altering of data, yielding unpredictable results. To alleviate this possibility, the B Plus Protocol provides the ability to use the underlying packet structure to exchange blocks of data with error detection and retransmission. Entering the Transport Layer operation is more complicated than the File Transfer mode previously described: o The user invokes a CompuServe application o The application program transmits a CompuServe Application Protocol escape sequence. o The user's terminal program responds with an escape sequence which informs the host application that it must use the Transport Layer. o The host program initializes its B Plus routines, setting the Transport Layer parameter to 0x01. o The terminal program waits until its own B Plus routines have been initialized, also setting the Transport Layer parameter to 0x01. o Once the host and remote B Plus routines have exchanged their Transport Layer Parameters, the Transport Layer is in effect. The succeeding action is a function of the application. From an implementation standpoint, the primary differences from the B Plus Protocol so far described are: o Separate Packet Sequence Numbers are maintained for sending and receiving. o Received Packets are placed in a first-in-first-out queue. o Another level of software is placed between the packet handlers and the application. This level is responsible for sending and receiving blocks of data, packaging them into protocol-sized packets. The following Packet Types are used in the Transport Layer: `M': This is a data packet; another data packet follows. `L': This is the last data packet for the current block. A Failure Packet will terminate the transport layer for both entities. 35 36 K. Initiation of Master Mode The following state machine describes the process of a host entity initiating a B Plus Session. Its starting state is Initiate_B PLUSProtocol. Note: CompuServe reserves the right to restrict implementation of this process, termed "Master Mode". It is necessary for interested parties to obtain a license from CompuServe. State Received Action Next State ------ -------- ---------------------- ---------- Initiate_B PLUSProtocol Set ENQ_Count to 0 Set Standard Checksum Set 512 byte Data Block Set default quote set Clear Plus_Seen and Plus_Plus flags Send_ENQ ----------------------------------------------------------- Send_ENQ ... Increment ENQ_Count If ENQ_Count > 5 then Exit with Failure Transmit <ENQ> Get_DLE ----------------------------------------------------------- Get_DLE <DLE> ... Get_Digit <+> If Plus_Seen true, then set Plus_Plus ... Get_DLE <R> Set Relaxed_Timing Get_DLE timeout Send_ENQ ------------------------------------------------------------ Get_Digit <digit> Initialize Send and Receive Sequence Numbers Send_Parameters <+> Set Plus_Seen Get_DLE timeout ... Send_ENQ ------------------------------------------------------------ 36 37 Send_Parameters ... If Plus_Seen true, then if Plus_Plus true, then set to quote 0x00-0x1f and 0x80-0x9f if Send Parameters Packet Failed then Exit with Failure If Receive Parameters Packet Failed then Exit with Failure Establish session's parameters Exit with Success ------------------------------------------------------------- 37 38 L. Supporting the Various B Protocol Versions There are four versions of B Protocol which an implementor must be aware of. Any new implementation should follow the B Plus Protocol as described in this document to ensure full compatibility with all existing CompuServe Host software. The four versions are: o "Classic" B Protocol o An interim version of B Plus (called Interim B) o B Plus The differences are: Initial <ENQ> response: Classic B <DLE> <digit> Interim B: <DLE> + <DLE> <digit> B Plus: <DLE> + + <DLE> <digit> or <DLE> + + R <DLE> 0 Default Quoting Sets: Classic B: 0x00 -> 0x1f Interim B: 0x00 0x03 0x05 0x10 0x11 0x13 0x15 B Plus: 0x03 0x05 0x10 0x11 0x13 0x15 Extended Quoting: Classic B: none Interim B: Specified by the DQ Parameter: 0x00 : 0x00 0x03 0x05 0x10 0x11 0x13 0x15 0x01 : 0x03 0x05 0x10 0x11 0x13 0x15 0x02 : 0s03 0x05 0x10 0x11 0x13 0x15 0x91 0x93 0x03 : 0x00-0x1f and 0x80-0x9f B Plus: Established by the Q1 through Q8 parameters. Quoting of the Parameters Packet: Classic B: No parameters packet Interim B: 0x00 -> 0x1f B Plus: 0x00 -> 0x1f and 0x80 -> 0x9f Response to a <NAK>: Classic B: Retransmit the last packet Interim B: Resynchronize with <ENQ><ENQ>, wait for two identical ACK sequences, retransmit as necessary. B Plus: Same as Interim B CompuServe Host software will support all three B Protocol versions. In order to do so, it relies on the initial response to <ENQ> to determine what version is being used in the terminal 38 39 software. The defaults given in Section D.1 ("Enquire") are intended to reflect "Classic" B Protocol. If the Host receives <DLE> <+> <DLE> <digit> it sends its Transport Parameters Packet using "Classic" B data quoting (0x00 -> 0x1f). If two "+" characters are received, it will quote 0x00 -> 0x1f and 0x80 -> 0x9f. This is done to maximize the chances of getting the packet through most modems and networks. Once the Transport Parameters Packets have been successfully exchanged, the Host software uses the negotiated quoting set, and the remote is expected to do likewise. Negotiation of quoted characters allows implementors to provide configuration set up to cope with a wide variety of modems, operating system, network, and other situations which can adversely affect through transmission of 8-bit binary data. 39 40 M. Check Value Calculation 1. Standard B Protocol Checksum. The following C-language code fragment illustrates the Standard Checksum calculation: int checksum; do_checksum (ch) unsigned int ch; { checksum = checksum << 1; if checksum > 0xff checksum = (checksum & 0xff) + 1; checksum += ch & 0xff; if checksum > 0xff checksum = (checksum & 0xff) + 1; }; 2. XMODEM-Style CRC-16. /* * Calculates XMODEM-style CRC (uses the CCITT V.41 * polynomial but * completely backwards from the normal bit ordering). */ static unsigned crc_xmodem_tab[] = { 0x0000,0x1021,0x2042,0x3063,0x4084,0x50A5,0x60C6,0x70E7, 0x8108,0x9129,0xA14A,0xB16B,0xC18C,0xD1AD,0xE1CE,0xF1EF, 0x1231,0x0210,0x3273,0x2252,0x52B5,0x4294,0x72F7,0x62D6, 0x9339,0x8318,0xB37B,0xA35A,0xD3BD,0xC39C,0xF3FF,0xE3DE, 0x2462,0x3443,0x0420,0x1401,0x64E6,0x74C7,0x44A4,0x5485, 0xA56A,0xB54B,0x8528,0x9509,0xE5EE,0xF5CF,0xC5AC,0xD58D, 0x3653,0x2672,0x1611,0x0630,0x76D7,0x66F6,0x5695,0x46B4, 0xB75B,0xA77A,0x9719,0x8738,0xF7DF,0xE7FE,0xD79D,0xC7BC, 0x48C4,0x58E5,0x6886,0x78A7,0x0840,0x1861,0x2802,0x3823, 0xC9CC,0xD9ED,0xE98E,0xF9AF,0x8948,0x9969,0xA90A,0xB92B, 0x5AF5,0x4AD4,0x7AB7,0x6A96,0x1A71,0x0A50,0x3A33,0x2A12, 0xDBFD,0xCBDC,0xFBBF,0xEB9E,0x9B79,0x8B58,0xBB3B,0xAB1A, 0x6CA6,0x7C87,0x4CE4,0x5CC5,0x2C22,0x3C03,0x0C60,0x1C41, 0xEDAE,0xFD8F,0xCDEC,0xDDCD,0xAD2A,0xBD0B,0x8D68,0x9D49, 0x7E97,0x6EB6,0x5ED5,0x4EF4,0x3E13,0x2E32,0x1E51,0x0E70, 0xFF9F,0xEFBE,0xDFDD,0xCFFC,0xBF1B,0xAF3A,0x9F59,0x8F78, 0x9188,0x81A9,0xB1CA,0xA1EB,0xD10C,0xC12D,0xF14E,0xE16F, 0x1080,0x00A1,0x30C2,0x20E3,0x5004,0x4025,0x7046,0x6067, 0x83B9,0x9398,0xA3FB,0xB3DA,0xC33D,0xD31C,0xE37F,0xF35E, 40 41 0x02B1,0x1290,0x22F3,0x32D2,0x4235,0x5214,0x6277,0x7256, 0xB5EA,0xA5CB,0x95A8,0x8589,0xF56E,0xE54F,0xD52C,0xC50D, 0x34E2,0x24C3,0x14A0,0x0481,0x7466,0x6447,0x5424,0x4405, 0xA7DB,0xB7FA,0x8799,0x97B8,0xE75F,0xF77E,0xC71D,0xD73C, 0x26D3,0x36F2,0x0691,0x16B0,0x6657,0x7676,0x4615,0x5634, 0xD94C,0xC96D,0xF90E,0xE92F,0x99C8,0x89E9,0xB98A,0xA9AB, 0x5844,0x4865,0x7806,0x6827,0x18C0,0x08E1,0x3882,0x28A3, 0xCB7D,0xDB5C,0xEB3F,0xFB1E,0x8BF9,0x9BD8,0xABBB,0xBB9A, 0x4A75,0x5A54,0x6A37,0x7A16,0x0AF1,0x1AD0,0x2AB3,0x3A92, 0xFD2E,0xED0F,0xDD6C,0xCD4D,0xBDAA,0xAD8B,0x9DE8,0x8DC9, 0x7C26,0x6C07,0x5C64,0x4C45,0x3CA2,0x2C83,0x1CE0,0x0CC1, 0xEF1F,0xFF3E,0xCF5D,0xDF7C,0xAF9B,0xBFBA,0x8FD9,0x9FF8, 0x6E17,0x7E36,0x4E55,0x5E74,0x2E93,0x3EB2,0x0ED1,0x1EF0}; 41 42 unsigned CRC; UpdCrc (Byte) unsigned int ByteC; { CRC = crc_xmodem_tab [(CRC >> 8 ^ Byte) & 0xff] ^ (crc << 8); }; 42 43 3. CCITT CRC-16 and CRC-32 /* * CCITT CRC-32 */ typedef unsigned long int UNS_32_BITS; /* Need an unsigned type capable of holding 32 bits; */ #define CRC_32_POLY 0xedb88320L #define CCITT_CRC_32_COMPARE 0xdebb20e3 static UNS_32_BITS crc_32_tab[] = { /* CRC polynomial 0xedb88320 */ 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3, 0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988, 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91, 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de, 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7, 0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, 0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5, 0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172, 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b, 0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940, 0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59, 0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116, 0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f, 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924, 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, 0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a, 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433, 0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818, 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01, 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e, 0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457, 0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c, 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65, 0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2, 0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb, 0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0, 0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9, 0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086, 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f, 0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, 0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad, 0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a, 0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683, 0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8, 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1, 0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe, 0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7, 43 44 0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc, 0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5, 0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252, 0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b, 0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60, 0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79, 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236, 0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f, 0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04, 0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d, 0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a, 0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713, 0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38, 0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21, 0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e, 0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777, 0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c, 0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45, 0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2, 0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db, 0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0, 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9, 0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6, 0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf, 0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94, 0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d }; 44 45 /* * CCITT CRC-16 */ #define CRC_CCITT_POLY 0x8408L /* X^16+X^12+X^5+X^0 */ #define CCITT_CRC_16_COMPARE 0xf0b8 static UNS_32_BITS crc_ccitt_tab[] = { /* CRC-CCITT polynomial 0x8408 */ 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf, 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7, 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e, 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876, 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd, 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5, 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c, 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974, 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb, 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3, 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a, 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72, 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9, 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1, 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738, 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70, 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7, 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff, 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036, 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e, 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5, 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd, 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134, 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c, 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3, 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb, 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232, 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a, 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1, 0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9, 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330, 0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78 }; 45 46 /* * This macro calculates an updated CRC value for either the * CCITT CRC-16 or CCITT CRC-32 polynomials. It will ___ not work * for the XMODEM CRC-16. * * octet = new 8-bit value to be added to the CRC * crc = current CRC value * tab = either crc_32_tab or ccitt_crc_tab */ #define updcrc(octet, crc, tab) (tab[((crc) ^ (octet)) & 0xff] ^ ((crc) >> 8)) /* * The calculation process is as follows: * * transmitter receiver * ---------------------- ----------------------------------- * preset to -1 preset to -1 * for all data octets for all octets, including rec'd crc * updcrc updcrc * invert (xor 0xffffffff) compare (0xf0b8 if CCITT CRC-16, * transmit crc, LSB first 0xdebb20e3 if CCITT CRC-32) * */ 46 47 N. Interrogation Although not part of the B Plus Protocol, implementors are urged to support the CompuServe Interrogation Sequence. This process passes information to the CompuServe Host to identify the various options supported by the terminal program. Host software will generally perform an Enquire (Section D.1) first to determine if the terminal program supports B Protocol. If B Protocol ("Classic," Interim B, or B Plus) is supported, the host then sends the sequence: <ESC> I When the terminal program receives this sequence of characters, it transmits an Interrogation Response as follows: <#> <<Product> <F-codes> <+> <Check> <CR> where: <#> Identifies the string as an Interrogation Response <Product> Identifies the remote software as follows: <PID> <:> <Ver> <:> <Ops> where: <PID> = Product Id (1 to 6 char.) <Ver> = Version (1 to 12 char.) <Ops> = Operating System (1 to 3 char.) Example: WINCIM:1.0.b7:W31 identified CompuServe WinCIM version 1.0.b7 running under Windows 3.1. The PID and Ops fields will be assigned by CompuServe Marketing. 47 48 <F-codes> A series of character fields giving the options supported. Each <F-code> is followed by a comma. The currently recognized <F-codes> are as follows: Cursor/Screen Control AC : ANSI Color CA : ANSI/VT100 Cursor Control CC : VIDTEX/VT52 Cursor Control CW : Wide mode (Double width characters invoked by <ESC> <m> uninvoked by <ESC> <l> (lower case L) SSyx : Screen Size; y gives number of lines + 31, x gives number of columns Plus 31. SS7o identifies a 24 line by 80 column screen. It is suggested that the SS field always be present. Note: The SS code is not currently utilized by CompuServe software. Graphics GF : GIF graphics GH : High resolution RLE graphics GJ : JPEG graphics GM : Medium resolution RLE graphics NF : Full NAPLPS graphics GIvcpwwwhhh : GIF Capabilities v = highest GIF supported: 0 = 87a 1 = 89a c = color bits/pixel p = color resolution www = width in pixels (hex) hhh = heighth in pixels (hex) Protocols AP : Recognizes and properly responds to the CompuServe Application Protocol escape sequences CB : Capture Buffer PB : B Protocol (includes Interim B and B Plus) PX : XMODEM 48 49 International CHd : Character Set COddd : Country Code LAd : Language Preference (Note: d represents decimal digits) Miscellaneous HC : Hard Copy (printer connected) XX : Ignored All other <F-codes> are reserved for future use. <Check> This is a check value derived by adding together all characters in the Interrogate Response up to and including the +, truncating the sum to 16 bits, and converting it to an ASCII digit string. <CR> This is the ASCII Carriage Return and serves to terminate the Interrogate Response. If the <Check> value does not match, the host will send another <ESC> I and compare the string it receives to the previous one. If the two strings match, it is accepted, otherwise the <ESC> I and matching will continue for ten trials before giving up. A sample Interrogate Response is: #PC3:3.2a:D,CC,GH,GM,GF,PB,+1035<CR> which specifies: o PC3:3.2a:D CompuServe PC3 v. 3.2a for DOS o CC Supports standard VIDTEX/VT52 cursor controls o GH Supports high-resolution RLE graphics o GM Supports medium-resolution RLE graphics o GF Supports GIF o PB Supports B Protocol o 1035 Sum of "#PC3:3.2a:D,CC,GH,GM,GF,PB,+" 49 50 For additional information concerning the Interrogation Response, please contact CompuServe Incorporated, Microcomputer Software Development. 50 51 Index B Plus Control Sequences, 20 B Plus Packet Types, 10 B Plus Transport Layer., 35 B Protocol Versions, 38 Calculating CCITT CRC-16, 45 CCITT CRC-32, 43 Standard B Protocol Checksum, 40 XMODEM-Style CRC-16, 40 Check Value, 9 Check Value Calculation, 40 Controlling Excessive Retransmissions., 33 Enquire, 20 Flow Control, 34 History of CompuServe B Protocol, 3 Initiation of Master Mode, 36 Master Mode, 36 mplementation Considerations, 31 Negative Acknowledge, 21 Negotiation of Transport Parameters, 23 Notation, 4 nterrogation., 47 Optional `T' Packets., 16 Packet Structure, 5 Body, 5 Lead-in, 5 Sequence, 5 Trailer, 5 Type, 5 Type, 15 'F' - Failure, 15 'L' - Last transport data, 35 'M' - More transport data, 35 `+': Transport Parameters., 10 `N': Data., 15 `T': File Transfer., 13 `Tf' : Failed CRC, 17 `TI' : File Information., 18 `Tr' : Download Resume, 16 Packet Send Ahead, 29 Packet Size., 33 Panic Abort., 21 Port Parameters, 31 Positive Acknowledge, 21 Quoting of characters, 7 51 52 Sample B Plus packet, 6 Standard B Protocol Checksum, 9 Supporting the Various B Protocol Versions, 38 Terminal Program States., 25 Time-Out, 31 Time-Outs Relaxed, 20 Transport Layer, 35 Wait for Acknowledge, 26 Wait., 21 XMODEM-Style CRC-16., 9 52