rfc955.txt

RFC 的详细文档！

RFC 955                                                   September 1985
Transaction Protocol


   minimal two-packet exchange used over the LAN should be possible
   across the Internet.  This leads to two requirements for supporting
   distributed operating systems:

      *  No Explicit Connection Setup or Teardown Phases;

      *  Implicit ("piggy-backed") Acknowledgments Whenever Possible.

         This implies that the response packet will serve as an implicit
         acknowledgment to the request packet (when timing makes this
         possible).  Similarly, a new request (for the same pair of
         addressable entities) would implicitly acknowledge the previous
         response, if it came soon enough.

   The nature of the application imposes two other requirements:

      *  Reliable ("at-most-once"), Ordered Delivery

         However, it should be possible to relax the reliability to take
         advantage of special cases like an idempotent request.

      *  Multicast Capability

         The transport service should mesh cleanly with the proposed
         Internet multicast facility, using host groups [ChDe85].

5.  OBJECTIVES FOR A PROTOCOL

   We believe that it is possible to design a new transport protocol for
   the Internet which is suitable for a wide variety of
   transaction-oriented applications.  Such a transport protocol would
   have the following attributes:

      *  Reliable Delivery

         Data will be delivered reliably, i.e., exactly once, or the
         sender will be informed.  The protocol must be able to handle
         loss, duplication, and reordering of request and response
         packets.  In particular, old duplicate request packets must not
         cause erroneous actions.

         It should also be possible for the application programs to
         request that the reliability be relaxed for particular
         transactions.  This would allow communication economies in the
         case of idempotent requests or of notification without reply.




Braden                                                          [Page 6]



RFC 955                                                   September 1985
Transaction Protocol


      *  Minimum Number of Packets in Simple Cases

         In the simplest case (small messages, no packet losses, and the
         interval between requests and replies between the same pair of
         addressable entities shorter than applicable timeouts), a
         simple two-packet exchange should result.

      *  No Explicit Connection Setup or Teardown Phases

         The protocol will not create virtual circuits, but will provide
         what is sometimes (confusingly) called "reliable datagram"
         service.

         However, in order to provide a minimum two-packet exchange,
         there must be some implicit state or "soft" virtual circuit
         between a pair of addressable entities. In recent discussions
         this has been dubbed a "conversation", to distinguish it from a
         connection.

      *  Minimal Idle State

         When a server is not processing a transaction, there will be no
         state kept (except enough to recognize old duplicate packets
         and to suppress unneeded ACK packets).

      *  Fragmentation/Reassembly of Large Messages

         There is a range of possible objectives here. The minimum
         requirement is that the application not have to know the number
         576, 548, etc. For example, each application might establish
         its own "natural" upper limit on the size of a message, and
         always provide a buffer of that size [3].

         At the other extreme, the protocol might allow very large
         messages (e.g., a megabyte or more).  In this case, the
         proposed protocol would, in the large-message limit, be
         performing the bulk data transfer function of TCP.  It would be
         interesting to know whether this is possible, although it is
         not necessarily a requirement.

         The introduction of multi-packet messages leads to the complex
         issues of window sizes and flow control.  The challenge is to
         handle these efficiently in the absence of connection setup.

      *  Message Orientation




Braden                                                          [Page 7]



RFC 955                                                   September 1985
Transaction Protocol


         The basic unit of communication will be an entire message, not
         a stream of bytes.  If a message has to be segmented, it will
         be delivered in units of segments or buffers, not bytes.

      *  Multicast Capability

   Based on this discussion, we can suggest some of the key issues and
   problems in design of this protocol.

      *  Choice of Addressable Entity

         What will be the addressable entity?  It must be unique in
         space; must it be unique in time (even across system crashes) ?

      *  Timeout Dynamics

         Timeouts must be the key to operation of this protocol.
         Experience with TCP has shown the need for dynamic selection of
         an appropriate timeout, since Internet delays range over four
         decimal orders of magnitude.

         However, the absence of connection setup and the
         typically-short duration of a single interaction seem to
         preclude the dynamic measurement of delays.

      *  Multi-Packet Messages

         How can flow control be provided for multi-packet messages, to
         provide reasonable throughput over long-delay paths without
         overrun with short-delay paths, when there is no virtual
         circuit setup?

      *  Implementation Efficiency

         The protocol should lend itself to efficient (which probably
         implies simple) implementations, so that hosts will be willing
         to use it over LAN's as well as for general Internet
         communication.

   We believe further study is needed on these questions.

   The reader may wonder: how is the proposed protocol related to an RPC
   (Remote Procedure Call) facility?  The intent is that RPC facilities
   and message-passing IPC facilities will be built on top of the
   proposed transport layer.  These higher-level mechanisms will need to
   address a number of additional issues, which are not relevant to the
   communication substrate:


Braden                                                          [Page 8]



RFC 955                                                   September 1985
Transaction Protocol


      1.  Application Interface

         This includes binding and stub generators.

      2.  Structured Data Encoding

      3.  Server Location and Binding

      4.  Authentication and Access Control

6.  CONCLUSION

   Distributed processing and distributed data bases will underlie many
   of the future computer system research projects and applications
   based upon the Internet.  As a result, transaction-based
   communication will be an increasingly important activity on the
   Internet.  We claim that there is a pressing need for an appropriate
   transport protocol for transaction processing.  In this memo, we have
   given examples to support this claim, and have outlined the service
   which such a new transport protocol would provide.

   This memo is based upon discussions within the New End-to-End
   Protocols taskforce, and it is a pleasure to acknowledge the
   participation and sagacity of the members of that group.  I want to
   thank Dave Clark, an ex officio taskforce member, for his
   contribution to these discussions, and Robert Cole for very helpful
   suggestions.

NOTES:

   [1]  For the purposes of this RFC, in fact, the reader may consider
        "transport service" to be defined as that protocol layer which
        contains TCP and UDP, as in Figure 1 of RFC-791.  Alternatively,
        we may use the ISO definition -- the transport service is the
        lowest layer providing end-to-end service which is essentially
        independent of the characteristics of the particular (Inter-)
        network used to support the communication.

   [2]  This idea is implicit in the ISO definition of a transport
        service.

   [3]  It would be reasonable for the name server definition to specify
        an upper bound on the size of a single query or response; e.g.,
        2K bytes.  This would imply (large) limits on the number of RR's
        that could be returned per response. If that limit is exceeded,
        we are doing something wrong!



Braden                                                          [Page 9]



RFC 955                                                   September 1985
Transaction Protocol


REFERENCES

   BiNe84   Birrell, Andrew D. and Nelson, Bruce Jay, "Implementing
            Remote Procedure Calls". ACM TOCS, Vol. 2, No. 1, February
            1984.

   ChDe85   Cheriton, David R. and Deering, Steven, "Host Groups: a
            Multicast Extension for Datagram Networks".  To be presented
            to 9th Data Communication Symposium.

   Cher85   Cheriton, David R., "V Message Transaction Protocol".
            Private communication, July 1985.

   Cour81   Xerox Corp., "Courier: The Remote Procedure Call Protocol".
            XSIS 038112, Xerox Corp., Stamford, Conn., December 1981.

   Coop84   Cooper, Eric C., "Circus: a Replicated Procedure Call
            Facility".  Proc. 4th Symposium on Reliability in
            Distributed Software and Database Systems, October 1984.

   Crow85   Crowcroft, Jon, "A Sequential Exchange Protocol".  Internal
            Note 1688, Computer Science Department, University College
            London, June 1985.

   Gurw85   Gurwitz, Robert F., "Object Oriented Interprocess
            Communication in the Internet".  Private communication,
            April 1985.

   Mill85   Miller, Trudy, "Internet Reliable Transaction Protocol --
            Functional and Interface Specification".  RFC-938, February
            1985.

   Shel85   Sheltzer, Alan B. , "Network Transparency in an Internetwork
            Environment", PhD Thesis, UCLA Department of Computer
            Science, July 1985.

   Wats81   Watson, Richard W., "Timer-based Mechanisms in Reliable
            Transport Protocol Connection Management".  Computer
            Networks, Vol. 5, pp47-56, 1981 (also distributed as
            IEN-193).









Braden                                                         [Page 10]