rfc938.txt

RFC 相关的技术文档

      value of the length is 8.)

   2.6 Checksum

      The checksum is the 16-bit one's complement of the one's
      complement sum of the IRTP header and the transaction packet data
      (padded with an octet of zero if necessary to make an even number
      of octets.)



























Miller                                                          [Page 4]



RFC 938                                                    February 1985
Internet Reliable Transaction Protocol


CHAPTER 3 - INTERFACES

   3.1 User Services Provided by IRTP

      The exact interface to the TRTP from the using processes is
      implementation dependent, however, IRTP should provide the
      following services to the using processes.

         o  user processes must be able to claim a port number

         o  users must be able to request that data be sent to a
            particular port at an internet address (the port must be one
            which the user has claimed)

         o  users must be able to request transaction data from a
            particular port at any (unspecified) remote internet address
            (the port must be one which the user has claimed)

         o  if a port is determined to be unreachable at a particular
            destination, the using process which has claimed that port
            should be notified

      In addition to these minimal data transfer services, a particular
      implementation may want to have a mechanism by which a
      "supervisory" (that is, port independent) module can define
      dynamically the remote internet addresses which are legal targets
      for host to host communication by this IRTP module.  This
      mechanism might be internal or external to the IRTP module itself.

   3.2 IP Services Expected by IRTP

      IRTP expects a standard interface to IP through which it can send
      and receive transaction packets as IP datagrams.  In addition, if
      possible, it is desirable that IP or ICMP notify IRTP in the event
      that a remote internet address is unreachable.

      If the IP implementation (including ICMP) is able to notify IRTP
      of source quench conditions, individual IRTP implementations may
      be able to perform some dynamic adjustment of transmission
      characteristics.









Miller                                                          [Page 5]



RFC 938                                                    February 1985
Internet Reliable Transaction Protocol


CHAPTER 4 - MODEL OF OPERATION

   The basic operation of IRTP is as follows.  The first time two hosts
   communicate (or the first time after both have simultaneously
   failed,) synchronization is established using constant initial
   sequence numbers (there is a sequence number for each direction of
   transmission).  The TCP "quiet time" is used following reboots to
   insure that this will not cause inaccurate acknowledgment processing
   by one side or the other.

   Once synchronization has been achieved data may be passed in both
   directions.  Each transaction packet has a 16 bit sequence number.
   Sequence numbers increase monotonically as new packets are generated.
   The receipt of each sequence number must be acknowledged, either
   implicitly or explicitly.  At most 8 unacknowledged packets may be
   outstanding in one direction.  This number (called MAXPACK) is fixed
   for all IRTP modules. Unacknowledged packets must be periodically
   retransmitted.  Sequence numbers are also used for duplicate
   detection by receiving IRTP modules.

   If synchronization is lost due to the failure of one of the
   communicating hosts, after a reboot that host requests the remote
   host to communicate sequence number information, and data transfer
   continues.

   4.1 State Variables

      Each IRTP is associated with a single internet address.  The
      synchronization mechanism of the IRTP depends on the requirement
      that each IRTP module knows the internet addresses of all modules
      with which it will communicate.  For each remote internet address,
      an IRTP module must maintain the following information (called the
      connection table):

      rem_addr     (32 bit remote internet address)
      conn_state   (8  bit connection state)
      snd_nxt      (16 bit send sequence number)
      rcv_nxt      (16 bit expected next receive sequence number)
      snd_una      (16 bit first unacknowledged sequence number)

      In addition to maintaining the connection tables defined above, it
      is required that every IRTP module have some mechanism which
      generates "retransmission events" such that SYNCH packets are
      periodically retransmitted for any connection in synch_wait state
      (see Section 4.3), and the appropriate DATA packet is periodically
      retransmitted for any connection in data_transfer state (see
      Section 4.4.2).  It is implementation dependent whether this


Miller                                                          [Page 6]



RFC 938                                                    February 1985
Internet Reliable Transaction Protocol


      mechanism is connection dependent, or a uniform mechanism for all
      connections, so it has not been made part of the connection state
      table.  See Chapter 5 for more discussion.

   4.2 IRTP Initialization

      Whenever a remote internet address becomes known by an IRTP
      process, a 2 minute "quiet time" as described in the TCP
      specification must be observed before accepting any incoming
      packets or user requests.  This is to insure that no old IRTP
      packets are still in the network.  In addition, a connection table
      is initialized as follows:

      rem_addr     =    known internet address
      conn_state   =    0 = out-of-synch
      snd_nxt      =    0
      rcv_nxt      =    0
      snd_una      =    0

      Strictly speaking, the IRTP specification does not allow
      connection tables to be dynamically deleted and recreated,
      however, if this happens the above procedure must be repeated.
      See Chapter 5 for more discussion.

   4.3 Host-to-Host Synchronization

      An IRTP module must initiate synchronization whenever it receives
      a DATA packet or a user request referencing an internet address
      whose connection state is out-of-synch.  Typically, this will
      happen only the first time that internet address is active
      following the reinitialization of the IRTP module. A SYNCH packet
      as shown below is transmitted.  Having sent this packet, the host
      enters connection state synch_wait (conn_state = 1).  In this
      state, any incoming DATA, DATA ACK or PORT NAK packets are
      ignored.  The SYNCH packet itself must be retransmitted
      periodically until synchronization has been achieved.

      4.3.1 Response to SYNCH Packets -

         Whenever a SYNCH packet is received, the recipient, regardless
         of current connection state, is required to to return a SYNCH
         ACK packet as shown below.  At this point the recipient enters
         data_transfer state (conn_state = 2).






Miller                                                          [Page 7]



RFC 938                                                    February 1985
Internet Reliable Transaction Protocol


      4.3.2 Response to SYNCH ACK Packet -

         On receipt of a SYNCH ACK packet, the behavior of the recipient
         depends on its state.  If the recipient is in synch_wait state
         the recipient sets rcv_nxt to the sequence number value, sets
         snd_nxt and snd_una to the value in the two-octet data field,
         and enters data_transfer state (conn_state = 2).  Otherwise,
         the packet is ignored.

            0      7 8     15 16             31
            +--------+--------+--------+--------+
            |00000000|00000000|00000000 00000000|
            +--------+--------+--------+--------+
            |        8        |    checksum     |
            +-----------------+-----------------+

            Figure 4-1.  SYNCH Packet Format

            0      7 8     15 16             31
            +--------+--------+--------+--------+
            |00000001| unused |     snd_una     |
            +--------+--------+--------+--------+
            |        10       |    checksum     |
            +-----------------+-----------------+
            |      rcv_nxt    |
            +-----------------+

            Figure 4-2.  SYNCH ACK Packet Format

   4.4 Transmitting Data

      Once in data_transfer state DATA, DATA ACK and PORT NAK packets
      are used to achieve communication between IRTP processes, subject
      to the constraint that no more than MAXPACK unacknowledged packets
      may be transmitted on a connection at any time.  Note that all
      arithmetic operations and comparisons on sequence numbers
      described in this chapter are to be done modulo 2 to the 16.

      4.4.1 Receiving Data From Using Processes -

         User processes may request IRTP to send packets of at most 512
         user data octets to a remote internet address and IRTP port.
         When such a request is received, the behavior of the IRTP
         depends on the state of the connection with the remote host and
         on implementation dependent considerations.  If the connection




Miller                                                          [Page 8]



RFC 938                                                    February 1985
Internet Reliable Transaction Protocol


         between this IRTP module and the remote host is not in
         data_transfer state, that state must be achieved (see Section
         4.3) before acting on the user request.

         Once the connection is in data_transfer state, the behavior of
         the IRTP module in reaction to a write request from a user is
         implementation dependent.  The simplest IRTP implementations
         will not accept write requests when MAXPACK unacknowledged
         packets have been sent to the remote connection and will
         provide interested users a mechanism by which they can be
         notified when the connection is no longer in this state, which
         is called flow controlled.  Such implementations are called
         blocking IRTP implementations.  These implementations check, on
         receipt of a write request, to see if the value of snd_nxt is
         less than snd_una+MAXPACK.  If it is, IRTP prepends a DATA
         packet header as shown below, and transmits the packet.  The
         value of snd_nxt is then incremented by one.  In addition, the
         packet must be retained in a retransmission queue until it is
         acknowledged.

            0       7 8     15 16             31
            +--------+--------+--------+--------+
            |00000010|port num|     snd_nxt     |
            +--------+--------+--------+--------+
            |     length      |    checksum     |
            +-----------------+-----------------+
            |           data octet(s)           |
            + . . . . . . . . . . . . . . . . . +

            Figure 4-3.  DATA Packet Format

         Other implementations may allow (some number of) write requests
         to be accepted even when the connection is flow controlled.
         These implementations, called non-blocking IRTP
         implementations, must maintain, in addition to the
         retransmission queue for each connection, a queue of accepted
         but not yet transmitted packets, in order of request.  This is
         called the pretransmission queue for the connection.

         When a non-blocking implementation receives a write request, if
         the connection is not flow controlled, it behaves exactly as a
         blocking IRTP.  Otherwise, it prepends a DATA packet header
         without a sequence number to the data, and appends the packet
         to the pretransmission queue.  Note that in this case, snd_nxt
         is not incremented.  The value of snd_nxt is incremented only
         when a packet is transmitted for the first time.



Miller                                                          [Page 9]



RFC 938                                                    February 1985
Internet Reliable Transaction Protocol


      4.4.2 Packet Retransmission -

         The IRTP protocol requires that the transaction packet with
         sequence number snd_una be periodically retransmitted as long
         as there are any unacknowledged, but previously transmitted,
         packets (that is, as long as the value of snd_una is not equal
         to that of snd_nxt.)

         The value of snd_una increases over time due to the receipt of
         DATA ACK or PORT NAK packets from a remote host (see Sections
         4.5.3 and 4.5.4 below).  When either of these packet types is
         received, if the incoming sequence number in that packet is
         greater than the current value of snd_una, the value of snd_una
         is set to the incoming sequence number in that packet.  Any
         DATA packets with sequence number less than the new snd_una
         which were queued for retransmission are released.

         (If this is a non-blocking IRTP implementation, for each DATA
         packet which is thus released from the retransmission queue,
         the earliest buffered packet may be transmitted from the
         pretransmission queue, as long as the pretransmission queue is
         non-empty.  Prior to transmitting the packet, the current value
         of snd_nxt is put in the sequence number field of the header.
         The value of snd_nxt is then incremented by one.)

         Finally, if the acknowledgment is a PORT NAK, the user process
         with the nacked port number should be notified that the remote
         port is not there.

         It is also to be desired, though it is not required, that IRTP
         modules have some mechanism to decide that a remote host is not
         responding in order to notify user processes that this host is
         apparently unreachable.