home *** CD-ROM | disk | FTP | other *** search
- 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-rep
-