Thoughts on Interactions in Distributed Services
RFC 722

Document Type RFC - Unknown (September 1976; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 722 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text