summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc722.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc722.txt')
-rw-r--r--doc/rfc/rfc722.txt800
1 files changed, 800 insertions, 0 deletions
diff --git a/doc/rfc/rfc722.txt b/doc/rfc/rfc722.txt
new file mode 100644
index 0000000..0840547
--- /dev/null
+++ b/doc/rfc/rfc722.txt
@@ -0,0 +1,800 @@
+Network Working Group Jack Haverty (MIT)
+Request for Comments: 722 Sept 1976
+NIC #36806
+
+
+I. ABSTRACT
+
+
+ This paper addresses some issues concerned with the
+design of distributed services. In particular, it is
+concerned with the characteristics of the interactions,
+between programs which support some service at various
+network sites. The ideas presented are derived mainly from
+experience with various service protocols [Reference 1]
+on the ARPANET.
+
+ A model is developed of interactions between programs.
+Salient features of this model which promote and simplify
+the construction of reliable, responsive services are
+identified. These dualities are motivated by problems
+experienced with various ARPANET protocols and in the design
+and maintenance of programs which use these protocols in the
+performance of some service.
+
+ Using this model as a template, the general
+architecture of one possible interaction protocol is
+presented. This mechanism provides a foundation on which
+protocols would be constructed for particular services,
+simplifying the process of creating services which are easy
+to implement and maintain, and appear reliable and
+responsive to the customer. This presentation is meant to
+serve as an introduction to a specific instance of such a
+protocol, called the RRP, which is defined in one of the
+references.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -1-
+II. OVERVIEW AND TERMINOLOGY
+
+
+ This paper considers the interaction of two programs
+which support some network service. It develops a model of
+the interactions of a class of such applications, and
+includes some thoughts on desirable goals and
+characteristics of implementations. The model is derived
+from a proposal [Reference 2] for mail-handling
+systems. Terminology, as introduced, is highlighted by
+capitalization.
+
+ Many uses of computer networks involve communication
+directly between programs, without human intervention or
+monitoring. Some examples would include an advanced
+mail-handling system, or any kind of multi-site data base
+manager.
+
+ Such programs will be termed SERVERs. They are the
+users of some mechanism which provides the needed
+communication and synchronization. The particular facility
+which the servers implement will be termed a SERVICE.
+Servers for any particular service may be written in several
+languages, operate in various system environments on
+different kinds of computers. The entity which utilizes the
+service will be termed the CUSTOMER.
+
+ Servers interact during ENCOUNTERs, which are the
+periods when two servers are in communication. An encounter
+begins when one server establishes a CHANNEL, a
+bidirectional communication link with another server. The
+interaction between servers is effected by the exchange of
+information over the channel. The conventions used in such
+an exchange are defined by the PROTOCOLs for the
+interaction.
+
+ The theme of this paper is a model for a particular
+class of process interactions which may be used as a basis
+for many possible services, where the interactions are
+fairly simple. Services which fit in this category interact
+in a manner which can be modeled by a REQUEST-REPLY
+DISCIPLINE, which is defined herein.
+
+ A set of guidelines and goals is developed, which
+address issues relevant to ease or implementation and
+reliability of operation of servers. These guidelines may
+be used to assist in the formulation of protocols specific
+to appropriate services.
+
+
+
+
+
+
+
+
+ -2-
+ Additionally, the guidelines presented may be used as a
+basis for a general process interaction protocol, by
+extracting the primitives and operational concepts which
+would be common to a protocol constructed for virtually any
+such service.
+
+ From these ideas, a protocol which provides a
+foundation can be constructed, to be extended for particular
+services by adding primitives specific to each. The RRP
+[Reference 4] is one such possible protocol. It
+provides basic primitives to control the interaction between
+servers, and a mechanism for extending the primitives to
+include service-specific operations.
+
+ The discussion here is primarily intended to explain
+the basis for the design of the RRP, and to present some
+general issues of design of services.
+
+
+III. THE REQUEST-REPLY DISCIPLINE
+
+
+ The class of services relevant to this discussion are
+those whose interactions could be performed in the following
+manner.
+
+ Two servers have established a channel by some external
+means. A single interaction between servers begins with one
+server, called the REQUESTER, issuing a request. The server
+receiving that request, the RESPONDER, issues a REPLY. The
+requester interprets the reply sequence to determine whether
+the request was successful, failed, or partially failed, and
+takes appropriate action. Such a sequence of events is
+termed an EXCHANGE. This is analogous to a subroutine call
+in a simple single-processor operating system.
+
+ This model is termed a REQUEST-REPLY DISCIPLINE of
+program interaction. It should be noted that this is only a
+model of program behavior, and does not necessarily exclude
+services which require, for example, some measure of
+pipelining of requests for efficiency in long-delay
+situation;. In fact, most network services would require
+such measures, put their interactions can still be reduced
+to the request-reply model.
+
+ At any time, one of the partners is in control of the
+interaction, and is termed the MASTER of the interaction.
+The other partner is called the SLAVE. In the simplest
+cases, the requester is always the master, although this is
+not always true in particular implementations, such as the
+RRP [Reference 4].
+
+
+
+
+ -3-
+IV. CHARACTERISTICS OF AN INTERACTION MECHANISM
+
+
+ The following set of characteristics desirable in an
+interaction mechanism is the result of experience with
+program communication in various ARPANET applications, such
+as message services, file transfer, Datacomputer, and remote
+job entry applications.
+
+ In attempting to produce such systems, several
+qualities recurred which would be desirable in the
+substructure upon which the systems are built. These
+characteristics would promote ease of writing and debugging
+servers, maintaining reliability, and providing services
+which are responsive to customer needs, while avoiding
+disruptions of service.
+
+ The qualities desired in the interaction mechanism are
+presented along with a discussion of the effects which they
+are intended to produce in the associated services. It must
+be emphasized that this discussion is related to a class of
+simple services, and might not be appropriate for more
+complex applications.
+
+
+ 1/ Servers must be able to transfer data in a precise
+ fashion, retaining the structure and semantic
+ meaning of the data, despite the dissimilarities of
+ the computer systems in which they function.
+
+ 2/ Synchronization and timing problems due to the
+ characteristics of the communications link must be
+ isolated and handled separately from any which
+ might be characteristic of the service itself.
+
+ 3/ Since services may wish to provide expanded
+ facilities as they are used and developed, a
+ mechanism must be included to enable the service
+ protocol to evolve.
+
+ 4/ Since various programs which act as servers may
+ undergo simultaneous development, care must be
+ taken to insure that servers with different
+ capabilities interact reliably, maintaining at
+ least the same level of service as existed
+ previously.
+
+ 5/ The mechanisms for extending the facilities must
+ avoid requiring servers to be modified when new
+ capabilities are introduced, but not impede
+ progress by maintainers who are anxious to provide
+ a new or experimental service.
+
+
+
+
+ -4-
+ These qualities may be placed in three categories, data
+precision (1), process synchronization (2), and service
+enhancement (3, 4, 5). Each will be discussed separately in
+the following sections. The significance of each quality
+and its effect on the associated service characteristics
+will be included, with some references to related problems
+with current and past services.
+
+ Since these considerations are common to many possible
+services, it is appropriate for the interaction protocol to
+include them within its machinery as much as possible. This
+permits services to be implemented which, if carefully
+designed, inherit these properties from the interaction
+substrate.
+
+
+V. PRECISE DATA TRANSFER
+
+
+ Precision in data transfer permits semantic and
+structural information which exists in the sender's instance
+of a datum to be reproduced in the receiver's image of the
+datum, even though it may be represented in the systems
+involved in entirely different fashions.
+
+ For programs to provide powerful, reliable
+capabilities, they must be able to interact using data which
+is meaningful to the particular service involved. The
+interaction mechanism must permit services to define their
+own relevant data types, and transfer such items efficiently
+and precisely. This facility provides a 'standard' for data,
+permitting the service's designers to concentrate on
+higher-level issues of concern to the service itself.
+
+ Data of a given type should be recognizable as such
+without need for context. The mechanism should also permit
+new data types to be handled by older servers without error,
+even though they cannot interpret the semantics of the new
+data.
+
+ These characteristic permits services to be designed in
+terms of the abstract data they need to function, without
+continued detailed concern for the particular formats in
+which it is represented within various machines.
+
+ For example, servers may need to transfer a datum
+identifying a particular date, which may be represented
+internally within systems in different forms. The data
+transfer mechanism should be capable of transferring such a
+datum as a date per se, rather than a strict pattern or bits
+or characters.
+
+
+
+
+ -5-
+ For example, in current FTP-based mail systems,
+messages often contain information with significant semantic
+meaning, which is lost or obscured when transferred between
+sites. An example might be a file specification, which
+effectively loses all identity as such when translated into
+a simple character stream. People can usually recognize
+such streams as file names, but it is often extremely
+difficult, time-consuming, and inefficient to construct a
+program to do so reliably. As a result, services which
+should be easy to provide to the customer, such as automatic
+retrieval of relevant files, become difficult and
+unreliable.
+
+ Some success has been achieved in handling certain
+data, such as dates and times, by defining a particular
+character pattern which, if seen in a particular context,
+can be recognized as a date or time. Each of these cases
+has been done on an individual basis, by defining a format
+for the individual data of concern. Generally, the format
+depends to some extent on the datum occurring within a
+particular context, and is not unique enough to be
+identifiable outside of that context.
+
+ A particular service can achieve data precision by
+meticulous specification of the protocols by which data is
+transferred. This need is widespread enough, however, that
+it is appropriate to consider inclusion of a facility to
+provide data precision within the interaction mechanism
+itself.
+
+ The major effect of this would be to facilitate the
+design of reliable, responsive services, by relieving the
+service's designers from the need to consider very low-level
+details of data representation, which are usually the least
+interesting, but highly critical, aspects of the design. By
+isolating the data transfer mechanism, thIs architecture
+also promotes modularity or implementations, which can
+reduce the cost and time needed to implement or modify
+services.
+
+
+VI. PROCESS SYNCHRONIZATION
+
+ A major source of problems in many services involved
+synchronization of server; interacting over a relatively
+low-bandwidth, high-delay communications link.
+
+ Interactions in most services involve issuing a command
+and waiting for a response. The number of responses which
+can be elicited by a given command often varies, and there
+is usually no way to determine if all replies have arrived.
+Programs can easily issue a request before the responses to
+a previous request have completed, and get out of
+synchronization in a response is incorrectly matched to a
+request. Each server program must be meticulously designed
+to be capable of recovering if an unexpected reply arrives
+after a subsequent command is issued.
+
+ -6-
+ Note that, for reliable operation, it is always
+necessary that each response cause a reply to occur, at
+least in the sense that the request ts confirmed at some
+point. No service should perform a critical operation, such
+as deleting a file, which depends on the success of a
+previous request unless it has been confirmed. Requests in
+current protocols which do not appear to cause a reply may
+be viewed as confirmed later when a subsequent request is
+acknowledged, while such protocols work, they are more
+opaque than desirable, and consequently more difficult to
+implement.
+
+ These characteristics of protocols have often resulted
+in implementation of ad hoc methods for interaction, such as
+timeouts or sufficient length to assure correctness in an
+acceptably high percentage of situations. Often this has
+required careful tuning of programs as experience in using a
+protocol shows which commands are most likely to cause
+problems. Such methods generally result in a service which
+is less responsive, powerful, or efficient than desirable,
+and expensive to build and maintain.
+
+ Additionally, protocol specifications for services have
+often been incomplete, in that an enumeration of the
+responses which may occur for a given command is inaccurate
+or non-existent. This greatly complicates the task of the
+programmer trying to construct an intelligent server. In
+most cases, servers are slowly improved over time as
+experience shows which responses are common in each
+instance.
+
+ The synchronization problems mentioned above are in
+addition to those which naturally occur as part of the
+service operation. Thus, problems of synchronization may
+be split into two classes, those inherent in the service,
+and those associated with the interaction mechanism itself.
+
+ Construction of reliable, responsive servers can be
+assisted by careful design of the interaction mechanism and
+protocols. An unambiguous, completely specified mapping
+between commands and responses is desirable.
+Synchronization considerations of the two types can be
+attacked separately. An interaction mechanism which handles
+its own synchronization can be provided as a base for
+service' designers to use, relieving them of considerations
+of the low-level, protocol-derived problems, by providing
+primitives which encourage the design of reliable services.
+
+ To achieve a reasonable effective bandwidth, it is
+usually desirable to permit interacting programs to operate
+in a full-duplex fashion. Significant amounts of data are
+often in transit at any time. This magnifies the problems
+associated with interaction by introducing parallelism. The
+interaction mechanism can also be structured to provide ways
+of handling these problems, and to provide a basis on which
+servers which exploit parallelism can be constructed.
+
+
+ -7-
+ Many of these problems are too complex to warrant their
+consideration in any but the most active services. As a
+result, services are often constructed which avoid
+problems by inefficiencies in their operation, as mentioned
+above. Provision of an interaction mechanism and primitives
+for use by such services would promote efficiency interaction
+even by simple services which do not have the resources to
+consider all the problems in detail.
+
+
+VII. SERVICE ENHANCEMENT
+
+
+ When particular programs implementing a service are
+undergoing development simultaneously by several
+organizations, or are maintained at many distributed sites.
+many problems can develop concerning the compatibility of
+dissimilar servers.
+
+ This situation occurs in the initial phase of
+implementing a service, as well as whenever the protocols
+are modified to fix problems or expand the service.
+Virtually every interaction protocol is modified from time
+to time to add new capabilities. Two particular examples
+arc the TELNET protocol and mail header formats.
+
+ In most cases, the basic protocol had no facility for
+implementing changes in an invisible fashion. This has had
+several consequences.
+
+ First, it is very difficult to change a protocol unless
+the majority of concerned maintainers are interested in the
+changes and therefore willing to exert effort to change the
+programs involved. This situation has occurred in previous
+cases because any change necessarily impacts all servers.
+The services involved therefore often stagnate, and it
+becomes inappropriately difficult to provide a customer with
+a seemingly simple enhancement.
+
+ Second, when protocols change by will of the majority,
+existing servers often stop working or behave erratically
+which they suddenly find their partner speaking a new
+language. This is equally disconcerting to the service
+customer, as well as annoying to the maintainers of the
+servers at the various sites affected.
+
+ These problems can be easily avoided, or at least
+significantly reduced, by careful design of the interaction
+protocols. In particular, the interaction mechanism itself
+can be structured to avoid the problem entirely, leaving
+only those problems associated with the particular service
+operations themselves.
+
+ The interaction machinery should be structured so that
+the mechanisms of the interaction substrate itself may be
+improved or expanded in a fashion which is absolutely
+invisible to current servers.
+
+ -8-
+ 1/ No server should be required to implement a change
+ which is unimportant to its customers.
+
+ 2/ No server should be prevented from utilizing a new
+ facility when interacting with a willing partner.
+
+ 3/ Service should not be degraded in any way when a
+ new protocol facility is made available.
+
+ In cases where a single service is provided by
+different server programs at many sites, it is desirable for
+the various sites to be able to participate at a level
+appropriate to them. A new server program should be able to
+participate quickly, using only simple mechanisms of the
+protocol, and evolve into more advanced, powerful, or
+efficient interaction as desired. Sites wishing to utilize
+advanced or experimental features must be allowed to do so
+without imposing implementation of such features on others.
+Conversely, sites wishing to participate in a minimal
+fashion must not prevent others from using advanced
+features. In all cases, the various servers must be capable
+of continued interaction at the highest level supported by
+both.
+
+ The goal is an evolving system which maintains
+reliability as well as both upward and downward
+compatibility. The protocol itself should have these
+characteristics, and it should provide the mechanisms to
+service interaction protocols to be defined which
+inherit these qualities.
+
+
+
+VIII. STRUCTURING AN INTERACTION MECHANISM
+
+
+ The qualities presented previously should provide at
+least a starting point for implementation of services which
+avoid the problems mentioned. The rest of this paper
+addresses issues of a particular possible architecture of an
+interaction mechanism.
+
+ The design architecture splits the service-specific
+conventions from those of the interaction per se. An
+interaction protocol is provided which implements the
+machinery of the request-reply model, and includes handling
+of the problems of data precision, synchronization, and
+enhancement. This protocol is not specific to any service,
+but rather provides primitives, in the form of
+service-designed requests and replies, on which a particular
+service protocol is built.
+
+ An actual implementation for a particular service could
+merge the code of the interaction protocol with the service
+itself, or the interaction protocol could be provided as a
+'service' whose customer is the service being implemented.
+
+ -9-
+ The goals of this design architecture follow.
+
+ 1/ Provision of a general interaction mechanism to be
+ used by services which follow a request-reply
+ discipline. Services would design their protocols
+ using the primitives of the mechanism as a
+ foundation.
+
+ 2/ INTERACTION MECHANISM EXTENSIBILITY. The
+ interaction mechanism may be expanded as desired
+ without impacting on existing servers unless they
+ wish to use the new features.
+
+ 3/ SERVER EXTENSIBILITY. Servers can be implemented
+ using the most basic primitives. Implementations
+ may later be extended to utilize additional
+ capabilities to negate some of the inefficiency
+ inherent in a strict request-reply structure.
+
+ 4/ SERVICE EXTENSIBILITY. The primitives permit a
+ service to be expanded as desired without impacting
+ on existing servers in any way unless they wish to
+ use the new features.
+
+ 5/ SERVER COMPATIBILITY. Within the set of servers of
+ a given application, it is possible to have
+ different servers operating at different levels of
+ sophistication, and still maintain the ability for
+ any pair of servers to interact successfully.
+
+ These goals involve two basic areas of design. First,
+the interaction mechanism itself is designed to meet the
+goals. Secondly, guidelines for structure of the particular
+service' protocols are necessary, in order for it to inherit
+the qualities needed to meet the goals.
+
+
+
+IX. PARTITIONING THE PROBLEM
+
+
+
+ In defining the interaction mechanism itself, the
+problem may be simplified by considering two areas of
+concern separately.
+
+
+
+ 1/ The characteristics and format of the data conveyed
+ by the channel may be defined.
+
+ 2/ The conventions used to define the interaction may
+ be defined, in terms of the available data
+ supported by the channel.
+
+
+ -10-
+ For purposes of this paper, the data repertoire and
+characteristics of the channel are assumed to be as
+described in [Reference 3] and summarized in an
+appendix. Discussions of the interaction between servers
+will use only the abstract concepts of primitive and
+semantic data items, to isolate the issues of interaction
+from those of data formats and communication details, and
+therefore simplify the problem.
+
+ Additionally, actual implementation of a mechanism
+following the ideas presented here can be accomplished in a
+modular fashion, isolating code which is concerned with the
+channel itself from code concerned with the interaction
+behavior.
+
+ The interaction mechanism provides primitives to the
+service' designer which are likewise defined in terms of the
+data items available. Service designers are encouraged, but
+not required, to define interactions in terms of these data
+only.
+
+
+
+X. THE PRIMITIVES
+
+
+
+ The interaction mechanism assumes the existence of a
+channel [Reference 3] between two servers. Two
+new semantic data types are defined to implement the
+interaction. These are, unsurprisingly, called CONTROL
+REQUESTs and CONTROL REPLYs. Each of these data items
+contains at least two elements.
+
+
+
+ 1/ The TYPE element identifies a particular type of
+ request or reply.
+
+ 2/ The SEQUENCE element is used to match replies to
+ their corresponding request.
+
+ Other elements may appear. Their interpretation
+depends on the particular type of request or reply in which
+they appear.
+
+ The interaction protocol itself is defined in terms of
+control requests and control replies. A very small number
+of request and reply types is defined as the minimal
+implementation level. Additional request and reply types
+are also defined, for use by more advanced servers, to
+Provide additional capabilities to the service, or simply to
+increase efficiency of operation.
+
+
+ -11-
+ Two additional data items are defined, called USER
+REQUESTs and USER REPLYs. These are structured like
+requests and replies, but the various types are defined by
+the service itself, to implement the primitives needed in
+its operation.
+
+ Control and user requests and replies are generically
+referenced as simply REQUESTs and REPLYs.
+
+ The protocol of the interaction has several
+characteristics which form the basis of the request-reply
+model, and attempt to meet the goals mentioned previously.
+
+ 1/ Every request elicits a reply.
+
+ 2/ Every reply is associated unambiguously with a
+ previous request.
+
+ 3/ Each server always knows the state of the
+ interaction, such as whether or not more data is
+ expected from its partner.
+
+ 4/ The protocol definition includes enumeration of the
+ possible responses for each request. Service
+ protocols are encouraged to do likewise for user
+ requests and user replies.
+
+ 5/ Servers who receive requests of unknown type issue
+ a response which effectively refuses the request.
+ Servers attempting to use advanced features of a
+ protocol 'rephrase' their requests in simpler terms
+ where possible to maintain the previous level of
+ service.
+
+ The minimal implementation will support interaction
+almost exactly along the lines of the request-reply
+discipline.
+
+ Extensions to the minimal configuration are defined for
+two reasons. First, the strict request-reply discipline
+model is inefficient for use in high-volume situations
+because of the delays involved. Several extensions are
+defined to cope with this problem. Thus, although the
+interaction is based on such a discipline, it does not
+necessarily implement the interaction in that fashion.
+Second, additional primitives are defined which provide some
+standard process synchronization operations, for use by the
+services.
+
+ The protocol architecture presented here is defined in
+detail in an associated document. [Reference 4]
+
+
+
+
+ -12-
+
+Appendix I -- The Channel
+
+ The following discussion is a summary of the ideas
+presented in [Reference 3], which should be
+consulted for further detail.
+
+ The communication link between two servers is termed a
+CHANNEL. Channels provide bidirectional communications
+capabilities, and will usually be full-duplex. The programs
+involved establish the channel as their individual
+applications require, using some form of initial connection
+protocol.
+
+ The channel acts as an interface between servers. It
+conveys abstract data items whose semantics are understood
+by the programmers involved, such as INTEGERs, STRINGs, FILE
+PATH NAMEs, and so on. Because the users of the channel may
+operate in dissimilar computer environments, their
+communication is defined only in terms of such abstract data
+items, which are the atomic units of information carried on
+the channel. The program implementing the channel at each
+site converts the data between an encoded transmission
+format appropriate to the particular communication link
+involved, and whatever internal representational form is
+appropriate in the computer itself.
+
+ The channel protocol provides a mechanism for
+definition of various types of data items of semantic value
+for the particular service concerned, for example, possibly,
+user-name, set, syllable, sentence, and other data items of
+interest to the particular service. The channel provides a
+mechanism for transportation of such user-defined data from
+host to host.
+
+ The channel may actually be implemented by one or more
+separate encoding mechanisms which would be used in
+different conditions, initially, the channel machinery would
+provide a rudimentary facility based on a single mechanism
+such as the MSDTP [Reference 3].
+
+ The mechanism is not dependent on the existence of
+actual line-style network connections but will operate in
+other environments, such as a message-oriented (as opposed
+to connection-oriented) communications architecture, and in
+fact is more naturally structured for such an environment.
+
+
+
+
+
+
+
+
+ -13-
+
+XI. REFERENCES
+
+
+
+[1] Network Information Center, ARPANET Protocol Handbook,
+April, 1976.
+
+[2] Broos, Haverty, Vezza, Message Services Protocol
+proposal, December, 1975.
+
+[3] Haverty, Jack, Message Services Data Transfer Protocol,
+NWG RFC 713, NIC 34729, April, 1976.
+
+[4] Haverty, Jack, RRP, A Process Communication Protocol for
+Request-reply Disciplines, NWG RFC 723, NIC 36807, (to
+be issued)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -14-