rfc914.txt

RFC 的详细文档！

      data contained in the message. Following the length is a three bit
      field of flags.  The first bit is used to indicate that the a
      receive error has occurred, and the ACK is actually a repeat of
      the Last Acknowledged message (a LACK).  The second bit is used to
      indicate a Synchronize Sequence Numbers message (SSNM), and the
      third bit is used to indicate a Start of Control Message (SOCM);
      all three of these flags are explained below. Finally, at the end
      of the message is an exclusive-or checksum.  The message format is
      shown in figure D-1.

            ________________________________________________

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
|     StH       |  SEQ  |  ACK  |  Length |Flags|...Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
The maximum data length is 32 bytes.                0 1 2 3 4 5 6 7
This limits the vulnerability of receiver       ...-+-+-+-+-+-+-+-+-+-+
timeout errors occurring because of bit error .Data...|   Checksum    |
in the length field.                            ...-+-+-+-+-+-+-+-+-+-+

                    Figure D-1. SLIP Message Format

            ________________________________________________


Farber & Delp & Conte                                          [Page 17]



RFC 914                                                   September 1984
Thinwire Protocol


      The Sender, when idle but needing to acknowledge, will send out
      short messages of the same format as a regular message but with
      the SOCM flag set and the data field omitted.  ( This short
      message is called a SOCM, and is used instead of a zero length
      message to avoid the problem of continually ACK'ing ACK's ). The
      Sender Task, when originating a connection (see STARTING UP AND
      FINISHING OFF COMMUNICATIONS), will send out another short message
      but with the SSNM flag set and the data omitted.  This message (a
      SSNM) used for a TCP-style 3 way startup handshake.

   PROTOCOL SPECIFICATIONS and SUGGESTIONS

      The SLIP module, when called with data to send, prepends its
      header (SEE ABOVE) to the data, calculates a checksum and appends
      the checksum at the end.  (This creates a message.)  The message
      has a sequence number associated with it which represents the
      position of the message in the Sender SLIP's buffers.  The
      sequence number for the message can range from 0 to 15 and is
      returned in the ACK field of the other machine's Sender SLIP
      messages to acknowledge receipt.

      There are two scenarios for transmission.  In the first, both
      SLIP's will be transmitting to each other.  To send an
      acknowledgement, the Receiver SLIP uses the ACK field in its next
      outgoing message. To receive an acknowledgement, the Sender checks
      the ACK field of its Receiver's incoming messages.  In the second
      scenario, one SLIP may have no data to transmit for a long time.
      Then, as stated above, to acknowledge a received message, the
      Receiver has its Sender send out a short message, the SOCM (SEE
      ABOVE) which specifies the message it is acknowledging.  The SOCM
      includes a checksum of its total contents.  If there is a checksum
      error, THE SOCM IS IGNORED.

      When there is a checksum error on a received normal message, the
      Receiver asks its Sender to send out a SOCM with the LACK flag
      set, or set the LACK flag on its next message.  The Sender sends
      this flag ONCE then ceases to increment the acknowledgement number
      (the ACK) while the Receiver continues to check incoming messages
      for the sequence number of the message with a checksum error.
      (Note that it continues to react to the acknowledgement field in
      the incoming messages.) When it finds the needed message, it
      resumes accepting the data in new messages and increments the
      acknowledgement number transmitted accordingly.

      The sending SLIP must never send a message greater than four past
      the last message for which it has received an acknowledgement
      (effectively a window size of four). Under normal processing
      loads, a window size greater than four should not be needed, and
      this decreases the probability of random errors creating valid


Farber & Delp & Conte                                          [Page 18]



RFC 914                                                   September 1984
Thinwire Protocol


      acknowledgement or sequence numbers.  If the Sender has four
      unacknowledged messages outstanding, it will retransmit the old
      messages, starting from the oldest unacknowledged message.  If it
      receives an acknowledgement with the LACK flag set, it transmits
      the message following the LACK number and continues to transmit
      the messages from that one on.  Thus a LACK is a message asking
      the Sender to please the Receiver.  If the Sender times out on any
      message not logically greater than four past the last acknowledged
      message, it should retransmit the message that timed out and then
      continues to transmit messages following the timed out message.

      The following describes a partial implementation of SLIP.  System
      dependent subjects like buffer management, timer handling and
      calling conventions are discussed.

      The SLIP implementation is subdivided into four modules and two
      sets of input/output interfaces.  The four modules are: The Sender
      Task, The Receiver Task, the buffer Manager, and SLIPTIME (the
      timer). The two interfaces are to the higher protocol and to the
      lower protocol (the UARTian, an interrupt driven device driver for
      the serial lines).

   OPERATIONS OF THE SENDER TASK

      The Sender Task takes a relatively noncomplex approach to
      transmitting.  It sends message zero, sets a timer (using the
      SLIPTIME Task) on the message, and proceeds to send and set timers
      for messages one, two, and three.  When the Receiver Task tells
      the Sender Task that a message has been acknowledged, the Sender
      Task then clears the timer for that message, and marks it
      acknowledged.  When the Sender Task has finished sending a
      message, it checks several conditions to decide what to do next.
      It first checks to see if a LACK has been received. If it has then
      it clears all the timers, and begins retransmitting messages
      (updating the acknowledgement field and checksum) starting from
      the one after the LACK'ed message.  If there is not a LACK waiting
      for the Sender Task, it checks to see if any messages have timed
      out.  If a message has timed out, the Sender Task again will clear
      the timers and begin retransmitting from the message number which
      timed out.  If neither of these conditions are true, the Sender
      Task checks to see if, because it has looped back to retransmit,
      it has any previously formulated messages to send.  If so, it send
      the first of these messages. If it does not have previously
      formulated messages, it checks to see if it is more than three
      past the last acknowledged message.  If so, it restarts from the
      message after the last acknowledged message.  If none of these are
      true, then it checks to see if there is more data waiting to be
      transmitted.  If there is more data available, it forms the
      largest packet it can, and begins to transmit it.  If there is no


Farber & Delp & Conte                                          [Page 19]



RFC 914                                                   September 1984
Thinwire Protocol


      more data to transmit, it checks to see if it needs to acknowledge
      a message received from the other side.  If so then it sends a
      SOCM.  If none of the above conditions create work for the Sender
      Task, the task suspends itself.

      Note that the Sender Task uses the Receiver Task to find out about
      acknowledgements and the Receiver Task uses the Sender Task to
      send acknowledgements to the other SLIP on the other side (via the
      ACK field in the Sender Task's message). The two tasks on one
      machine communicate through a small buffer. Because
      acknowledgements need to be passed back to the Sender Task
      quickly, the Receiver Task can wake up the Sender Task (unblock
      it).

   OPERATIONS OF THE RECEIVER TASK

      The Receiver Task checks the checksums of the messages coming into
      it.  When it gets a checksum error, it tells the Sender Task to
      mark the next acknowledgement as a LACK.  It then throws away all
      messages coming into it that don't match the message it wants and
      continues to acknowledge with the last ACK until it gets the
      message it wants.  As a checksum error could be the result of a
      crashed packet, and the StH character can occur within the packet,
      when a checksum error does occur, the recovery includes scanning
      forward from the last StH character for the next StH character
      then attempting to verify a packet beginning from it.  A valid
      message includes a valid checksum, and sequence and
      acknowledgement numbers within the active window of numbers.  This
      eliminates the need for the resequencing of messages, because the
      Receiver Task throws away anything that would make information in
      its buffers out of sequence.

   OPERATIONS OF SLIPTIME

      The timer task will maintain and update a table of timers for each
      request.  Its functions should be called with the timer length and
      the sequence number to associate with the timer.  Its functions
      can also be called with a request to delete a timer.  An
      interrupt-driven mechanism is used to update the running timers
      and to wake up the Sender when an alarm goes off.











Farber & Delp & Conte                                          [Page 20]



RFC 914                                                   September 1984
Thinwire Protocol


   THE INPUT AND OUTPUT INTERFACES

      To force SLIP to do something, the higher protocol should create a
      buffer and then call SLIP, passing it a pointer to the buffer.
      SLIP will then read the buffer and begin sending it.  The call to
      SLIP will return the number of bytes written, negative number
      indicates to the caller that SLIP could not do the request.  Exact
      error numbers will be assigned in the future.  To ask SLIP to
      receive something, one would call SLIP and SLIP would immediately
      return the number of bytes received or a negative number for an
      error (nothing ready to receive, for example).

      SLIP, when it wants to talk to the underworld of the serial
      interface, will do much the same thing only through a buffer
      written to by the UARTian (for received data) and read from by the
      UARTian (for sent data).

   OPERATIONS OF THE BUFFER/WINDOW MANAGER

      The Manager tends a continuous, circular buffer for the Sender
      Task in which data to be sent (from the downcalling protocol) is
      stored.  This buffer is called the INPUT-DATA BUFFER (IDBuff).
      The Manager also manages a SENDER TASK'S OUTPUT-DATA BUFFER
      (SODBuff), which is its output buffer to the UARTian.

      The IDBuff has associated with it some parameters.  These
      parameters include: START OF MEMORY (SOM), the start of memory
      reserved for the IDBuff; END OF MEMORY (EOM), the end of memory
      reserved; START OF DATA (SOD), the beginning of the used portion
      of the IDBuff; and END OF DATA (EOD), the end of data in the
      IDBuff.  The SOM and EOM are constants whereas the SOD and EOD are
      variables.

      The SODBuff is composed of four buffers for four outbound messages
      (less the checksum).  The buffers can be freed up to be
      overwritten when the message that they contain is acknowledged by
      the SLIP on the other side of the line.  When a message is in the
      SODBuff, it has associated with it a sequence number (which is the
      message's sequence number).  The Sender Task can reference the
      data in the SODBuff and reference acknowledgements via this
      sequence number.

      When the application has data to be transmitted, it is placed in
      the IDBuff by the application using functions from the Manager and
      the EOD is incremented.  If the data the application wants to send
      won't fit in the buffer, no data is written, and the application
      can either sleep, or continue to attempt to write data until the




Farber & Delp & Conte                                          [Page 21]



RFC 914                                                   September 1984
Thinwire Protocol


      data will fit. The Sender Task calls a Manager function to fill a
      message slot in the SODBuff.  The Sender Task then sends its
      message from the SODBuff.

      The Manager also maintains a buffer set for the Receiver Task. The
      buffers are similar to those of the Sender Task.  There is a
      CHECKSUMMED OUTPUT-DATA BUFFER (CODBuff), which is the final
      output from SLIP that the higher level protocol may read.  The
      CODBuff is also controlled by the four parameters START OF MEMORY,
      END OF MEMORY, START OF DATA, and END OF DATA (SOM, EOM, SOD, and
      EOD).

      There is also an inbound circular buffer the analog of the
      SODBuff, called the RECEIVER TASK'S INPUT-DATA BUFFER (RIDBuff).

      When the UARTian gets data, it places the data in the RIDBuff.
      After this, the Receiver Task checksums the data.  If the checksum
      is good and the Receiver Task opts to acknowledge the message, it
      moves the data to the CODBuff, increments EOD, and frees up space
      in the RIDBuff.  The higher level application can then take data
      off on the CODBuff, incrementing SOD as it does so.

   STARTING UP AND FINISHING OFF COMMUNICATIONS

      The problem is that the SLIP's on either side need to know (and
      keep knowing) the sequence number of the other SLIP.  The easiest
      way to solve most of these problems is to have the SLIP check the
      Request to Send and Clear to Send Lines to see if the other SLIP
      is active. On startup, or if it has reason to believe the other
      side has died, the SLIP assumes: all connections are closed, no
      data from any connection has been sent, and both its SEQ and the
      SEQ of the other SLIP are zero.  To start up a connection, the
      instigating SLIP sends a SSNM with its starting sequence number in
      it.  The receiving SLIP acknowledges this SSNM and replies with
      its starting sequence number (combined into one message).  Then
      the sending SLIP acknowledges the receiving SLIP's starting
      sequence number and the transmission commences.  This is the three
      way handshake taken from TCP, After which data transmission can
      begin.












Farber & Delp & Conte                                          [Page 22]