-
structuring rpc systems - procedural decomposition
- generating
rpc infrastructure - stubs and skeletons
- the rpc model
- specification, design, implementation
- implementation -
by hand, from libraries, custom generation
- rpc support -
data, control, generation
- data - xdr, other
presentation-level tools; usually libraries
- control - how the
os implements rpc; system calls and libraries
- communication -
how the rpc works; kernel code
- generation - goo between the
application and the system
- rpc system design is natural -
perhaps too much
- often externally constrained - service
locations
- hiding latency is a good design problem - prefetch;
call fragmentation
- what's being designed - client, server, or
both
- implementing rpc
- stubs are the
endpoints in the rpc chain - the client and server are on the other
side of the stubs
- stubs marshal data and work the rpc protocol
- the server side also demultiplexes rpc calls, if necessary
- naming - preserving the procedure name across machines
- generating rpc code
- rpc code has variable
variablility - the further from the ends, the less it varies
-
variability is directly related to the ends - the procedures
-
variability is usually trivial - order, number, type
- this can
be handled automatically
- rpcgen - part of onc rpc
- reads a description of the remote procedure and generates code
- types and constants, marshalling procedure, client-side
communications stub, server-side communications stub
- the
problem of infinte regress - how does the client call the remote
procedure? how does the client call the rpc stub? . . .
-
and for the server too
- the client (and server) provides
an interface routine to the rpc code
This page
last modified on 26 February 2002.