RFC 955 (rfc955) - Page 2 of 10

Towards a transport service for transaction processing applications

RFC 955                                                   September 1985
Transaction Protocol


      *  Assumption 2: We need to develop appropriate service
         requirements for a "transaction processing protocol".

         The classifications "virtual circuit" and "datagram"
         immediately define in our minds the most important attributes
         of TCP and UDP.  We have no such immediate agreement about the
         services to be provided for transaction processing.  The
         existing and proposed transaction-oriented protocols show a
         number of alternative choices [e.g., Cour81, BiNe84, Coop84,
         Cher85, Crow85, Gurw85, Mill85].

   Many of the ideas discussed here are not new.  For example, Birrell
   and Nelson [BiNe84] and Watson [Wats81] have described
   transport-level protocols appropriate for transactions.  Our purpose
   here is to urge the solution of this problem within the Internet
   protocol family.

2.  TRANSACTION PROCESSING COMMUNICATIONS

   We begin by listing the characteristics of the communication patterns
   typical in "transaction processing" applications.

      *  Unsymmetrical Model

         The two end points of the communication typically take
         different roles, generally called "client" and "server".  This
         leads to an unsymmetrical communication pattern.

         For example, the client always initiates a communication
         sequence or "transaction".  Furthermore, an important subclass
         of applications uses only a simple exchange of messages, a
         "request" to the server followed by a "reply" to the client.

         Other applications may require a continuing exchange of
         messages, a dialog or "conversation".  For example, a request
         to read a file from a file server might result in a series of
         messages, one per file block, in reply. More complex patterns
         may occur.

      *  Simplex Transfers

         Regardless of the pattern, it always consists of a series of
         SIMPLEX data transfers; at no time is it necessary to send data
         in both directions simultaneously.





Braden