Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
UNKNOWN
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource SharingTHE GOAL, RESOURCE SHARING 1 The principal goal of all resource-sharing computer networks,including the now international ARPA Network (the ARPANET), is tousefully interconnect geographically distributed hardware, software,and human resources [1]. Achieving this goal requires the designand implementation of various levels of support software within eachconstituent computer, and the specification of network-wide"protocols" (that is, conventions regarding the format and therelative timing of network messages) governing their interaction.This paper outlines an alternative to the approach that ARPANETsystem builders have been taking since work in this area began in1970, and suggests a strategy for modeling distributed systemswithin any large computer network. 1a The first section of this paper describes the prevailing ARPANETprotocol strategy, which involves specifying a family ofapplication-dependent protocols with a network-wide inter-processcommunication facility as their common foundation. In the secondsection, the application-independent command/response disciplinethat characterizes this protocol family is identified and itsisolation as a separate protocol proposed. Such isolation wouldreduce the work of the applications programmer by allowing thesoftware that implements the protocol to be factored out of eachapplications program and supplied as a single,installation-maintained module. The final section of this paperproposes an extensible model for this class of network interactionthat in itself would even further encourage the use of networkresources. 1b -1-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing The Current Software Approach to Resource SharingTHE CURRENT SOFTWARE APPROACH TO RESOURCE SHARING 2Function-Oriented Protocols 2a The current ARPANET software approach to facilitating resourcesharing has been detailed elsewhere in the literature [2, 3, 4].Briefly, it involves defining a Host-Host Protocol by which theoperating systems of the various "host" computers cooperate tosupport a network-wide inter-process communication (IPC) facility,and then various function-oriented protocols by which processesdeliver and receive specific services via IPC. Eachfunction-oriented protocol regulates the dialog between a resident"server process" providing the service, and a "user process" seekingthe service on behalf of a user (the terms "user" and "user process"will be used consistently throughout this paper to distinguish thehuman user from the computer process acting on his behalf). 2a1 The current Host-Host Protocol has been in service since 1970.Since its initial design and implementation, a variety ofdeficiencies have been recognized and several alternative protocolssuggested [5, 6]. Although improvements at this level would surelyhave a positive effect upon Network resource sharing, the presentpaper simply assumes the existence of some form of IPC and focusesattention upon higher level protocol design issues. 2a2 Each of the function-oriented protocols mentioned in this paperconstitutes the official ARPANET protocol for its respectiveapplication domain and is therefore implemented at nearly all of the75 host installations that now comprise the Network.It isprimarily upon this widely implemented protocol family (and thephilosophy it represents) that the present paper focuses. Needlessto say, other important resource sharing tools have also beenconstructed within the ARPANET. The Resource Sharing Executive(RSEXEC), designed and implemented by Bolt, Beranek and Newman, Inc[7], provides an excellent example of such work. 2a3Experience with and Limitations of Hands-On Resource Sharing 2b The oldest and still by far the most heavily usedfunction-oriented protocol is the Telecommunications Networkprotocol (TELNET) [8], which effectively attaches a terminal on onecomputer to an interactive time-sharing system on another, andallows a user to interact with the remote system via the terminal asif he were one of its local users. 2b1 -2-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing The Current Software Approach to Resource Sharing As depicted in Figure 1, TELNET specifies the means by which auser process monitoring the user's terminal is interconnected, viaan IPC communication channel, with a server process with access tothe target time-sharing system. TELNET also legislates a standardcharacter set in which the user's commands and the system'sresponses are to be represented in transmission between machines.The syntax and semantics of these interchanges, however, vary fromone system to another and are unregulated by the protocol; the userand server processes simply shuttle characters between the humanuser and the target system. 2b2 Although the hands-on use of remote resources that TELNET makespossible is a natural and highly visible form of resource sharing,several limitations severely reduce its long-term utility: 2b3 (1) It forces upon the user all of the trappings of the resource's own system. To exploit a remote resource, the user must leave the familiar working environment provided by his local system and enter an alien one with its own peculiar system structure (login, logout, and subsystem entry and exit procedures) and command language discipline (command recognition and completion conventions, editing characters, and so on). Hands-on resource sharing thus fails to provide the user with the kind of organized and consistent workshop he requires to work effectively [9]. (2) It provides no basis for bootstrapping new composite resources from existing ones. Because the network access discipline imposed by each resource is a human-engineered command language, rather than a machine-oriented communication protocol, it is virtually impossible for one resource to programatically draw upon the services of others. Doing so would require that the program deal successfully with complicated echoing and feedback characteristics; unstructured, even unsolicited system responses; and so forth. Hands-on resource sharing thus does nothing to provide an environment in which existing resources can be used as building blocks to construct new, more powerful ones. These inherent limitations of hands-on resource sharing areremoved by a protocol that simplifies and standardizes the dialogbetween user and server processes. Given such a protocol, the -3-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing The Current Software Approach to Resource Sharingvarious remote resources upon which a user might wish to draw canindeed be made to appear as a single, coherent workshop byinterposing between him and them a command language interpreter thattransforms his commands into the appropriate protocol utterances[10, 11]. The construction of composite resources also becomesfeasible, since each resource is accessible by means of amachine-oriented protocol and can thus be readily employed by otherprocesses within the network. 2b4Standardizing the Inter-Machine Dialog in Specific Application Areas 2c After the TELNET protocol had been designed and widelyimplemented within the ARPANET, work began on a family offunction-oriented protocols designed for use by programs, ratherthan human users. Each such protocol standardizes the inter-machinedialog in a particular application area. While TELNET dictates onlythe manner in which user and server processes are interconnected viathe IPC facility, and the character set in which the two processescommunicate once connected, each member of this family specifies inaddition the syntax and semantics of the commands and responses thatcomprise their dialog. 2c1 Protocols within this family necessarily differ in substance,each specifying its own application-specific command set. The FileTransfer Protocol (FTP) [12], for example, specifies commands formanipulating files, and the Remote Job Entry Protocol (RJE) [13]specifies commands for manipulating batch jobs. Protocolsthroughout the family are, however, similar in form, each successivefamily member having simply inherited the physical features of itspredecessors. Thus FTP and RJE enforce the same conventions forformulating commands and responses. 2c2 This common command/response discipline requires that commandsand responses have the following respective formats: 2c3 command-name <SP> parameter <CRLF> response-number <SP> text <CRLF>Each command invoked by the user process is identified by NAME andis allowed a single PARAMETER. Each response generated by theserver process contains a three-digit decimal response NUMBER (to beinterpreted by the user process) and explanatory TEXT (forpresentation, if necessary, to the user). Response numbers areassigned in such a way that, for example, positive and negativeacknowledgments can be easily distinguished by the user process. 2c4 -4-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing The Current Software Approach to Resource Sharing FTP contains, among others, the following commands (each listedwith one of its possible responses) for retrieving, appending to,replacing, and deleting files, respectively, within the serverprocess' file system: 2c5 Command Response RETR <SP> filename <CRLF> 250 <SP> Beginning transfer. <CRLF> APPE <SP> filename <CRLF> 400 <SP> Not implemented. <CRLF> STOR <SP> filename <CRLF> 453 <SP> Directory overflow. <CRLF> DELE <SP> filename <CRLF> 450 <SP> File not found. <CRLF>The first three commands serve only to initiate the transfer of afile from one machine to another. The transfer itself occurs on aseparate IPC channel and is governed by what amounts to a separateprotocol. 2c6 Since the general command format admits but a single parameter,multiparameter operations must be implemented as sequences ofcommands. Thus two commands are required to rename a file: 2c7 Command Response RNFR <SP> oldname <CRLF> 200 <SP> Next parameter. <CRLF> RNTO <SP> newname <CRLF> 253 <SP> File renamed. <CRLF> -5-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing A Command/Response Protocol, the Basis for an Alternative ApproachA COMMAND/RESPONSE PROTOCOL, THE BASIS FOR AN ALTERNATIVE APPROACH 3The Importance of Factoring Out the Command/Response Discipline 3a That FTP, RJE, and the other protocols within this family share acommon command/response discipline is a fact not formally recognizedwithin the protocol literature, and each new protocol documentdescribes it in detail, as if for the first time. Nowhere are theseconventions codified in isolation from the various contexts in whichthey find use, being viewed as a necessary but relativelyunimportant facet of each function-oriented protocol. "This commoncommand/response discipline has thus gone unrecognized as theimportant, application-independent protocol that it is." 3a1 This oversight has had two important negative effects upon thegrowth of resource sharing within the ARPANET: 3a2 (1) It has allowed the command/response discipline to remain crude. As already noted, operations that require more than a single parameter are consistently implemented as two or more separate commands, each of which requires a response and thus incurs the overhead of a full round-trip network delay. Furthermore, there are no standards for encoding parameter types other than character strings, nor is there provision for returning results in a command response. (2) It has placed upon the applications programmer the burden of implementing the network "run-time environment (RTE)" that enables him to access remote processes at the desired, functional level. Before he can address remote processes in terms like the following: execute function DELE with argument TEXTFILE on machine X the applications programmer must first construct (as he invariably does in every program he writes) a module that provides the desired program interface while implementing the agreed upon command/response discipline. This run-time environment contains the code required to properly format outgoing commands, to interface with the IPC facility, and to parse incoming responses. Because the system provides only -6-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing A Command/Response Protocol, the Basis for an Alternative Approach the IPC facility as a foundation, the applications programmer is deterred from using remote resources by the amount of specialized knowledge and software that must first be acquired. If, on the other hand, the command/response discipline were formalized as a separate protocol, its use in subsequent function-oriented protocols could rightly be anticipated by the systems programmer, and a single run-time environment constructed for use throughout an installation (in the worst case, one implementation per programming language per machine might be required). This module could then be placed in a library and, as depicted in Figure 2, link loaded with (or otherwise made available to) each new applications program, thereby greatly simplifying its use of remote resources. Furthermore, since enhancements to it would pay dividends to every applications program employing its services, the run-time environment would gradually be augmented to provide additional new services to the programmer. The thesis of the present paper is that one of the keys tofacilitating network resource sharing lies in (1) isolating as aseparate protocol the command/response discipline common to a largeclass of applications protocols; (2) making this new,application-independent protocol flexible and efficient; and (3)constructing at each installation a RTE that employs it to give theapplications programmer easy and high-level access to remoteresources. 3a3Specifications for the Command/Response Protocol 3b Having argued the value of a command/response protocol (hereaftertermed the Protocol) as the foundation for a large class ofapplications protocols, there remains the task of suggesting theform that the Protocol might take. There are eight requirements.First, it must reproduce the capabilities of the discipline itreplaces: 3b1 (1) Permit invocation of arbitrary, named commands (or functions) implemented by the remote process. (2) Permit command outcomes to be reported in a way that aids both the program invoking the commmand and the user under whose control it may be executing. -7-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing A Command/Response Protocol, the Basis for an Alternative ApproachSecond, the Protocol should remove the known deficiencies of itspredecessor, that is: 3b2 (3) Allow an arbitrary number of parameters to be supplied as arguments to a single command. (4) Provide representations for a variety of parameter types, including but not limited to character strings. (5) Permit commands to return parameters as results as well as accept them as arguments.And, finally, the Protocol should provide whatever additionalcapabilities are required by the more complex distributed systemswhose creation the Protocol seeks to encourage. Although others maylater be identified, the three capabilities below are recognized nowto be important: 3b3 (6) Permit the server process to invoke commands in the user process, that is, eliminate entirely the often inappropriate user/server distinction, and allow each process to invoke commands in the other. In the workshop environment alluded to earlier, for example, the user process is the command language interpreter and the server process is any of the software tools available to the user. While most commands are issued by the interpreter and addressed to the tool, occasionally the tool must invoke commands in the interpreter or in another tool. A graphical text editor, for example, must invoke commands within the interpreter to update the user's display screen after an editing operation. (7) Permit a process to accept two or more commands for concurrrent execution. The text editor may wish to permit the user to initiate a long formatting operation with one command and yet continue to issue additional, shorter commands before there is a response to the first. (8) Allow the process issuing a command to suppress the response the command would otherwise elicit. This feature would permit network traffic to be reduced in those cases in which the process invoking the command deems a -8-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing A Command/Response Protocol, the Basis for an Alternative Approach response unnecessary. Commands that always succeed but never return results are obvious candidates for this kind of treatment.A Formulation of the Protocol That Meets These Specifications 3c The eight requirements listed above are met by a protocol inwhich the following two messages are defined: 3c1 message-type=COMMAND [tid] command-name arguments message-type=RESPONSE tid outcome resultsHere and in subsequent protocol descriptions, elements enclosed insquare brackets are optional. 3c2 The first message invokes the command whose NAME is specifiedusing the ARGUMENTS provided. The second is issued in eventualresponse to the first and returns the OUTCOME and RESULTS of thecompleted command. Whenever OUTCOME indicates that a command hasfailed, the command's RESULTS are required to be an error number anddiagnostic message, the former to help the invoking programdetermine what to do next, the latter for possible presentation tothe user. The protocol thus provides a framework for reportingerrors, while leaving to the applications program the tasks ofassigning error numbers and composing the text of error messages. 3c3 There are several elements of the Protocol that are absent fromthe existing command/response discipline: 3c4 (1) RESULTS, in fulfillment of Requirement 5. (2) A MESSAGE TYPE that distinguishes commands from responses, arising from Requirement 6. In the existing discipline, this distinction is implicit, since user and server processes receive only responses and commands, respectively. (3) An optional transaction identifier TID by which a command and its response are associated, arising from Requirements 7 and 8. The presence of a transaction identifier in a command implies the necessity of a response echoing the identifier; and no two concurrently outstanding commands may bear the same identifier. -9-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing A Command/Response Protocol, the Basis for an Alternative Approach Requirements 3 and 4--the ability to transmit an arbitrary numberof parameters of various types with each command or response--aremost economically and effectively met by defining a small set ofprimitive "data types" (for example, booleans, integers, characterstrings) from which concrete parameters can be modeled, and a"transmission format" in which such parameters can be encoded.Appendix A suggests a set of data types suitable for a large classof applications;Appendix B defines some possible transmissionformats. 3c5 The protocol description given above is, of course, purelysymbolic.Appendix C explores one possible encoding of the Protocolin detail. 3c6Summarizing the Arguments Advanced So Far 3d The author trusts that little of what has been presented thus farwill be considered controversial by the reader. The followingprincipal arguments have been made: 3d1 (1) The more effective forms of resource sharing depend upon remote resources being usefully accessible to other programs, not just to human users. (2) Application-dependent protocols providing such access using the current approach leave to the applications programmer the task of constructing the additional layer of software (above the IPC facility provided by the system) required to make remote resources accessible at the functional level, thus discouraging their use. (3) A single, resource-independent protocol providing flexible and efficient access at the functional level to arbitrary remote resources can be devised. (4) This protocol would make possible the construction at each installation of an application-independent, network run-time environment making remote resources accessible at the functional level and thus encouraging their use by the applications programmer. A protocol as simple as that suggested here has great potentialfor stimulating the sharing of resources within a computer network.First, it would reduce the cost of adapting existing resources fornetwork use by eliminating the need for the design, documentation,and implementation of specialized delivery protocols. Second, it -10-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing A Command/Response Protocol, the Basis for an Alternative Approachwould encourage the use of remote resources by eliminating the needfor application-specific interface software. And finally, it wouldencourage the construction of new resources built expressly forremote access, because of the ease with which they could be offeredand used within the network software marketplace. 3d2 -11-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing A High-Level Model of the Network EnvironmentA HIGH-LEVEL MODEL OF THE NETWORK ENVIRONMENT 4The Importance of the Model Imposed by the Protocol 4a The Protocol proposed above imposes upon the applicationsprogrammer a particular model of the network environment. In aheterogeneous computer network, nearly every protocol intended forgeneral implementation has this effect, since it idealizes a classof operations that have concrete but slightly different equivalentsin each system. Thus the ARPANET's TELNET Protocol alluded toearlier, for example, specifies a Network Virtual Terminal thatattempts to provide a best fit to the many real terminals in usearound the Network. 4a1 As now formulated, the Protocol models a remote resource as aninteractive program with a simple, rigidly specified commandlanguage. This model follows naturally from the fact that thefunction-oriented protocols from which the Protocol was extractedwere necessitated by the complexity and diversity of user-orientedcommand languages. The Protocol may thus legitimately be viewed asa vehicle for providing, as an adjunct to the sophisticated commandlanguages already available to users, a family of simple commandlanguages that can readily be employed by programs. 4a2 While the command/response model is a natural one, others arepossible. A remote resource might also be modeled as a process thatservices and replies to requests it receives from other computerprocesses. This request/reply model would emphasize the fact thatthe Protocol is a vehicle for inter-process communication and thatno human user is directly involved. 4a3 Substituting the request/reply model for the command/responsemodel requires only cosmetic changes to the Protocol: 4a4 message-type=REQUEST [tid] op-code arguments message-type=REPLY tid outcome resultsIn the formulation above, the terms "REQUEST", "REPLY", and"op-code" have simply been substituted for "COMMAND", "RESPONSE",and "command-name", respectively. 4a5 The choice of model need affect neither the content of theProtocol nor the behavior of the processes whose dialog it governs.Use of the word "command" in the command/response model, forexample, is not meant to imply that the remote process can becoerced into action. Whatever model is adopted, a process has -12-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing A High-Level Model of the Network Environmentcomplete freedom to reject an incoming remote request that it isincapable of or unwilling to fulfill. 4a6 But even though it has no substantive effect upon the Protocol,the selection of a model--command/response, request/reply, and soon--is an important task because it determines the way in which bothapplications and systems programmers perceive the networkenvironment. If the network environment is made to appear foreignto him, the applications programmer may be discouraged from usingit. The choice of model also constrains the kind and range ofprotocol extensions that are likely to occur to the systemsprogrammer; one model may suggest a rich set of useful extensions,another lead nowhere (or worse still, in the wrong direction). 4a7 In this final section of the paper, the author suggests a networkmodel (hereafter termed the Model) that he believes will bothencourage the use of remote resources by the applications programmerand suggest to the systems programmer a wide variety of usefulProtocol extensions. Unlike the substance of the Protocol, however,the Model has already proven quite controversial within the ARPANETcommunity. 4a8Modeling Resources As Collections of Procedures 4b Ideally, the goal of both the Protocol and its accompanying RTEis to make remote resources as easy to use as local ones. Sincelocal resources usually take the form of resident and/or librarysubroutines, the possibility of modeling remote commands as"procedures" immediately suggests itself. The Model is furtherconfirmed by the similarity that exists between local procedures andthe remote commands to which the Protocol provides access. Bothcarry out arbitrarily complex, named operations on behalf of therequesting program (the caller); are governed by arguments suppliedby the caller; and return to it results that reflect the outcome ofthe operation. The procedure call model thus acknowledges that, ina network environment, programs must sometimes call subroutines inmachines other than their own. 4b1 Like the request/reply model already described, the procedurecall model requires only cosmetic changes to the Protocol: 4b2 message-type=CALL [tid] procedure-name arguments message-type=RETURN tid outcome resultsIn this third formulation, the terms "CALL", "RETURN", and"procedure-name" have been substituted for "COMMAND, "RESPONSE", and -13-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing A High-Level Model of the Network Environment"command-name", respectively. And in this form, the Protocol mightaptly be designated a "procedure call protocol (PCP)". 4b3 "The procedure call model would elevate the task of creatingapplications protocols to that of defining procedures and theircalling sequences. It would also provide the foundation for a truedistributed programming system (DPS) that encourages and facilitatesthe work of the applications programmer by gracefully extending thelocal programming environment, via the RTE, to embrace modules onother machines." This integration of local and network programmingenvironments can even be carried as far as modifying compilers toprovide minor variants of their normal procedure-calling constructsfor addressing remote procedures (for which calls to the appropriateRTE primitives would be dropped out). 4b4 Finally, the Model is one that can be naturally extended in avariety of ways (for example, coroutine linkages and signals) tofurther enhance the distributed programming environment. 4b5Clarifying the Procedure Call Model 4c Although in many ways it accurately portrays the class of networkinteractions with which this paper deals, the Model suggested abovemay in other respects tend to mislead the applications programmer.The Model must therefore be clarified: 4c1 (1) Local procedure calls are cheap; remote procedure calls are not. Local procedure calls are often effected by means of a single machine instruction and are therefore relatively inexpensive. Remote procedure calls, on the other hand, would be effected by means of a primitive provided by the local RTE and require an exchange of messages via IPC. Because of this cost differential, the applications programmer must exercise discretion in his use of remote resources, even though the mechanics of their use will have been greatly simplified by the RTE. Like virtual memory, the procedure call model offers great convenience, and therefore power, in exchange for reasonable alertness to the possibilities of abuse. (2) Conventional programs usually have a single locus of control; distributed programs need not. -14-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing A High-Level Model of the Network Environment Conventional programs are usually implemented as a single process with exactly one locus of control. A procedure call, therefore, traditionally implies a transfer of control from caller to callee. Distributed systems, on the other hand, are implemented as two or more processes, each of which is capable of independent execution. In this new environment, a remote procedure call need not suspend the caller, which is capable of continuing execution in parallel with the called procedure. The RTE can therefore be expected to provide, for convenience, two modes of remote procedure invocation: a blocking mode that suspends the caller until the procedure returns; and a non-blocking mode that releases the caller as soon as the CALL message has been sent or queued. Most conventional operating systems already provide such a mode choice for I/O operations. For non-blocking calls, the RTE must also, of course, either arrange to asynchronously notify the program when the call is complete, or provide an additional primitive by which the applications program can periodically test for that condition. Finally, the applications programmer must recognize that by nomeans all useful forms of network communication are effectivelymodeled as procedure calls. The lower level IPC facility thatremains directly accessible to him must therefore be employed inthose applications for which the procedure call model isinappropriate and RTE-provided primitives simply will not do. 4c2 -15-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing Some ExpectationsSOME EXPECTATIONS 5 Both the Procedure Call Protocol and its associated Run-TimeEnvironment have great potential for facilitating the work of thenetwork programmer; only a small percentage of that potential hasbeen discussed in the present paper. Upon the foundation providedby PCP can be erected higher level application-independent protocollayers that further enhance the distributed programming environmentby providing even more powerful capabilities (seeAppendix D). 5a As the importance of the RTE becomes fully evident, additionaltasks will gradually be assigned to it, including perhaps those of: 5b (1) Converting parameters between the format employed internally by the applications program, and that imposed by the Protocol. 5b1 (2) Automatically selecting the most appropriate inter-process transmission format on the basis of the two machines' word sizes. 5b2 (3) Automatically substituting for network IPC a more efficient form of communication when both processes reside on the same machine. 5b3The RTE will eventually offer the programmer a wide variety ofapplication-independent, network-programming conveniences, and so,by means of the Protocol, become an increasingly powerfuldistributed-system-building tool. 5c -16-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing AcknowledgmentsACKNOWLEDGMENTS 6 Many individuals within both SRI's Augmentation Research Center(ARC) and the larger ARPANET community have contributed their timeand ideas to the development of the Protocol and Model described inthis paper. The contributions of the following individuals areexpressly acknowledged: Dick Watson, Jon Postel, Charles Irby, KenVictor, Dave Maynard, and Larry Garlick of ARC; and Bob Thomas andRick Schantz of Bolt, Beranek and Newman, Inc. 6a ARC has been working toward a high-level framework fornetwork-based distributed systems for a number of years now [14].The particular Protocol and Model described here result fromresearch begun by ARC in July of 1974. This research includeddeveloping the Model; designing and documenting the Protocolrequired to support it [15]; and designing, documenting, andimplementing a prototype run-time environment for a particularmachine [16, 17], specifically a PDP-10 running the Tenex operatingsystem developed by Bolt, Beranek and Newman, Inc [18]. Threedesign iterations were carried out during a 12-month period, and theresulting specification implemented for Tenex. The Tenex RTEprovides a superset of the capabilities presented in the body ofthis paper and Appendices A through C as well as those alluded to inAppendix D. 6b The work reported here was supported by the Advanced ResearchProjects Agency of the Department of Defense, and by the Rome AirDevelopment Center of the Air Force. 6c -17-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource SharingAppendix A: Suggested Data TypesAPPENDIX A: SUGGESTED DATA TYPES 7 The Protocol requires that every parameter or "data object" berepresented by one of several primitive data types defined by theModel. The set of data types below is sufficient to convenientlymodel a large class of data objects, but since the need foradditional data types (for example, floating-point numbers) willsurely arise, the set must remain open-ended. Throughout thedescriptions below, N is confined to the range [0, 2**15-1]: 7a LIST: A list is an ordered sequence of N data objects called "elements". A LIST may contain other LISTs as elements, and can therefore be employed to construct arbitrarily complex composite data objects. 7a1 CHARSTR: A character string is an ordered sequence of N ASCII characters, and conveniently models a variety of textual entities, from short user names to whole paragraphs of text. 7a2 BITSTR: A bit string is an ordered sequence of N bits and, therefore, provides a means for representing arbitrary binary data (for example, the contents of a word of memory). 7a3 INTEGER: An integer is a fixed-point number in the range [-2**31, 2**31-1], and conveniently models various kinds of numerical data, including time intervals, distances, and so on. 7a4 INDEX: An index is an integer in the range [1, 2**15-1]. As its name and value range suggest, an INDEX can be used to address a particular bit or character within a string, or element within a list. INDEXes have other uses as well, including the modeling of handles or identifiers for open files, created processes, and the like. Also, because of their restricted range, INDEXes are more compact in transmission than INTEGERs (seeAppendix B). 7a5 BOOLEAN: A boolean represents a single bit of information, and has either the value true or false. 7a6 EMPTY: An empty is a valueless place holder within a LIST or parameter list. 7a7 -18-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource SharingAppendix B: Suggested Transmission FormatsAPPENDIX B: SUGGESTED TRANSMISSION FORMATS 8 Parameters must be encoded in a standard transmission formatbefore they can be sent from one process to another via theProtocol. An effective strategy is to define several formats andselect the most appropriate one at run-time, adding to the Protocola mechanism for format negotiation. Format negotiation would beanother responsibility of the RTE and could thus be made completelyinvisible to the applications program. 8a Suggested below are two transmission formats. The first is a36-bit binary format for use between 36-bit machines, the second an8-bit binary, "universal" format for use between dissimilarmachines. Data objects are fully typed in each format to enable theRTE to automatically decode and internalize incoming parametersshould it be desired to provide this service to the applicationsprogram. 8bPCPB36, For Use Between 36-Bit Machines 8c Bits 0-13 Unused (zero) 8c1 Bits 14-17 Data type 8c2 EMPTY =1 INTEGER=4 LIST=7 BOOLEAN=2 BITSTR =5 INDEX =3 CHARSTR=6 Bits 18-20 Unused (zero) 8c3 Bits 21-35 Value or length N 8c4 EMPTY unused (zero) BOOLEAN 14 zero-bits + 1-bit value (TRUE=1/FALSE=0) INDEX unsigned value INTEGER unused (zero) BITSTR unsigned bit count N CHARSTR unsigned character count N LIST unsigned element count N Bits 36- Value 8c5 EMPTY unused (nonexistent) BOOLEAN unused (nonexistent) INDEX unused (nonexistent) INTEGER two's complement full-word value BITSTR bit string + zero padding to word boundary CHARSTR ASCII string + zero padding to word boundary LIST element data objects -19-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource SharingAppendix B: Suggested Transmission FormatsPCPB8, For Use Between Dissimilar Machines 8d Byte 0 Data type 8d1 EMPTY =1 INTEGER=4 LIST=7 BOOLEAN=2 BITSTR =5 INDEX =3 CHARSTR=6 Bytes 1- Value 8d2 EMPTY unused (nonexistent) BOOLEAN 7 zero-bits + 1-bit value (TRUE=1/FALSE=0) INDEX 2-byte unsigned value INTEGER 4-byte two's complement value BITSTR 2-byte unsigned bit count N + bit string + zero padding to byte boundary CHARSTR 2-byte unsigned character count N + ASCII string LIST 2-byte element count N + element data objects -20-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource SharingAppendix C: A Detailed Encoding of the Procedure Call ProtocolAPPENDIX C: A DETAILED ENCODING OF THE PROCEDURE CALL PROTOCOL 9 Although the data types and transmission formats detailed in theprevious appendixes serve primarily as vehicles for representing thearguments and results of remote procedures, they can just as readilyand effectively be employed to represent the commands and responsesby which those parameters are transmitted. 9a Taking this approach, one might model each of the two Protocolmessages as a PCP data object, specifically a LIST whose firstelement is an INDEX message type. The following concise statementof the Protocol then results: 9b LIST (CALL, tid, procedure, arguments) INDEX=1 INDEX/EMPTY CHARSTR LIST 9b1 LIST (RETURN, tid, outcome, results) INDEX=2 INDEX BOOLEAN LIST 9b2The RESULTS of an unsuccessful procedure would be represented asfollows: 9c LIST (error, diagnostic) INDEX CHARSTR 9c1 -21-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource SharingAppendix D: A Look at Some Possible Extensions to the ModelAPPENDIX D: A LOOK AT SOME POSSIBLE EXTENSIONS TO THE MODEL 10 The result of the distributed-system-building strategy proposedin the body of this paper and the preceeding appendices is depictedin Figure D-1. At the core of each process is the inter-processcommunication facility provided by the operating system, whicheffects the transmission of arbitrary binary data between distantprocesses. Surrounding this core are conventions regarding firstthe format in which a few, primitive types of data objects areencoded in binary for IPC, and then the formats of several compositedata objects (that is, messages) whose transmission either invokesor acknowledges the previous invocation of a remote procedure.Immediately above lies an open-ended protocol layer in which anarbitrary number of enhancements to the distributed programmingenvironment can be implemented. Encapsulating these variousprotocol layers is the installation-provided run-time environment,which delivers DPS services to the applications program according tomachine- and possibly programming-language-dependent conventions. 10a The Protocol proposed in the present paper recognizes only themost fundamental aspects of remote procedure calling. It permitsthe caller to identify the procedure to be called, supply thenecessary arguments, determine the outcome of the procedure, andrecover its results. In a second paper [19], the author proposessome extensions to this simple procedure call model, and attempts toidentify other common forms of inter-process interaction whosestandardization would enhance the distributed programmingenvironment. Included among the topics discussed are: 10b (1) Coroutine linkages and other forms of communication between the caller and callee. 10b1 (2) Propagation of notices and requests up the thread of control that results from nested procedure calls. 10b2 (3) Standard mechanisms for remotely reading or writing system-global data objects within another program. 10b3 (4) Access controls for collections of related procedures. 10b4 (5) A standard means for creating and initializing processes, that is, for establishing contact with and logging into a remote machine, identifying the program to be executed, and so forth. This facility would permit arbitrarily complex process hierarchies to be created. 10b5 -22-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource SharingAppendix D: A Look at Some Possible Extensions to the Model (6) A mechanism for introducing processes to one another, that is, for superimposing more general communication paths upon the process hierarchy. 10b6These and other extensions can all find a place in the open-endedprotocol layer of Figure D-1. The particular extensions explored in[19] are offered not as dogma but rather as a means of suggestingthe possibilities and stimulating further research. 10c -23-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing ReferencesREFERENCES 11 1. Kahn, R. E., "Resource-Sharing Computer Communications Networks," Proceedings of the IEEE, Vol. 60, No. 11, pp. 1397-1407, November 1972. 11a 2. Crocker, S. D., Heafner, J. F., Metcalfe, R. M., Postel, J. B., "Function-oriented Protocols for the ARPA Computer Network," AFIPS Proceedings, Spring Joint Computer Conference, Vol. 40, pp. 271-279, 1972. 11b 3. Carr, C. S., Crocker, S. D., Cerf, V. G., "Host-Host Communication Protocol in the ARPA Network," AFIPS Proceedings, Spring Joint Computer Conference, Vol. 36, pp. 589-597, 1970. 11c 4. Mc Kenzie, A. A., Host/Host Protocol for the ARPA Network, Bolt Beranek and Newman Inc., Cambridge, Massachusetts, January 1972 (SRI-ARC Catalog Item 8246). 11d 5. Walden, D. C., "A System for Interprocess Communication in a Resource Sharing Computer Network," Communications of the ACM, Vol. 15, No. 4, pp. 221-230, April 1972. 11e 6. Cerf, V. G., Kahn, R. E., "A Protocol for Packet Network Intercommunication," IEEE Transactions on Communications, Vol. Com-22, No. 5, pp. 637-648, May 1974. 11f 7. Thomas, R. H., "A Resource-Sharing Executive for the ARPANET," AFIPS Proceedings, National Computer Conference, Vol. 42, pp. 155-163, 1973. 11g 8. TELNET Protocol Specification, Stanford Research Institute, Menlo Park, California, August 1973 (SRI-ARC Catalog Item 18639). 11h 9. Engelbart, D. C., Watson, R. W., Norton, J. C., "The Augmented Knowledge Workshop," AFIPS Proceedings, National Computer Conference, Vol. 42, pp. 9-21, 1973. 11i10. Engelbart, D. C., English, W. K., "A Research Center for Augmenting Human Intellect," AFIPS Proceedings, Fall Joint Computer Conference, Vol. 33, pp. 395-410, 1968. 11j11. Irby, C. H., Dornbush, C. F., Victor, K. E., Wallace, D. C., "A Command Meta Language for NLS," Final Report, Contract -24-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing References RADC-TR-75-304, SRI Project 1868, Stanford Research Institute, Menlo Park, California, December, 1975. 11k12. Neigus, N. J., File Transfer Protocol, ARPA Network Working Group Request for Comments 542, Bolt Beranek and Newman Inc., Cambridge, Massachusetts, July 1973 (SRI-ARC Catalog Item 17759). 11l13. Bressler, R. D., Guida, R., Mc Kenzie, A. A., Remote Job Entry Protocol, ARPA Network Working Group Request for Comments 360, Dynamic Modeling Group, Massachusetts Institute of Technology, Cambridge, Massachusetts, (undated) (SRI-ARC Catalog Item 12112). 11m14. Watson, R. W., Some Thoughts on System Design to Facilitate Resource Sharing, ARPA Network Working Group Request for Comments 592, Augmentation Research Center, Stanford Research Institute, Menlo Park, California, November 20, 1973 (SRI-ARC Catalog Item 20391). 11n15. White, J. E., DPS-10 Version 2.5 Implementer's Guide, Augmentation Research Center, Stanford Research Institute, Menlo Park, California, August 15, 1975 (SRI-ARC Catalog Item 26282). 11o16. White, J. E., DPS-10 Version 2.5 Programmer's Guide, Augmentation Research Center, Stanford Research Institute, Menlo Park, California, August 13, 1975 (SRI-ARC Catalog Item 26271). 11p17. White, J. E., DPS-10 Version 2.5 Source Code, Augmentation Research Center, Stanford Research Institute, Menlo Park, California, August 13, 1975 (SRI-ARC Catalog Item 26267). 11q18. Bobrow, D. G., Burchfiel, J. D., Murphy, D. L., Tomlinson, R. S., "TENEX, a Paged Time Sharing System for the PDP-10," Communications of the ACM, Vol. 15, No. 3, pp. 135-143, March 1972. 11r19. White, J. E., "Elements of a Distributed Programming System," Submitted for publication in the Journal of Computer Languages, 1976. 11s -25-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263NCC 76 A High-Level Framework for Network-Based Resource Sharing Figure ListFIGURE LIST 12Figure 1. Interfacing a remote terminal to a local time-sharing system via the TELNET Protocol. 12aFigure 2. Interfacing distant applications programs via their run-time environments. 12bFigure D-1. Software and protocol layers comprising a process within the distributed programming system. 12c -26-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263 -27-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263 A High-Level Framework for Network-Based Resource Sharing 23-DEC-75 James E. White Augmentation Research Center Stanford Research Institute Menlo Park, California 94025 (415) 326-6200 x2960 This paper proposes a high-level, application-independent protocol and software framework that would extend the local programming environment to embrace modules in other computers within a resource sharing computer network, and thereby facilitate the construction of distributed systems and encourage the sharing of resources. The work reported here was supported by the Advanced Research Projects Agency of the Department of Defense, and by the Rome Air Development Center of the Air Force. This paper has been submitted for publication in the Proceedings of the 1976 National Computer Conference.
[8]ページ先頭