rfc908.txt

RFC 相关的技术文档

                          Reliable Data Protocol



                                  RFC-908














                               David Velten

                               Robert Hinden

                                 Jack Sax






                      BBN Communications Corporation






                                July 1984





Status of This Memo

   This RFC specifies a proposed protocol for the ARPA Internet
   community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.







     RDP Specification                           



                             Table of Contents





     1   Introduction.......................................... 1

     2   General Description................................... 3
     2.1   Motivation.......................................... 3
     2.2   Relation to Other Protocols......................... 5

     3   Protocol Operation.................................... 7
     3.1   Protocol Service Objectives......................... 7
     3.2   RDP Connection Management........................... 7
     3.2.1   Opening a Connection.............................. 8
     3.2.2   Ports............................................. 8
     3.2.3   Connection States................................. 8
     3.2.4   Connection Record................................ 11
     3.2.5   Closing a Connection............................. 13
     3.2.6   Detecting an Half-Open Connection................ 14
     3.3   Data Communication................................. 14
     3.4   Reliable Communication............................. 15
     3.4.1   Segment Sequence Numbers......................... 15
     3.4.2   Checksums........................................ 16
     3.4.3   Positive Acknowledgement of Segments............. 16
     3.4.4   Retransmission Timeout........................... 17
     3.5   Flow Control and Window Management................. 17
     3.6   User Interface..................................... 19
     3.7   Event Processing................................... 20
     3.7.1   User Request Events.............................. 21
     3.7.2   Segment Arrival Events........................... 24
     3.7.3   Timeout Events................................... 29

     4   RDP Segments and Formats............................. 31
     4.1   IP Header Format................................... 31
     4.2   RDP Header Format.................................. 32
     4.2.1   RDP Header Fields................................ 33
     4.3   SYN Segment........................................ 36
     4.3.1   SYN Segment Format............................... 36
     4.3.2   SYN Segment Fields............................... 37
     4.4   ACK Segment........................................ 38
     4.4.1   ACK Segment Format............................... 38
     4.4.2   ACK Segment Fields............................... 39
     4.5   Extended ACK Segment............................... 40
     4.5.1   EACK Segment Format.............................. 40
     4.5.2   EACK Segment Fields.............................. 40



                                                                Page i



     RFC-908                                                 July 1984



     4.6   RST Segment........................................ 42
     4.6.1   RST Segment Format............................... 42
     4.7   NUL Segment........................................ 43
     4.7.1   NUL segment format............................... 43

     5   Examples of Operation................................ 45
     5.1   Connection Establishment........................... 45
     5.2   Simultaneous Connection Establishment.............. 46
     5.3   Lost Segments...................................... 47
     5.4   Segments Received Out of Order..................... 48
     5.5   Communication Over Long Delay Path................. 49
     5.6   Communication Over Long Delay Path With Lost
       Segments
          .................................................... 50
     5.7   Detecting a Half-Open  Connection  on  Crash
       Recovery
          .................................................... 51
     5.8   Detecting a Half-Open  Connection  from  the
       Active Side
          .................................................... 52

     A   Implementing a Minimal RDP........................... 53




























     Page ii



     RDP Specification                           



                                  FIGURES




     1  Relation to Other Protocols............................ 5
     2  Form of Data Exchange Between Layers................... 6
     3  RDP Connection State Diagram.......................... 10
     4  Segment Format........................................ 31
     5  RDP Header Format..................................... 32
     6  SYN Segment Format.................................... 37
     7  ACK Segment Format.................................... 38
     8  EACK Segment Format................................... 41
     9  RST Segment Format.................................... 42
     10  NUL Segment Format................................... 43


































                                                              Page iii








                                 CHAPTER 1


                               Introduction



          The Reliable Data Protocol (RDP) is designed  to  provide  a
     reliable  data  transport  service  for packet-based applications
     such as remote loading and debugging.  The protocol  is  intended
     to  be simple to implement but still be efficient in environments
     where there may be long transmission  delays  and  loss  or  non-
     sequential delivery of message segments.

          Although this protocol was designed with  applications  such
     as  remote  loading and debugging in mind, it may be suitable for
     other applications that require reliable message  services,  such
     as computer mail, file transfer, transaction processing, etc.

          Some of the concepts used come from a  variety  of  sources.
     The  authors  wish credit to be given to Eric Rosen, Rob Gurwitz,
     Jack Haverty, and to acknowledge material adapted from  "RFC-793,
     The Transmission Control Protocol", edited by Jon Postel.  Thanks
     to John Linn for the checksum algorithm.



























                                                                Page 1



     RFC-908                                                 July 1984





















































     Page 2



     RDP Specification                             General Description



                                 CHAPTER 2


                            General Description



     2.1  Motivation

          RDP is a transport protocol designed to efficiently  support
     the  bulk  transfer  of data for such host monitoring and control
     applications  as  loading/dumping  and  remote   debugging.    It
     attempts to provide only those services necessary, in order to be
     efficient in operation and small in size.  Before  designing  the
     protocol,  it  was  necessary  to  consider  what  minimum set of
     transport  functions  would  satisfy  the  requirements  of   the
     intended applications.

          The following is a list of requirements for such a transport
     protocol:


         o   Reliable delivery of packets is required.   When  loading
             or  dumping  a  memory  image,  it  is necessary that all
             memory segments be  delivered.   A  'hole'  left  in  the
             memory  image  is  not acceptable.  However, the internet
             environment is a lossy  one  in  which  packets  can  get
             damaged  or  lost.   So  a  positive  acknowledgement and
             retransmission mechanism is a necessary component of  the
             protocol.

         o   Since loading and  dumping  of  memory  images  over  the
             internet  involves  the bulk transfer of large amounts of
             data over a lossy network with potentially  long  delays,
             it  is necessary that the protocol move data efficiently.
             In particular,  unnecessary  retransmission  of  segments
             should be avoided.  If a single segment has been lost but
             succeeding  segments  correctly  received,  the  protocol
             should  not  require  the  retransmission  of  all of the
             segments.

         o   Loading  and  dumping  are  applications  that   do   not
             necessarily  require  sequenced  delivery of segments, as
             long as all segments eventually are  delivered.   So  the
             protocol  need  not  force sequenced delivery.  For these
             types of applications, segments may be delivered  in  the
             order in which they arrive.



                                                                Page 3



     RFC-908                                                 July 1984



         o   However, some  applications  may  need  to  know  that  a
             particular  piece  of  data  has  been  delivered  before
             sending the next.  For example, a debugger will  want  to
             know  that  a  command inserting a breakpoint into a host
             memory  image  has  been  delivered  before   sending   a
             "proceed"  command.   If  those  segments  arrived out of
             sequence, the intended results  would  not  be  achieved.
             The  protocol  should  allow a user to optionally specify
             that a connection  must  deliver  segments  in  sequence-
             number order.

         o   The loading/dumping and debugging applications are  well-
             defined  and lend themselves to easy packetization of the
             transferred data.  They do not require  a  complex  byte-
             stream transfer mechanism.

          In order to combine the requirements for bulk  transfers  of
     data   and  reliable  delivery,  it  is  necessary  to  design  a
     connection-oriented  protocol  using  a  three-way  handshake  to
     synchronize   sequence   numbers.    The  protocol  seems  to  be
     approaching TCP in complexity, so  why  was  TCP  not,  in  fact,
     chosen?   The answer is that TCP has some disadvantages for these
     applications.  In particular:

         o   TCP  is  oriented  toward  a  more  general  environment,
             supporting  the transfer of a stream of bytes between two
             communicating  parties.   TCP  is  best  suited   to   an
             environment where there is no obvious demarcation of data
             in a communications exchange.  Much of the difficulty  in
             developing a TCP implementation stems from the complexity
             of supporting this general byte-stream transfer, and thus
             a  significant  amount  of  complexity  can be avoided by
             using  another   protocol.    This   is   not   just   an
             implementation consideration, but also one of efficiency.

         o   Since TCP does not allow a byte to be acknowledged  until
             all  prior  bytes have been acknowledged, it often forces
             unnecessary retransmission of data.  Therefore,  it  does
             not meet another of the requirements stated above.

         o   TCP  provides  sequenced  delivery   of   data   to   the
             application.   If  the  application does not require such
             sequenced delivery,  a  large  amount  of  resources  are
             wasted in providing it.  For example, buffers may be tied
             up  buffering  data  until  a  segment  with  an  earlier