Movatterモバイル変換

Network Working Group                                       Jack Haverty  (MIT)Request for Comments: 722                                             Sept 1976NIC #36806I. ABSTRACT     This paper addresses some issues concerned with thedesign of distributed services.  In particular, it isconcerned with the characteristics of the interactions,between programs which support some service at variousnetwork sites.  The ideas presented are derived mainly fromexperience 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 simplifythe construction of reliable, responsive services areidentified.  These dualities are motivated by problemsexperienced with various ARPANET protocols and in the designand maintenance of programs which use these protocols in theperformance of some service.     Using this model as a template, the generalarchitecture of one possible interaction protocol ispresented.  This mechanism provides a foundation on whichprotocols would be constructed for particular services,simplifying the process of creating services which are easyto implement and maintain, and appear reliable andresponsive to the customer.  This presentation is meant toserve as an introduction to a specific instance of such aprotocol, called the RRP, which is defined in one of thereferences.                                -1-

II. OVERVIEW AND TERMINOLOGY     This paper considers the interaction of two programswhich support some network service.  It develops a model ofthe interactions of a class of such applications, andincludes some thoughts on desirable goals andcharacteristics of implementations.  The model is derivedfrom a proposal [Reference 2] for mail-handlingsystems.  Terminology, as introduced, is highlighted bycapitalization.     Many uses of computer networks involve communicationdirectly between programs, without human intervention ormonitoring.  Some examples would include an advancedmail-handling system, or any kind of multi-site data basemanager.     Such programs will be termed SERVERs.  They are theusers of some mechanism which provides the neededcommunication and synchronization.  The particular facilitywhich the servers implement will be termed a SERVICE.Servers for any particular service may be written in severallanguages, operate in various system environments ondifferent kinds of computers.  The entity which utilizes theservice will be termed the CUSTOMER.     Servers interact during ENCOUNTERs, which are theperiods when two servers are in communication.  An encounterbegins when one server establishes a CHANNEL, abidirectional communication link with another server.  Theinteraction between servers is effected by the exchange ofinformation over the channel.  The conventions used in suchan exchange are defined by the PROTOCOLs for theinteraction.     The theme of this paper is a model for a particularclass of process interactions which may be used as a basisfor many possible services, where the interactions arefairly simple.  Services which fit in this category interactin a manner which can be modeled by a REQUEST-REPLYDISCIPLINE, which is defined herein.     A set of guidelines and goals is developed, whichaddress issues relevant to ease or implementation andreliability of operation of servers.  These guidelines maybe used to assist in the formulation of protocols specificto appropriate services.                                -2-

     Additionally, the guidelines presented may be used as abasis for a general process interaction protocol, byextracting the primitives and operational concepts whichwould be common to a protocol constructed for virtually anysuch service.     From these ideas, a protocol which provides afoundation can be constructed, to be extended for particularservices by adding primitives specific to each.  The RRP[Reference 4] is one such possible protocol.  Itprovides basic primitives to control the interaction betweenservers, and a mechanism for extending the primitives toinclude service-specific operations.     The discussion here is primarily intended to explainthe basis for the design of the RRP, and to present somegeneral issues of design of services.III. THE REQUEST-REPLY DISCIPLINE     The class of services relevant to this discussion arethose whose interactions could be performed in the followingmanner.     Two servers have established a channel by some externalmeans.  A single interaction between servers begins with oneserver, called the REQUESTER, issuing a request.  The serverreceiving that request, the RESPONDER, issues a REPLY.  Therequester interprets the reply sequence to determine whetherthe request was successful, failed, or partially failed, andtakes appropriate action.  Such a sequence of events istermed an EXCHANGE.  This is analogous to a subroutine callin a simple single-processor operating system.     This model is termed a REQUEST-REPLY DISCIPLINE ofprogram interaction.  It should be noted that this is only amodel of program behavior, and does not necessarily excludeservices which require, for example, some measure ofpipelining of requests for efficiency in long-delaysituation;.  In fact, most network services would requiresuch measures, put their interactions can still be reducedto the request-reply model.     At any time, one of the partners is in control of theinteraction, and is termed the MASTER of the interaction.The other partner is called the SLAVE.  In the simplestcases, the requester is always the master, although this isnot always true in particular implementations, such as theRRP [Reference 4].                                -3-

IV. CHARACTERISTICS OF AN INTERACTION MECHANISM     The following set of characteristics desirable in aninteraction mechanism is the result of experience withprogram communication in various ARPANET applications, suchas message services, file transfer, Datacomputer, and remotejob entry applications.     In attempting to produce such systems, severalqualities recurred which would be desirable in thesubstructure upon which the systems are built.  Thesecharacteristics would promote ease of writing and debuggingservers, maintaining reliability, and providing serviceswhich are responsive to customer needs, while avoidingdisruptions of service.     The qualities desired in the interaction mechanism arepresented along with a discussion of the effects which theyare intended to produce in the associated services.  It mustbe emphasized that this discussion is related to a class ofsimple services, and might not be appropriate for morecomplex 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, dataprecision (1), process synchronization (2), and serviceenhancement (3, 4, 5).  Each will be discussed separately inthe following sections.  The significance of each qualityand its effect on the associated service characteristicswill be included, with some references to related problemswith current and past services.     Since these considerations are common to many possibleservices, it is appropriate for the interaction protocol toinclude them within its machinery as much as possible.  Thispermits services to be implemented which, if carefullydesigned, inherit these properties from the interactionsubstrate.V. PRECISE DATA TRANSFER     Precision in data transfer permits semantic andstructural information which exists in the sender's instanceof a datum to be reproduced in the receiver's image of thedatum, even though it may be represented in the systemsinvolved in entirely different fashions.     For programs to provide powerful, reliablecapabilities, they must be able to interact using data whichis meaningful to the particular service involved.  Theinteraction mechanism must permit services to define theirown relevant data types, and transfer such items efficientlyand precisely.  This facility provides a 'standard' for data,permitting the service's designers to concentrate onhigher-level issues of concern to the service itself.     Data of a given type should be recognizable as suchwithout need for context.  The mechanism should also permitnew data types to be handled by older servers without error,even though they cannot interpret the semantics of the newdata.     These characteristic permits services to be designed interms of the abstract data they need to function, withoutcontinued detailed concern for the particular formats inwhich it is represented within various machines.     For example, servers may need to transfer a datumidentifying a particular date, which may be representedinternally within systems in different forms.  The datatransfer mechanism should be capable of transferring such adatum as a date per se, rather than a strict pattern or bitsor characters.                                -5-

     For example, in current FTP-based mail systems,messages often contain information with significant semanticmeaning, which is lost or obscured when transferred betweensites.  An example might be a file specification, whicheffectively loses all identity as such when translated intoa simple character stream.  People can usually recognizesuch streams as file names, but it is often extremelydifficult, time-consuming, and inefficient to construct aprogram to do so reliably.  As a result, services whichshould be easy to provide to the customer, such as automaticretrieval of relevant files, become difficult andunreliable.     Some success has been achieved in handling certaindata, such as dates and times, by defining a particularcharacter pattern which, if seen in a particular context,can be recognized as a date or time.  Each of these caseshas been done on an individual basis, by defining a formatfor the individual data of concern.  Generally, the formatdepends to some extent on the datum occurring within aparticular context, and is not unique enough to beidentifiable outside of that context.     A particular service can achieve data precision bymeticulous specification of the protocols by which data istransferred.  This need is widespread enough, however, thatit is appropriate to consider inclusion of a facility toprovide data precision within the interaction mechanismitself.     The major effect of this would be to facilitate thedesign of reliable, responsive services, by relieving theservice's designers from the need to consider very low-leveldetails of data representation, which are usually the leastinteresting, but highly critical, aspects of the design.  Byisolating the data transfer mechanism, thIs architecturealso promotes modularity or implementations, which canreduce the cost and time needed to implement or modifyservices.VI. PROCESS SYNCHRONIZATION     A major source of problems in many services involvedsynchronization of server; interacting over a relativelylow-bandwidth, high-delay communications link.     Interactions in most services involve issuing a commandand waiting for a response.  The number of responses whichcan be elicited by a given command often varies, and thereis usually no way to determine if all replies have arrived.Programs can easily issue a request before the responses toa previous request have completed, and get out ofsynchronization in a response is incorrectly matched to arequest.  Each server program must be meticulously designedto be capable of recovering if an unexpected reply arrivesafter a subsequent command is issued.                                -6-

     Note that, for reliable operation, it is alwaysnecessary that each response cause a reply to occur, atleast in the sense that the request ts confirmed at somepoint.  No service should perform a critical operation, suchas deleting a file, which depends on the success of aprevious request unless it has been confirmed.  Requests incurrent protocols which do not appear to cause a reply maybe viewed as confirmed later when a subsequent request isacknowledged, while such protocols work, they are moreopaque than desirable, and consequently more difficult toimplement.     These characteristics of protocols have often resultedin implementation of ad hoc methods for interaction, such astimeouts or sufficient length to assure correctness in anacceptably high percentage of situations.  Often this hasrequired careful tuning of programs as experience in using aprotocol shows which commands are most likely to causeproblems.  Such methods generally result in a service whichis less responsive, powerful, or efficient than desirable,and expensive to build and maintain.     Additionally, protocol specifications for services haveoften been incomplete, in that an enumeration of theresponses which may occur for a given command is inaccurateor non-existent.  This greatly complicates the task of theprogrammer trying to construct an intelligent server.  Inmost cases, servers are slowly improved over time asexperience shows which responses are common in eachinstance.     The synchronization problems mentioned above are inaddition to those which naturally occur as part of theservice operation.  Thus, problems of synchronization maybe split into two classes, those inherent in the service,and those associated with the interaction mechanism itself.     Construction of reliable, responsive servers can beassisted by careful design of the interaction mechanism andprotocols.  An unambiguous, completely specified mappingbetween commands and responses is desirable.Synchronization considerations of the two types can beattacked separately.  An interaction mechanism which handlesits own synchronization can be provided as a base forservice' designers to use, relieving them of considerationsof the low-level, protocol-derived problems, by providingprimitives which encourage the design of reliable services.     To achieve a reasonable effective bandwidth, it isusually desirable to permit interacting programs to operatein a full-duplex fashion.  Significant amounts of data areoften in transit at any time.  This magnifies the problemsassociated with interaction by introducing parallelism.  Theinteraction mechanism can also be structured to provide waysof handling these problems, and to provide a basis on whichservers which exploit parallelism can be constructed.                                -7-

     Many of these problems are too complex to warrant theirconsideration in any but the most active services.  As aresult, services are often constructed which avoidproblems by inefficiencies in their operation, as mentionedabove.  Provision of an interaction mechanism and primitivesfor use by such services would promote efficiency interactioneven by simple services which do not have the resources toconsider all the problems in detail.VII. SERVICE ENHANCEMENT     When particular programs implementing a service areundergoing development simultaneously by severalorganizations, or are maintained at many distributed sites.many problems can develop concerning the compatibility ofdissimilar servers.     This situation occurs in the initial phase ofimplementing a service, as well as whenever the protocolsare modified to fix problems or expand the service.Virtually every interaction protocol is modified from timeto time to add new capabilities.  Two particular examplesarc the TELNET protocol and mail header formats.     In most cases, the basic protocol had no facility forimplementing changes in an invisible fashion.  This has hadseveral consequences.     First, it is very difficult to change a protocol unlessthe majority of concerned maintainers are interested in thechanges and therefore willing to exert effort to change theprograms involved.  This situation has occurred in previouscases because any change necessarily impacts all servers.The services involved therefore often stagnate, and itbecomes inappropriately difficult to provide a customer witha seemingly simple enhancement.     Second, when protocols change by will of the majority,existing servers often stop working or behave erraticallywhich they suddenly find their partner speaking a newlanguage.  This is equally disconcerting to the servicecustomer, as well as annoying to the maintainers of theservers at the various sites affected.     These problems can be easily avoided, or at leastsignificantly reduced, by careful design of the interactionprotocols.  In particular, the interaction mechanism itselfcan be structured to avoid the problem entirely, leavingonly those problems associated with the particular serviceoperations themselves.     The interaction machinery should be structured so thatthe mechanisms of the interaction substrate itself may beimproved or expanded in a fashion which is absolutelyinvisible 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 bydifferent server programs at many sites, it is desirable forthe various sites to be able to participate at a levelappropriate to them.  A new server program should be able toparticipate quickly, using only simple mechanisms of theprotocol, and evolve into more advanced, powerful, orefficient interaction as desired.  Sites wishing to utilizeadvanced or experimental features must be allowed to do sowithout imposing implementation of such features on others.Conversely, sites wishing to participate in a minimalfashion must not prevent others from using advancedfeatures.  In all cases, the various servers must be capableof continued interaction at the highest level supported byboth.     The goal is an evolving system which maintainsreliability as well as both upward and downwardcompatibility.  The protocol itself should have thesecharacteristics, and it should provide the mechanisms toservice interaction protocols to be defined whichinherit these qualities.VIII. STRUCTURING AN INTERACTION MECHANISM     The qualities presented previously should provide atleast a starting point for implementation of services whichavoid the problems mentioned.  The rest of this paperaddresses issues of a particular possible architecture of aninteraction mechanism.     The design architecture splits the service-specificconventions from those of the interaction per se.  Aninteraction protocol is provided which implements themachinery of the request-reply model, and includes handlingof the problems of data precision, synchronization, andenhancement.  This protocol is not specific to any service,but rather provides primitives, in the form ofservice-designed requests and replies, on which a particularservice protocol is built.     An actual implementation for a particular service couldmerge the code of the interaction protocol with the serviceitself, 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 thegoals.  Secondly, guidelines for structure of the particularservice' protocols are necessary, in order for it to inheritthe qualities needed to meet the goals.IX. PARTITIONING THE PROBLEM     In defining the interaction mechanism itself, theproblem may be simplified by considering two areas ofconcern 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 andcharacteristics of the channel are assumed to be asdescribed in [Reference 3] and summarized in anappendix.  Discussions of the interaction between serverswill use only the abstract concepts of primitive andsemantic data items, to isolate the issues of interactionfrom those of data formats and communication details, andtherefore simplify the problem.     Additionally, actual implementation of a mechanismfollowing the ideas presented here can be accomplished in amodular fashion, isolating code which is concerned with thechannel itself from code concerned with the interactionbehavior.     The interaction mechanism provides primitives to theservice' designer which are likewise defined in terms of thedata items available.  Service designers are encouraged, butnot required, to define interactions in terms of these dataonly.X. THE PRIMITIVES     The interaction mechanism assumes the existence of achannel [Reference 3] between two servers.  Twonew semantic data types are defined to implement theinteraction.  These are, unsurprisingly, called CONTROLREQUESTs and CONTROL REPLYs.  Each of these data itemscontains 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 interpretationdepends on the particular type of request or reply in whichthey appear.     The interaction protocol itself is defined in terms ofcontrol requests and control replies.  A very small numberof request and reply types is defined as the minimalimplementation level.  Additional request and reply typesare also defined, for use by more advanced servers, toProvide additional capabilities to the service, or simply toincrease efficiency of operation.                                -11-

     Two additional data items are defined, called USERREQUESTs and USER REPLYs.  These are structured likerequests and replies, but the various types are defined bythe service itself, to implement the primitives needed inits operation.     Control and user requests and replies are genericallyreferenced as simply REQUESTs and REPLYs.     The protocol of the interaction has severalcharacteristics which form the basis of the request-replymodel, 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 interactionalmost exactly along the lines of the request-replydiscipline.     Extensions to the minimal configuration are defined fortwo reasons.  First, the strict request-reply disciplinemodel is inefficient for use in high-volume situationsbecause of the delays involved.  Several extensions aredefined to cope with this problem.  Thus, although theinteraction is based on such a discipline, it does notnecessarily implement the interaction in that fashion.Second, additional primitives are defined which provide somestandard process synchronization operations, for use by theservices.     The protocol architecture presented here is defined indetail in an associated document.  [Reference 4]                                -12-

Appendix I -- The Channel     The following discussion is a summary of the ideaspresented in [Reference 3], which should beconsulted for further detail.     The communication link between two servers is termed aCHANNEL.  Channels provide bidirectional communicationscapabilities, and will usually be full-duplex.  The programsinvolved establish the channel as their individualapplications require, using some form of initial connectionprotocol.     The channel acts as an interface between servers.  Itconveys abstract data items whose semantics are understoodby the programmers involved, such as INTEGERs, STRINGs, FILEPATH NAMEs, and so on.  Because the users of the channel mayoperate in dissimilar computer environments, theircommunication is defined only in terms of such abstract dataitems, which are the atomic units of information carried onthe channel.  The program implementing the channel at eachsite converts the data between an encoded transmissionformat appropriate to the particular communication linkinvolved, and whatever internal representational form isappropriate in the computer itself.     The channel protocol provides a mechanism fordefinition of various types of data items of semantic valuefor the particular service concerned, for example, possibly,user-name, set, syllable, sentence, and other data items ofinterest to the particular service.  The channel provides amechanism for transportation of such user-defined data fromhost to host.     The channel may actually be implemented by one or moreseparate encoding mechanisms which would be used indifferent conditions, initially, the channel machinery wouldprovide a rudimentary facility based on a single mechanismsuch as the MSDTP [Reference 3].     The mechanism is not dependent on the existence ofactual line-style network connections but will operate inother environments, such as a message-oriented (as opposedto connection-oriented) communications architecture, and infact 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 Protocolproposal, December, 1975.[3] Haverty, Jack, Message Services Data Transfer Protocol,NWGRFC 713, NIC 34729, April, 1976.[4] Haverty, Jack, RRP, A Process Communication Protocol forRequest-reply Disciplines, NWGRFC 723, NIC 36807, (tobe issued)                             -14-