| | | | |
| | | | v
| | | | +---------+
| | | | | |
| | | | +---------+
| | | |
| | | \ +---------+
| | | `-> | |
| | | +---------+
| | |
| | \ +---------+
| | `-----------> | |
| | +---------+
| |
| \ +---------+
| `--------------------->| |
| +---------+
|
\ +---+
`-----CARRY------------------------>| |
+---+
ADD
+---------+---------+
| | |
+--CARRY--+---------+
|
\ +-----+
ADD `-----> | |
+-----+
+---------+
| |
+-RESULT--+
RFC 2
3b1a2a Using this scheme, it is assumed that, if there
are n fields, the carries from the first n-1 fields
are automatically added into the low order position of
the next higher field, so that in folding, one need
only add the [n] result fields to the carry from the
nth field, and then add in an appropiately sized carry
from that addition (and repeat the desired number of
times to achieve the result.
3b1a3 A checksum computed in this manner has the advantage
that the word lengths of different machines may each be used
optimally:
3b1a3a If a string of suitable length is chosen for
computing the checksum, and a suitable checksum field
length is selected, the checksum technique for each of
the machines will be relatively optimal.
3b1a3a1 Field length: 288 bits (lowest common
denomenator of (24,32,36)
3b1a3a2 Checksum length: 8 bits (convenient field size
for all machines)
3b1b If a message is divided into groups of fields, and each
group is checksummed in this manner, an order dependent
checksum may be got by shifting the checksum for each group,
and adding it in (successively) to the checksum of the next
group
3c A facility will be provided where two HOSTs may enter a mode which
requires positive verification of all messages. This verification is
sent over the control link.
4 MONITOR FUNCTIONS
4a Network I/O drivers
4a1 Input
4a1a Input message from IMP.
4a1b Do error checking on message.
4a1b1 Verify checksum,
4a1b2 Send "message recieved" aknowledgement over control
link if aknowledge mode is in effect.
RFC 2
4a1c (trans)character translation
=4= |