Filetype PDF | Posted on 05 Feb 2023 | 2 years ago
Authentication
digital resources
186x Filetype PDF File size 1.84 MB Source: cds.cern.ch
CERN DD/OC TBL.RPC5
RPC proiecfi How it will work 9 April 1986
DRAFT SPBCIFICATIOI{S AND
IMPLEMBI{TATION NOTES FOR
THE RPC PROJECT
[. How a distributed system will be built
2. The sequence of stages in a remote call
3. Calling sequences for the Run-time support
4. Principal development areas
5. Project State
DRAFT
VERSION 6
s Tim Berners-læe DD/OC
First version 27 Feb 86
This is a working document, and is frequently updated. Recent changes are marked by a vertical line in
the right-hand you
margin. If harte comments, please say so, or pass back a marked up cop!.
ln Version 4:
Changes reflecting input from Kris Kostro about the Hermes system, offers of available time to pass on
his understanding of it, and adapt it to our needs. This means that commonality v/ith Flermes should
be extended from the run-time support system to the compiler as well.
The isolation of transaction-oriented protocol as a specifi.c area of work, to be looked at by Yves
Grandjean. (section 4.2)
ln version 5:
A decision, if possible, to use yacc for any compiler development, in the hope of making a corlmon,
supportable, RPC project. (section 4.1)
In version 6:
Minor updates only.
*
t
Contents i RPC project: How it will work
CONÏENTS
I. STAGES IN SIMPLE RPC 1
1.1 Program Generation I
1.1.1 Prograrnmer writes modular program I
1.1.2 Programmer describes an lnterface Unit . I
1.1.3 The RPC Compiler 2
1.2 l,oad time: Addressing and linking 2
1.2.L Requirement 2
1.2.2 RPC-OPEN 3
1.2.3 Linking the stub to the Run-Time Support 3
1.3 Version checking. 3
, RLIN TIME: THE REMOTE CALL 5
2.1 Program Calls Stub 5
2.2 Buffer Formatting 5
2.3 Stub Calls Run-Time Support 5
2.4 RTS calls Communication Service 5
2.5 Server RTS system calls communication service. 6
2.6 Server RTS system calls Server Stub 6
2.7 Server stub calls User routine 6
2.8 The Return of OUT Parameters 6
2.9 Abort and Reject: Intemrpt generalisations. ,I
2.10 Closing a service 7
3. RLIN-TIME SUPPORT CALLING SEQI.]ENCES I
3.1 RPC OPEN I
3.2 RPC_CLOSE.... I
3.3 RPC-CALL I
3.4 RPC ATTACH STUB 9
3.5 RPC_DETACH-STUB 9
3.6 A Server Stub . 9
3.7 RPC RETURN.. 9
3.8 RPC-REJECT.. l0
4. PRINCIPAL DEVELOPMENT AREAS tl
4.1 Compiler Design l1
4.1.1 The procedure definition language (MESAiRPCL) 11
4.I.2 Method of Writing the compiler 1l
4.2 Transaction-oriented protocol 12
4.3 .VAX/VMS Raw Ethernet support 13
5. PROJECTSTEPS t4
References .14
ç
s
project:
RPC How it will work page I
I. STAGES IN SIMPLE RPC
This Chapter describes some details of the sequence of operations occuring when a distibuted system
using SRPC is built, and when it runs.
Mention is made of any standards which are be used to make the system more open.
A general understanding of RPC principles is assumed.
1.1 Program Generation
This section enumerates the stages involved in building a distributed program.
I.I.I Programmer writes modular program
Firstly, the program has to be written in a modular fashion. The modules have to be designed so that
in the final version, they can run on di.fferent machines.
Various rules must be follwed:
1. Control is not passed between modules except as a procedure call
2. No data is to be passed between modules except explicitly as parameters to routines.
3. The data types of parameters are limited.
Whereas the hermes project [2] is designed to interface to C programs, in DD/OC we (and our users)
require remote Pascal and FORTRAN programs. Parameter types used will include integers, charac-
ters, and variable or fixed length arrays of either. All will be passed (in gensral) by reference, as opposed
to by value.
1.1.2 Programmer describes an Interface Unit
Note: This step is done only irzformally when an RPC compiler is not used as at plesent (Apr 86)
If a prograrn has been designed in a modular way, the interfaces between the modules shoudl be well
defined early in the process. To use RPC, the interfaces between modules on diffemt machines must be
described to the RPC compiler. This is done by writing a short, consise, definition of each procedrue
involved.
For each procedure, one specifi.es its name, and for each of its parameters
o Its data type, indicating both the size and interpretation of the storage;
. Its dircction: whether it is transferred to or from the procedure, or both.
o Optionally, certain attributes which allow the compiler to optimise the code it generates.
s
è
page 2 RPC project: How it will work
ln order to reduce the organisational overhead, a related set of procedures are grouped together as a
'unit'. (The terms 'interface', omoduleo, 'prograat" (Courier), and "service" (hermes) have been used,
but are rather overused - we use the term unit in a specific way). A "unit" is all described in the same
file, and compiled into one stub module. A unit is an important concept in the addressing of remote
procedures.
1.1.3 The RPC Compiler
Note: This step is done by hand when an RPC compiler is not used as at present (Apr B6)
The RPC compiler ntru and generates the stub code for each end. In fact, tÀe RPC compiler takes the
definition file and cteates the source code for two pascal modules, on for the client and one for the ser-
ver end. These two modules are then compiled by a pascal compiler, to produce the object code for the
stubs.
1.2 Load "ne: Addressing alrfl linking
1.2.1 Requirement
It is necessary for some action to announce the client's indended use of a service. This allows
o the required service to be found.
o the server to be created (ifnecessary).
r a communicaton path to be estabilished between the client and server
There are two ways of doing this, and we must cater for both.
In the first case, the programmer has written his program in two parts (as above), and must be able to
link it (without changing or recompiling it) so that it will execute either on one machine, or on morÊ
than one. In this case, the setting up of the RPC communication, resolving of the addressing, etc, must
be done transparerrtly by the system utility which loads the program onto the various machines. (Tftis
is arnbitious -Rrtl Yes, but it is an optionwe do notwant to exclude.)
(Under VAXIVMS this can be done, by including an "INITIALVE" procedure in the stub module.
This is automatically called by the image loader before the main program is run, and is be responsible
for establishing the links).
In the second case, the user program is written with an av/areness of the RPC system, as it wants, as
tttn time, to be able to select, open and close remote servers. In this case, the'set-up facilites must be
provided for the use of the user.
There are many interesting problems in this area.
É
no reviews yet
Please Login to review.
