RFC 955 (rfc955) - Page 2 of 10
Towards a transport service for transaction processing applications
Alternative Format: Original Text Document
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