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



