Towards a transport service for transaction processing applications
RFC 955
|
Document |
Type |
|
RFC - Unknown
(September 1985; No errata)
|
|
Authors |
|
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy stream
|
|
Formats |
|
plain text
html
pdf
htmlized (tools)
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 955 (Unknown)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group R. Braden
Request for Comments: 955 UCLA OAC
September 1985
Towards a Transport Service for
Transaction Processing Applications
STATUS OF THIS MEMO
This RFC is concerned with the possible design of one or more new
protocols for the ARPA-Internet, to support kinds of applications
which are not well supported at present. The RFC is intended to spur
discussion in the Internet research community towards the development
of new protocols and/or concepts, in order to meet these unmet
application requirements. It does not represent a standard, nor even
a concrete protocol proposal. Distribution of this memo is
unlimited.
1. INTRODUCTION
The DoD Internet protocol suite includes two alternative transport
service [1] protocols, TCP and UDP, which provide virtual circuit and
datagram service, respectively [RFC-793, RFC-768]. These two
protocols represent points in the space of possible transport service
attributes which are quite "far apart". We want to examine an
important class of applications, those which perform what is often
called "transaction processing". We will see that the communication
needs for these applications fall into the gap "between" TCP and UDP
-- neither protocol is very appropriate.
We will then characterize the attributes of a possible new
transport-level protocol, appropriate for these ill-served
transaction-processing applications.
In writing this memo, the author had in mind several assumptions
about Internet protocol development.
* Assumption 1: The members of the Internet research community
now understand a great deal about protocols, and given a list
of consistent attributes we can probably generate a reasonable
protocol to meet that specification.
This is not to suggest that design of good protocols is easy.
It does reflect an assumption (perhaps wrong) that the set of
basic protocol techniques we have invented so far is sufficient
to give a good solution for any point in the attribute space,
and that we can forsee (at least in a general way) many of the
consequences of particular protocol design choices.
Braden [Page 1]
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 [Page 2]
RFC 955 September 1985
Transaction Protocol
* Short Duration
Transaction communication sequences generally have short
duration, typically 100's of milliseconds up to 10's of
seconds, but never hours.
Show full document text