Dec 302017
Documentation for Compuserve B+ Protocol.
File BPDOC.ZIP from The Programmer’s Corner in
Category Various Text files
Documentation for Compuserve B+ Protocol.
File Name File Size Zip Size Zip Type
BPLUS.DOC 86154 21964 deflated

Download File BPDOC.ZIP Here

Contents of the BPLUS.DOC file

The CompuServe B Plus Protocol

November 18, 1993


Russ Ranshaw

11/18/93 04:14 PM


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



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

o Provision of a mechanism to exchange transport and
application parameters.



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:

specifies the ASCII code for Data Link Escape.

o The C-language notation for hexadecimal values will
be used. Thus, the 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".



C. B Plus Packets

1. B Plus Packet Structure

B Plus Protocol packets consist of five parts as follows:

o Lead-in
o Sequence <0x30 through 0x39>
o Type
o Body
o Trailer
(may be followed by )

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 are included in
the Check Value. Note that and are
Quoted (Sec. C2), and that the Check Value is computed on
the actual data bytes rather than their quoted replacements
(the quoting is not included). Hence, if the character
0x13 is to be sent, it is sent as but the value
0x13 is included in the Check Value.

If Standard Checksum is used, consists of a
quoted byte.

If the XMODEM CRC-16 is used, 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

If CCITT CRC-16 is used, 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 (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 to work. Likewise,
all B Plus implementions must function properly if is
sent by the remote, even if the given implementation does
not use itself.


A sample B Plus packet, sent using the Standard Checksum, is
as follows:

B 7 T D A S . C 0x2A
0x10 0x42 0x37 0x54 0x44 0x41 0x53 0x2E 0x43 0x03 0x2A

Lead-in = B
Sequence = 7
Type = T
Body = DAS.C
Trailer = 0x2A

If the packet was sent using the XMODEM CRC-16 option, the
Check Value would be 0x57 0xFF instead of 0x2A.


2. Quoting of characters

The B Plus Protocol quotes certain ASCII control characters.
The default set of quoted characters is:

o 0x03
o 0x05
o 0x10
o 0x11
o 0x13
o 0x15

If B Plus is in effect, the following characters are added
to the default quoting set:

o 0x1E ()
o 0x91 ( + 0x80)
o 0x93 ( + 0x80)

The quoting mechanism uses the character to prefix the
quoted character. The quoted character with 0x40 added
follows the . For example, is quoted as:

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:

((char and 0x1f) + 0x60)

Hence, 0x93 is quoted as:

0x10 0x73



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

Get a character.
If the character is
Get next character.
If character is less than 0x60
character = character and 0x1f
character = (character and 0x1f) + 0x80


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


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 = 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 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.


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."

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

Same as Q1-Q4 for the range 0x80 through 0x9f.
CompuServe Hosts currently use:

Q1 Q2 Q3 Q4
0x00 0x00 0x50 0x00


Download Resume.
0x00 : Download Resume not supported
0x01 : Supports `Tr' Packet
0x02 : Supports `Tr' and `Tf' Packets


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

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
`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.


A sample File Transfer packet using CRC Check Method is:

B 7 T D A S . C 0x57 0xff

0x10 0x42 0x37 0x54 0x44 0x41 0x53 0x2e 0x43 0x03 0x57 0xff



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 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 field is
ignored. The first character of the 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

`N': Unimplemented Packet Type was received.

`S': Protocol Sequence Number failure.

`r`: Transfer Resume failure.


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:

B T r


= current number of bytes in Responder's
existing file.

= cyclic redundance check value of
all existing data in Responder's file.

Note that 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 and are transmitted as an ASCII
decimal string and are both followed by at least a single

The Initiator will perform the same calculation over
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.


If the values do not match, or the Initiator's file
be shorter than 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 and .
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


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:


: A = ASCII, B = Binary.

: 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)

: 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.

: Minutes offset from UCT of Sender.

: Date the file was created.
ASCII decimal string, yyyymmdd

: Time of day the file was created.
ASCII decimal string, seconds
since midnight.

: Date the file was last modified.
Same format as .
(`0' if unknown)

: Time of day the file was last
modified. Same format as
. (`0' if unknown)

: Number of bytes in .
(This is a single binary byte.)

: The actual file name with any device,
directory, or other ancillary information


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



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


It is sent in one of two circumstances:

o The Responder is in terminal mode and the Initiator
wants to synchronize its number, and to
tell the Responder to set up for normal B Protocol.
When the is received, the Responder must:

> Prepare for 512 byte data blocks
> Prepare for Standard Checksum
> Initialize its Sequence to 0x30
> Transmit the string:

+ + 0x30

> Return to terminal mode. Note: The terminal
program definitely should NOT enter B Protocol
mode when the is received.

It is possible that some remote implementations
of B Plus require longer time-outs. This is
supported by including an "R" in the
response as follows:

+ + R 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 during a B
Plus session is a Positive Acknowledge.


2. Positive Acknowledge

When a correctly checked and sequenced packet is received,
a Positive Acknowledge is transmitted. This consists of:


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:


4. Negative Acknowledge

When the receiving entity receives a packet with an
unexpected , improper checksum or times out, it
sends a Negative Acknowledge to the other entity. This
consists of the single byte:


When the sending entity receives a NAK, it initiates a
Re synchronization Process by sending two characters
and waiting until it receives two identical Positive

5. Panic Abort

The B Plus Protocol recognizes a series of four
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 is
really control-P, sending it is a very simple procedure.

In addition, the Initiator recognizes the sequence:


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 during a down-load to find out what is happening.
The Responder, now in terminal emulation mode, responds


+ + 0

and the Initiator will abort cleanly. For this reason it is
essential that any B Plus implementation observe the rules
for : If in terminal mode, send + + 0;
otherwise send Sequence.


D. Negotiation of Transport Parameters

The Initiator begins a B Plus protocol session by sending:

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:

+ + 0

o returns to terminal mode.

The Initiator, detecting the ` + +', 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.

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


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

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.



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 Rcvd. Return: Terminal
+ + 0
Set up for normal
B Protocol

Rcvd. None. DLE_Seen

Process as an
ASCII char. Terminal

DLE_Seen Rcvd. None. Get_First_Packet

Rcvd. None. Terminal

Get_First_Packet Receive the Packet
Valid packet :

<+> Process Transport Terminal
Parameters; set
up for B Plus if
successful exchange

Invoke Transfer Terminal

Return Failure Terminal
Packet N




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 from Responder.
S_DLE_Seen Get character following the .
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 to Responder.
S_Send_ACK Send ACK sequence to Responder.
S_Send_ENQs Count error; Send two characters to
S_Resend_Packets Retransmit packet(s) to Responder.

The State Transition table follows:

State Event Action Next State
---------------- ------------ ----------------- -----------
S_Get_DLE ... S_DLE_Seen
... S_Send_ENQ
... S_Send_ACK
... S_Send_NAK
timeout ... S_Send_ENQ
other ... S_Get_DLE

S_DLE_Seen Release Packet return success
If sent S_Resend_Packets
else S_Get_DLE
... S_DLE_B PLUSSeen
<;> ... S_Get_DLE
... S_Send_ACK
timeout ... S_Send_ENQ
other ... S_Get_DLE

S_DLE_B PLUSSeen ... S_Send_ACK
Intit Check Value S_Get_Data
timeout ... S_Send_NAK


S_Get_Data ... S_Get_Check
timeout ... S_Send_NAK
... S_Send_ACK
Add to
check value
Store in
buffer S_Get_Data

S_Get_Check If Check Method is
CRC_16 S_Get_CRC
Checksum S_Verify_CKS
timeout ... S_Send_NAK

S_Get_CRC Add 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
= expected Seq
number Return size
If Packet Type
= `F' Return size
If duplicate
packet S_Send_ACK
else S_Send_NAK

S_Send_NAK ... Count Receive
If too many errors Return failure
If not Aborting
then Send

S_Send_ACK ... IF not Aborting
then Send ACK sequence

S_Send_ENQ ... Send S_Get_DLE

S_Resend_Packets ... Send all un-ACKed
packets. S_Get_DLE


Note: "Aborting" means that a Failure Packet has been sent. If
Failure Packet has been sent, all outstanding packets are
assumed to be ACKed.



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
, 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
o A NAK is received. Retransmit all packets which are

If the Outstanding count is still at the maximum, stay in

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:



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'



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

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 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 when a time-out occurs.

If getting the job done is more important, then don't send
the on time-out.


3. Packet Size

The following chart shows the percentage of housekeeping overhead
for various packet sizes (not including quoted characters):

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

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.


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.



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

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
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


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.

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 Get_DLE


Get_DLE ... Get_Digit
<+> If Plus_Seen true,
then set Plus_Plus
... Get_DLE
Set Relaxed_Timing Get_DLE
timeout Send_ENQ


Get_Digit Initialize Send and
Receive Sequence
Numbers Send_Parameters
<+> Set Plus_Seen Get_DLE
timeout ... Send_ENQ



Send_Parameters ... If Plus_Seen true,
if Plus_Plus true,
then set to quote
0x00-0x1f and

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




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 response:
Classic B
Interim B: +
B Plus: + +
or + + R 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 :
Classic B: Retransmit the last packet
Interim B: Resynchronize with , 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 to determine what version is being used in the terminal


software. The defaults given in Section D.1 ("Enquire") are
intended to reflect "Classic" B Protocol. If the Host receives


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.



M. Check Value Calculation

1. Standard B Protocol Checksum.

The following C-language code fragment illustrates the
Standard Checksum calculation:


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[] = {




unsigned CRC;
UpdCrc (Byte)
unsigned int ByteC;
{ CRC =
crc_xmodem_tab [(CRC >> 8 ^ Byte) & 0xff] ^ (crc << 8);



3. CCITT CRC-16 and 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,


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




#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



* 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)



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:


When the terminal program receives this sequence of characters,
it transmits an Interrogation Response as follows:

<#> < <+>


<#> Identifies the string as an Interrogation

Identifies the remote software as

<:> <:>

= Product Id
(1 to 6 char.)
= Version
(1 to 12 char.)
= Operating System
(1 to 3 char.)



identified CompuServe WinCIM version
1.0.b7 running under Windows 3.1.

The PID and Ops fields will be assigned
by CompuServe Marketing.



A series of character fields giving the
options supported. Each is followed
by a comma. The currently recognized
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
uninvoked by (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

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)

AP : Recognizes and properly responds to
the CompuServe Application Protocol
escape sequences
CB : Capture Buffer
PB : B Protocol (includes Interim B and
B Plus)


CHd : Character Set
COddd : Country Code
LAd : Language Preference
(Note: d represents decimal

HC : Hard Copy (printer connected)
XX : Ignored

All other are reserved for future use.

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.

This is the ASCII Carriage Return and serves to
terminate the Interrogate Response.

If the value does not match, the host will send another
I and compare the string it receives to the previous one.
If the two strings match, it is accepted, otherwise the I
and matching will continue for ten trials before giving up.

A sample Interrogate Response is:


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,+"


For additional information concerning the Interrogation
Response, please contact CompuServe Incorporated, Microcomputer
Software Development.




B Plus Control Sequences, 20
B Plus Packet Types, 10
B Plus Transport Layer., 35
B Protocol Versions, 38
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
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

Sample B Plus packet, 6
Standard B Protocol Checksum, 9
Supporting the Various B Protocol Versions, 38
Terminal Program States., 25
Time-Out, 31
Relaxed, 20
Transport Layer, 35
Wait for Acknowledge, 26
Wait., 21
XMODEM-Style CRC-16., 9


 December 30, 2017  Add comments

Leave a Reply