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