rfc908.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 2,193 行 · 第 1/5 页

          The sequence number of the oldest unacknowledged segment.

     SND.MAX

          The maximum number of outstanding (unacknowledged)  segments
          that can be sent.  The sender should not send more than this
          number of segments without getting an acknowledgement.

     SND.ISS

          The initial send sequence  number.   This  is  the  sequence
          number that was sent in the SYN segment.

     Receive Sequence Number Variables:

     RCV.CUR

          The sequence number of the last segment  received  correctly
          and in sequence.

     RCV.MAX

          The maximum number of segments that can be buffered for this
          connection.

     RCV.IRS

          The initial receive sequence number.  This is  the  sequence
          number of the SYN segment that established this connection.

     RCVDSEQNO[n]

          The array of sequence numbers of  segments  that  have  been
          received and acknowledged out of sequence.

     Other Variables:

     CLOSEWAIT

          A timer used to time out the CLOSE-WAIT state.

     SBUF.MAX

          The largest possible segment (in octets) that can legally be
          sent.  This variable is specified by the foreign host in the



     Page 12



     RDP Specification                              Protocol Operation



          SYN segment during connection establishment.

     RBUF.MAX

          The  largest  possible  segment  (in  octets)  that  can  be
          received.   This  variable is specified by the user when the
          connection is opened.  The variable is sent to  the  foreign
          host in the SYN segment.

     Variables from Current Segment:

     SEG.SEQ

          The  sequence  number  of  the   segment   currently   being
          processed.

     SEG.ACK

          The acknowledgement sequence number in the segment currently
          being processed.

     SEG.MAX

          The maximum number of outstanding segments the  receiver  is
          willing  to  hold,  as  specified  in  the  SYN segment that
          established the connection.

     SEG.BMAX

          The maximum segment size (in octets) accepted by the foreign
          host  on  a connection, as specified in the SYN segment that
          established the connection.



     3.2.5  Closing a Connection

          The closing of a connection can  be  initiated  by  a  Close
     request  from  the  user  process or by receipt of an RST segment
     from the other end of the connection.  In the case of  the  Close
     request,  RDP  will  send an RST segment to the other side of the
     connection and then enter the CLOSE-WAIT state for  a  period  of
     time.   While  in the CLOSE-WAIT state, RDP will discard segments
     received from the other side of the connection.  When  the  time-
     out  period expires, the connection record is deallocated and the
     connection ceases  to  exist.   This  simple  connection  closing
     facility  requires  that  users  determine that all data has been



                                                               Page 13



     RFC-908                                                 July 1984



     reliably delivered before requesting a close of the connection.



     3.2.6  Detecting an Half-Open Connection

          If one side of a connection crashes, the connection  may  be
     left  with the other side still active.  This situation is termed
     to be an half-open connection.  For many cases,  the  active  RDP
     will  eventually  detect the half-open connection and reset.  Two
     examples of recovery from half-open connections are  provided  in
     sections  5.7  and  5.8.   Recovery  is  usually achieved by user
     activity or by the crashed host's attempts  to  re-establish  the
     connection.

          However, there are cases  where  recovery  is  not  possible
     without action by the RDP itself.  For example, if all connection
     blocks are in use, attempts to re-establish a  broken  connection
     will  be  rejected.   In  this  case, the RDP may attempt to free
     resources by verifying  that connections are fully open. It  does
     this  by  sending  a  NUL  segment to each of the other RDPs.  An
     acknowledgement indicates the connection is still open and valid.

          To minimize network overhead,  verification  of  connections
     should  only  be  done  when  necessary  to  prevent  a  deadlock
     situation.  Only inactive connections  should  be  verified.   An
     inactive  connection  is  defined  to be a connection that has no
     outstanding unacknowledged segments, has no segments in the  user
     input or output queues, and that has not had any traffic for some
     period of time.



     3.3  Data Communication

          Data  flows  through  an  RDP  connection  in  the  form  of
     segments.   Each  user  message  submitted with a Send request is
     packaged for transport as a single RDP segment.  Each RDP segment
     is packaged as an RDP header and one or more octets of data.  RDP
     will not attempt to fragment a large user  message  into  smaller
     segments  and re-assemble the message on the receiving end.  This
     differs from a byte-stream protocol such as  TCP  which  supports
     the  transfer  of  an indeterminate length stream of data between
     ports, buffering data until it is requested by the receiver.






     Page 14



     RDP Specification                              Protocol Operation



          At the RDP level, outgoing segments, as  they  are  created,
     are queued as input to the IP layer.  Each segment is held by the
     sending RDP  until  it  is  acknowledged  by  the  foreign  host.
     Incoming segments are queued as input to the user process through
     the user interface.  Segments are  acknowledged  when  they  have
     been accepted by the receiving RDP.

          The receiving end of each connection specifies  the  maximum
     segment  size  it  will  accept.   Any  attempt  by the sender to
     transmit a larger segment is an error.  If RDP determines that  a
     buffer  submitted  with  a  Send request exceeds the maximum size
     segment permitted on the connection, RDP will return an error  to
     the  user.   In addition, RDP will abort a connection with an RST
     segment if an  incoming  segment  contains  more  data  than  the
     maximum  acceptable  segment  size.   No  attempt will be made to
     recover from or otherwise overcome this error condition.

          If  sequenced  delivery  of  segments  is  necessary  for  a
     connection, the requirement must be stated when the connection is
     established.  Sequenced  delivery  is  specified  when  the  Open
     request is made.  Sequenced delivery of segments will then be the
     mode of delivery for the life of the connection.



     3.4  Reliable Communication

          RDP implements a reliable message service through  a  number
     of  mechanisms.   These include the insertion of sequence numbers
     and checksums into  segments,  the  positive  acknowledgement  of
     segment  receipt,  and  timeout  and  retransmission  of  missing
     segments.



     3.4.1  Segment Sequence Numbers

          Each segment transporting data has a  sequence  number  that
     uniquely  identifies  it  among  all  other  segments in the same
     connection.  The initial  sequence  number  is  chosen  when  the
     connection  is  opened  and is selected by reading a value from a
     monotonically increasing clock.  Each time a  segment  containing
     data   is   transmitted,  the  sequence  number  is  incremented.
     Segments containing no data do not increment the sequence number.
     However, the SYN and NUL segments, which cannot contain data, are
     exceptions.  The  SYN  segment  is  always  sent  with  a  unique
     sequence number, the initial sequence number.  The NUL segment is



                                                               Page 15



     RFC-908                                                 July 1984



     sent with the next valid sequence number.



     3.4.2  Checksums

          Each RDP segment contains a checksum to allow  the  receiver
     to  detect  damaged  segments.   RDP  uses  a non-linear checksum
     algorithm to compute a checksum that is 32-bits wide and operates
     on  data  in  units  of  four octets (32 bits).  The area that is
     covered by the checksum includes both the RDP header and the  RDP
     data area.

          If a segment contains a number of  header  and  data  octets
     that  is  not an integral multiple of 4 octets, the last octet is
     padded on the right with zeros to  form  a  32-bit  quantity  for
     computation  purposes.   The padding zeros are not transmitted as
     part of the segment.  While computing the checksum, the  checksum
     field  itself  is  replaced  with zeros.  The actual algorithm is
     described in Section 4.2.1.



     3.4.3  Positive Acknowledgement of Segments

          RDP assumes it has only an unreliable  datagram  service  to
     deliver  segments.   To  guarantee  delivery  of segments in this
     environment, RDP uses positive acknowledgement and retransmission
     of  segments.   Each  segment containing data and the SYN and NUL
     segments are acknowledged when they are  correctly  received  and
     accepted  by  the  destination host.  Segments containing only an
     acknowledgement  are  not  acknowledged.   Damaged  segments  are
     discarded  and  are not acknowledged.  Segments are retransmitted
     when there is no timely acknowledgement of  the  segment  by  the
     destination host.

          RDP allows  two  types  of  acknowledgement.   A  cumulative
     acknowledgement  is  used  to  acknowledge  all  segments up to a
     specified sequence number.  This type of acknowledgement  can  be
     sent   using   fixed   length   fields  within  the  RDP  header.
     Specifically,  the  ACK  control  flag  is  set  and   the   last
     acknowledged  sequence  number  is  placed in the Acknowledgement
     Number field.

          The extended or non-cumulative  acknowledgement  allows  the
     receiver  to  acknowledge segments out of sequence.  This type of
     acknowledgement is sent using  the  EACK  control  flag  and  the



     Page 16



     RDP Specification                              Protocol Operation



     variable  length  fields in the RDP segment header.  The variable
     length header fields are used to hold the sequence numbers of the
     acknowledged out-of-sequence segments.

          The type of acknowledgement used is simply a function of the
     order  in which segments arrive.  Whenever possible, segments are
     acknowledged using the cumulative acknowledgement segment.   Only
     out-of-sequence  segments  are  acknowledged  using  the extended
     acknowledgement option.

          The user process, when  initiating  the  connection,  cannot
     restrict the type of acknowledgement used on the connection.  The
     receiver   may   choose   not   to   implement    out-of-sequence
     acknowledgements.   On  the  other hand, the sender may choose to
     ignore out-of-sequence acknowledgements.



     3.4.4  Retransmission Timeout

          Segments may be lost in transmission for two  reasons:  they
     may  be  lost  or  damaged  due  to  the  effects  of  the  lossy
     transmission media; or they may be  discarded  by  the  receiving
     RDP.   The  positive acknowledgement policy requires the receiver
     to acknowledge a segment only when the segment has been correctly
     received and accepted.

          To detect missing segments,  the  sending  RDP  must  use  a
     retransmission  timer for each segment transmitted.  The timer is
     set to a value approximating the transmission time of the segment
     in  the  network.   When  an  acknowledgement  is  received for a
     segment, the timer is cancelled for that segment.  If  the  timer
     expires before an acknowledgement is received for a segment, that
     segment is retransmitted and the timer is restarted.



     3.5  Flow Control and Window Management

          RDP employs a simple flow control mechanism that is based on
     the  number  of  unacknowledged  segments  sent  and  the maximum
     allowed number of outstanding  (unacknowledged)  segments.   Each
     RDP  connection  has an associated set of flow control parameters
     that include the maximum number of outstanding segments for  each
     side  of  a  connection.  These parameters are specified when the
     connection is opened with the Open request, with each side of the
     connection   specifying  its  own parameters.  The parameters are



                                                               Page 17



     RFC-908                                                 July 1984



     passed from  one  host  to  another  in  the  initial  connection
     segments.

          The values specified for these parameters should be based on
     the  amount  and  size  of  buffers  that  the  RDP is willing to
     allocate to a connection.  The particular RDP implementation  can
     set  the  parameters to values that are optimal for its buffering
     scheme.  Once these parameters  are  set  they  remain  unchanged
     throughout the life of the connection.

          RDP employs the concept of  a  sequence  number  window  for
     acceptable segment sequence numbers.  The left edge of the window
     is the number  of  the  last  in-sequence  acknowledged  sequence
     number  plus  one.   The right edge of the window is equal to the
     left edge plus twice the allowed maximum  number  of  outstanding
     segments.   The allowed maximum number of outstanding segments is
     the number of segments the transmitting RDP software  is  allowed
     to send without receiving any acknowledgement.

          The flow control and window management parameters  are  used
     as  follows.   The  RDP  module  in  the  transmitting host sends
     segments  until  it  reaches  the  connection's   segment   limit
     specified  by the receiving process.  Once this limit is reached,
     the transmitting RDP module may only send a new segment for  each
     acknowledged segment.

          When a received segment has a  sequence  number  that  falls
     within  the  acceptance  window,  it  is  acknowledged.   If  the
     sequence number is equal to the left-hand edge (i.e., it  is  the
     next  sequence number expected), the segment is acknowledged with
     a cumulative acknowledgement (ACK).   The  acceptance  window  is
     adjusted  by  adding  one  to  the  value  of  the edges.  If the
     sequence number is within the acceptance window  but  is  out  of
     sequence,    it    is    acknowledged   with   a   non-cumulative
     acknowledgement (EACK).  The window  is  not  adjusted,  but  the
     receipt of the out-of-sequence segment is recorded.

          When  segments  are   acknowledged   out   of   order,   the
     transmitting  RDP  module must not transmit beyond the acceptance
     window.  This could occur if one segment is not acknowledged  but
     all  subsequent  segments  are  received  and acknowledged.  This
     condition will fix the left edge of the window  at  the  sequence
     number of the unacknowledged segment.  As additional segments are
     transmitted, the next  segment  to  be  sent  will  approach  and
     eventually  overtake  the  right  window edge.  At this point all
     transmission of new segments will cease until the  unacknowledged
     segment is acknowledged.



     Page 18



     RDP Specification                              Protocol Operation



     3.6  User Interface

          The user interface to RDP is  implementation  dependent  and
     may  use  system  calls,  function calls or some other mechanism.
     The list of requests that follows is not intended  to  suggest  a
     particular implementation.


     OPEN Request

          Opens a connection.   Parameters  include  type  (active  or
          passive),  local  port,  remote  port,  remote host address,
          maximum  segment  size,  maximum  number  of  unacknowledged
          segments,  delivery  mode (sequenced or non-sequenced).  The
          connection id,  including  any  allocated  port  number,  is
          returned to the user.


     SEND Request

          Sends  a  user  message.   Parameters   include   connection
          identifier, buffer address and data count.


     RECEIVE Request

          Receives a  user  message.   Parameters  include  connection
          identifier, buffer address and data count.


     CLOSE Request

          Closes a specified connection.  The single parameter is  the
          connection identifier.