1 REM Ins{nd av medlem 1789 1984-09-16 20.12.19 (Text 260162) 84-09-15 13.42 Torbj|rn Nordlindh Apple Computer AB Mottagare: CP/M tekniskt erfarenhetsutbyte <532> F|r k{nnedom: KERMIT erfarenhetsutbyte <499> Kommentar till: (Text 259469) av Bo Kullmar ABC-Klubben <3> Markerat av: Sven Olofsson QZ [rende: Christinasen protokollet ------------------------------------------------------------ Den h{r texten kommer fr}n handboken till kommunikationsprogrammet Access // f|r Apple //. Jag hoppas att den kan vara till nytta f|re den som vill im- plemenera protokollet p} sin maskin. Om n}gon beh|ver testk|ra, s} s{g bara till, jag en Apple //c hemma som Du kan f} prata med. H{r kommer det: The Christensen Protocol Technical Reference Christensen protocol is a technique for data transmission and error checking that was developed by Ward Christensen of Chicago. The protocol divides the data to be transmitted into blocks of 128 bytes and adds a three-byte header and a one-byte checksum to each block. The following control characters are used by the protocol: Label Used in the Text ASCII Value in Hex 01 04 06 15 18 ______________________________________________________________________________ Transmission Characteristics The protocol functions at any transmission speed. Access // uses 8 data bits, no parity, and one stop bit. The protocol imposes no restrictions on the contents of the data being transmitted. The contents of the 128-byte blocks are never checked for control characters. Absolutely any kind of data may be sent -- ASCII, binary, code files, and so on. For compatibility with CP/M (R) implementations of this protocol, if the file being transmitted ends exactly on a block boundary, an additional block containing 128 bytes of CONTROL-Z characters (ASCII 1A hex) is transmitted. If the file ends in the middle of a block, the block is padded with CONTROL-Z characters as necessary to reach 128 data bytes. There is no short block. With the three header bytes, 128 data bytes, and the checksum byte, each block is 132 (decimal) bytes long. Each block consists of: ! block number ! 255-block number ! data... ! checksum The first byte is the character. The second byte is the block number. Since there is only one byte for the block number, and we don't want to limit the length of transmission to 255 blocks, the block number wraps around to 00 after reaching FF hex. The first block number is block 01. The third byte is FF-block number. This provides for error checking of the block number by simply adding the first three bytes and checking to make sure the result is 256 (decimal), or if you're doing it in assembly language on an 8-bit computer, the accumulator should equal 0 (zero) with the carry bit set. The checksum is generated by adding together all the data bytes, discarding the carry generated by any add. ______________________________________________________________________________ Operation of the Protocol The protocol is operated by having the receiver started first. Once the receiver is started, it transmits an character every ten seconds until it receives data. When the sender is started, it "listens" on the line for the receiver's . If the sender doesn't get a within one minute, then the sender alerts the user that contact with the receiver has been lost. When the sender gets the from the receiver, the sender transmits the block. As soon as the receiver gets the first character, it starts counting characters until it has received all 132. If more than one second elapses with no character arriving before all 132 have been received, the receiver times out. The receiver waits for five seconds of silence on the line and sends a to cause the block to be retransmitted. When all 132 characters have been received, the block is verified and written to the file if it passes. The character is then sent to the sender to indicate a successful transmission. If any errors are detected, the character is sent; and the sender retransmits the block. After getting a block, the receiver waits for the next block. If no data arrive after ten seconds, a is transmitted to the sender. In this implementation, the sender transmits only in response to or . No automatic transmission is done, and it is not necessary. ______________________________________________________________________________ Receive Program considerations The receiver does not keep track of the number of 's sent while waiting for data. The receiver does keep track of the number of times a given block is received in error and alerts the user after receiving the same block ten times when the checksum doesn't match. The following conditions can occur while receiving: What Happens What it Does A valid block number is ACTION: Write the block to received, the checksum is the file; send . correct, the block number is the one expected. A repeat of the previous block ACTION: Not an error; assume is received. This is checked that the got garbaged only by checking the three- or lost. Ignore the repeat byte header. and send an . An out-of-sequence block ACTION: Fatal error; send a number is received. . The checksum does not match. ACTION: Increment the error counter and send a . If ten bad blocks are received, then give the user the option of canceling. is received when waiting ACTION: Transmission is for the of the next complete; close the file and block. tell the user. ______________________________________________________________________________ Send Program considerations Once the sender is started, the sender waits to receive a from the receiver. If one minute elapses without the sender getting a , then the file transmission is canceled, and the user is informed. Note that the sender never needs to retransmit automatically if it doesn't hear from the receiver. If the receiver's gets lost, the receiver will in ten seconds, which causes retranssmission of the old block, but no harm done. The following conditions can occur during sending: What Happens What it Does A block is transmitted and an ACTION: Send the next block. is received. A block is transmitted and a ACTION: Increment the error is received. counter and retransmit the block. If ten retries occur in succession, then halt transmission and ask the user whether or not to retry. A block is transmitted and no ACTION: Tell the user that reply is received for more contact has been lost with than one minute. the receiver. A block is transmitted and a ACTION: Stop transmitting is received. and tell the user that transmission has been canceled. End of file is reached while ACTION: Pad the block with constructing the next block. hex 1A and send it. After receiving the , send . The user interrupts ACTION: After the current transmission by pressing ESC. block has been 'ed, send . (Text 260162)------------------------------