a. Are LPC similar to RPC? b. How is a socket identified? Solution Remote Proced

Question

a. Are LPC similar to RPC?
b. How is a socket identified?

Explanation / Answer

Remote Procedure Call (RPC) =========================== Remote procedure is a procedure that resides in a different address space The goal of RPC model is to allow calling of remote procedures as if it were the local ones. The most important characteristics of RPC are: - client-server model (the server may also be a client of a different server) - not object oriented; procedures are encapsulated in "programs", program may exist in more "versions" simultaneously. The client specifies the procedure it wants to execute by program number, it's version number and procedure number - calls to remote programs are transparent. Client program just calls function in the server program (that way it appears to the programmer). - the RPC model si similar to the local one; caller of the remote procedure is blocked until the procedure finishes and returns result (or fails) - RPC does not define any semantics of remote procedures - the transport-independent protocol is defined to invoke remote procedure and obtain results; to unify representation of passed values, the eXternal Data Representation (XDR) is used Comparison of RPC and LPC ------------------------- - Error handling is more complex Failures of the remote server and the transport mechanism (including temporary network failures) must be handled. So, in contrast to LPC, every remote call may potentially fail due to communication problem. - Global variables and side-effects Since the server does not have access to the client's address space, hidden arguments cannot be passed as global variables or returned as side effects (which is a bad practice anyway) - Performance issues - The problem of call semantics when a operation request must be retransmitted - Need of caller authentication (because of the transport over insecure network) Stubs and Skeletons ------------------- To make a distributed system programming as simple as possible, the programmer need not to make difference of local and remote procedure call, at least from the syntactic point of view. It is possible due to stubs procedures, which are ordinary local procedures the programmer calls to invoke a remote procedure. Stubs have the same signatures as their remote counterparts; the only action the stub procedure takes is to transform the actual procedure parameters to the XDR representation and then send an appropriate operation request to the server via the RPC protocol. Then, when the server replies with a operation result, the result is transformed from the XDR representation to the local host's native format and passed back to the caller. All complexities concerning request retransmission when the reply does not arrive in a time limit are also solved here. On the server side, there must be a code which awaits requests from the client, extracts parameters and calls an appropriate server procedure, obtains result and passes it back to the client. That code is called a skeleton. Commonly, one skeleton exists for a version of program (see later), but conceptually, every procedure may have it's own skeleton. RPC Packages ------------ Stubs and skeletons are commonly generated automatically from the procedure signatures (in Sun RPC implementation, rpcgen program serves for this). So the programmer only has to code server procedures and client code and does not need to know anything about communication among client and server, which is assured by RPC libraries provided together with rpcgen. (The only thing the programmer specifies when running rpcgen is a transport protocol(s) for which the stub and skeleton procedures have to be generated). Two versions of RPC package are widely used: 1. Socket RPC - based on UDP/TCP transport and socket interface 2. TI-RPC (Transport Independent) - transport uses TLI API calls (Transport Layer Interface Application Program Interface) In fact, there exist a lot of RPC implementation. We will focus to that from Sun, which is freely available, including sources. Note: The Sun RPC protocol makes no restrictions on the concurrency model implemented; an implementation may choose to have RPC calls be asynchronous. Anyway, common implementation block the caller until the return value arrives from the server. Since some RPC programs may be of general usefulness while others are site specific, Sun defined a set of intervals of program numbers. Some are used for general-purpose program numbers and are administrated by Sun, while other set of program numbers is meant to be assigned by users as needed. 00000000 - 1fffffff defined by Sun 20000000 - 3fffffff defined by user 40000000 - 5fffffff transient (for applications generating program numbers dynamically) 60000000 - 7fffffff reserved 80000000 - 9fffffff reserved a0000000 - bfffffff reserved c0000000 - dfffffff reserved e0000000 - ffffffff reserved rpcgen ====== rpcgen is a program used to generate stubs from a remote procedure specification written in RPC language (compare to IDL compiler). Let us assume that the input RPC-language file is named proto.x. rpcgen may generate up to four output files: - proto.h: a header file - proto_svc.c: server-side stubs - proto_clnt.c: client-side stubs - proto_xdr.c: helper XDR routines - "examples" for both client and server implementation (optional) The generated code contains empty procedure definitions suitable to fill in the procedure implementation and the client code. When implementing remote procedures, note that return values are returned to the server stub as pointers to values; variables which carry these values must be static to maintain the value available to the server stub even after the execution of the remote procedure is done. When running rpcgen, we can specify the protocol the stubs use to communicate. in the case of Sun RPC, it can be TCP, UDP or both. The outline of the code generated by rpcgen -------------------------------------------- Client code: ------------ At the beginning: CLIENT cl=clnt_create(server_addr,PROG_ID,PROG_VERSION,protocol); - contacts the server (it's portmapper) and tries to find a port for a given program ID, version and protocol ... then we can call all procedures of the remote program Client stub procedures have the following signatures: return_type* procname_version(arg_type *argp, CLIENT *clnt); If the procedure takes no arguments, argp=NULL. If the value returned is NULL, some error occured. Server code (server stub, it's main() ): ---------------------------------------- - creates a (TCP,UDP or both) socket to receive requests - calls svc_register(port,protocol,program_#,version_#) to register a program at a (local) portmapper - calls a main request listening loop, which calls a generated multiplexing routine on receiving of each request. The multiplexing routine first extracts the arguments from the request and then calls the appropriate procedure based on a remote procedure # involved in the request. After a procedure returns, it communicates the procedure's return value back to the client. Transport mechanism ------------------- Since RPC was primarily constructed to distribute a computation over a set of diverse computers connected by a network, a standard defining the format of messages (i.e. operation invocation request and response) had to be defined (see RFC 1057). Note that that definition is not bound to a specific transport protocol, such as TCP (only some issues of using a connection-oriented and connectionless protocols are mentioned there). The format of RPC protocol messages are thus independent of the underlying transport protocol. Also note that the RPC protocol does not try to make the transport protocol reliable if it is not; it is the responsibility of the application (more precisely, it's stub and skeleton procedures) to solve problems of request retransmissions, timeouts etc. It implies that the stub layer of the application must be aware of the underlying transport protocol. The stub and skeleton procedures may also support more than one transport protocol. How is the call really handled -------------------------------- - When client wants to call remote procedure, it actually calls CLIENT STUB PROCEDURE generated by RPC package - The RPC package internal library codes arguments and passes the call request to the server in the form of the message - SERVER STUB receives the message, takes arguments from it and calls the appropriate server procedure. When the procedure is done, control is returned to the server stub, which takes return value, encapsulates it to the message and sends it back to the CLIENT STUB. - Client stub then receives the reply message, extracts reply value and passes it to the client application. => all communication details are hidden inside RPC, namely in stub and skeleton code. The advantage is that the programmer need not to cope with the issues of communication in unreliable communication environment. => by standardizing of message format and binary representation of values of the supported data types, RPC solves problem of different data representation at various machines of the heterogenous environment Call semantics -------------- In contrast to LPC, where nothing can prevent the procedure to be called, the call may fail in many points in RPC scenerio. It may be caused by server crash or communication problems. To take a corrective action (possibly try to invoke an operation once more), the client needs to know whether the failure occured BEFORE, DURING or AFTER the remote procedure was executed. The key point is not to leave the system in an inconsistent state after a failure. The common solution to retry the failed operation is to retransmit the request if a response do not arrive in a reasonable time. The problem is that the application cannot infer whether the remote procedure was executed or not. So if it retransmits the request multiple times (say, until a reply arrives), it cannot tell how many times the remote procedure was actually executed. Note: IDEMPOTENT OPERATION - can be performed many times instead of once; the system state does not depend on how many times the operation was performed Examples: idempotent op.: square root calculation unidempotent op.: bank account operations Common call semantics are: * Exactly Once Semantics - similar to local procedure call (LPC), the called procedure is executed exactly once, when called - most convenient to programmer, difficult to implement * At Most Once Semantics - the remote procedure is executed once or not at all - If the caller receives procedure results, it knows the procedure was executed exactly once. If it does not receive results, it does not know whether the procedure was executed or not (whether the call request was lost and the operation was not initiated or the operation was performed but the reply carrying result was lost) * At Least Once Semantics - the remote procedure was executed, but possibly multiple times. The execution may be repeated if a caller don't receive a reply, so it times-out and retransmits the request. We can afford this semantics only for idempotent operations. Most RPC and object request broker implementations try to reach exactly once semantics, which is most like the semantics of a traditional local procedure call. Common solution to reach exactly-one-semantics ---------------------------------------------- Requests are marked by client with a unique IDs to make them distinguishable. The server maintains a cache of processed requests and results associated to them. These results was obtained by calling the appropriate procedure when the request arrived first time. If the server receives a request, it scans the cache first to determine whether the request was already processed (i.e. the request received now is the retransmitted one, most probably because the server's reply was lost). If the request is known to be a retransmission, the server does not call the server procedure, but replies with a result previously stored in the cache. Note: The execution of the procedure should not take more time than a client retransmission timeout. Parameter and result passing ---------------------------- To ensure data value exchange between hosts of different architectures, there must be a standard how to represent values of a supported data types. Note: explicit vs. implicit typing Examples: ASN.1 - explicit, XDR - implicit Parameters can only be passed by value (due to separated address space) (Note: compare to INOUT parameter mode in CORBA) Note: Sun RPC allows for only one procedure parameter; if more parameters are needed, they must be packed together into a structure External Data Representation (XDR) ---------------------------------- - standard for description and encoding of data (RFC 1832) - used with RPC to code parameters, function results and other values in RPC message - uses a language similar to subset of C to describe data formats - types represented by multiplies of 4 bytes, numbered from 0 to n, byte N is written to stream before byte N+1, stream padded to multiple of 4 bytes by 0s - roughly analogous to ISO Abstract Syntaxt Notation (X.409) (XDR falls into ISO-OSI presentation layer) XDR Data types: --------------- Integer - 32b, signed & unsigned, 2's complement Enumeration - represented as signed ints enum { name-identifier = constant, ... } identifier; booleans (bool) defined as: enum { FALSE = 0, TRUE = 1 } identifier; Hyper Integer and Unsigned Hyper Integer - 64b float - 32b, IEEE-754 Single Precision Numbers double - 64b, IEEE-754 Double Precision Numbers quadruple floating point number - 128b fixed-length opaque data - uninterpreted data opaque identifier[n]; Variable-length Opaque Data - encoded as sequence length followed by sequence bytes opaque identifier; /* m is an upper bound of element count */[B or opaque identifier; /* upper bound not specified */ (If the upper bound of the length is not specified, it is assumed to be 2^32 - 1) String - a sequence of ASCII chars: len encoded as unsigned, then bytes of the string follow string object; or string object; Fixed-length Array - homogenous type-name identifier[n]; (Each element takes a multiply of 4 bytes, elements may have different lengths (e.g. array of strings)). Variable-length Array - homogenous, encoded as element count (unsigned int) followed by encoded elements. type-name identifier; /* m is an upper bound of an element count */ or type-name identifier; Structure struct { component-declaration-A; component-declaration-B; ... } identifier; Elements are encoded in the order as they appear in the declaration. Discriminated Union - type of the discriminant is int, unsigned int or enumerated (including bool) union switch (discriminant-declaration) { case discriminant-value-A: arm-declaration-A; case discriminant-value-B: arm-declaration-B; ... default: default-declaration; } identifier; - default case if optional and is used when the discriminant has a value not specified by any 'case'. - Encoded as: discriminant | implied_arm void - used only to describe operation parameters and results, has no actual representation Additional constructs: const - have not a representation, only to define a symbolic constant typedef - behaves as "macro" (to define type "aliases") The RPC Protocol ================ The RPC protocol is specified to be independent of the transport protocol. The formal specification of a RPC protocol (Sun RPC v.2) can be found in RFC 1057. Generally, the RPC protocol must provide: - Unique specification of a procedure to be called - Method to match response messages with request messages. - Specification of binary formats to exchange values of supported data types (XDR is used for this purpose) - Method to authenticate the caller to service and vice-versa (i.e. to guarantee that only some user entity (i.e. user, process, host,...) may call a remote procedure and ensure that the request may not be faked by someone else. The formal specification of a RPC protocol (Sun RPC v.2) can be found RFC 1057. RPC protocol procedure call message format ------------------------------------------ (also defined by XDR language in RFC 1057) The formal specification of a RPC protocol (Sun RPC v.2) can be found RFC 1057, RPC-call: --------- ////////////////////////////////////////////////////////////////////////// transaction ID (XID) - set by client and returned by the server to match replies with requests. The ID changes every call, but remains the same when the command must be retransmitted (to make exactly-once call sematics call/reply indicator - 0=CALL (1=REPLY) RPC version (2) program # version # procedure # - server procedure identification credentials - client identification (possibly UID, GID) - server may get credentials to assess whether the client has enough rights to perform the requester operation verifier - for Secure RPC, which uses DES encryption procedure parameters - in XDR format ///////////////////////////////////////////////////////////////////////////// Note: The total message length is given by packet size in case of datagram protocol (e.g.UDP); if used over connection-oriented protocol (such as TCP), the message length is inserted to the stream before XID field. Note: Lengths of variable-length fields (credentials, verifier) are encoded in these fields. RPC reply: ---------- ////////////////////////////////////////////////////////////////////////////// XID - copied from XID of the call call/reply indicator 1=REPLY (0=CALL) status (0=accepted) - rejected if RPC versions do not match or the server couldn't authenticate the client verifier - for Secure RPC to identify the server accept status - valid only if a message was accepted (status=0). Value of 0 indicates success, other values are error codes (unknown program, version or procedure number or the server cannot decode parameters) - see RFC1057 procedure result (XDR format) ///////////////////////////////////////////////////////////////////////////// THE RPC LANGUAGE ---------------- The RPC Language is an extension to the XDR language, with the addition of "program", "procedure", and "version" declarations. Example: program PING_PROG { /* * Latest and greatest version */ version PING_VERS_PINGBACK { void PINGPROC_NULL(void) = 0; /* * Ping the client, return the round-trip time * (in microseconds). Returns -1 if the operation * timed out. */ int PINGPROC_PINGBACK(void) = 1; } = 2; /* * Original version */ version PING_VERS_ORIG { void PINGPROC_NULL(void) = 0; } = 1; } = 1; const PING_VERS = 2; /* latest version */ By convention, procedure 0 of any RPC protocol should have no parameters and return nothing, and never require any kind of authentication. It is used by client to assure that a program whith a given version really exists. (It can be also used for round-trip measurement). If the null procedure is not explicitly stated, most rpcgen implementation will generate it automatically. program-def: "program" identifier "{" version-def version-def * "}" "=" constant ";" version-def:M "version" identifier "{" procedure-def procedure-def * "}" "=" constant ";" procedure-def: type-specifier identifier "(" type-specifier ("," type-specifier )* ")" "=" constant ";" Binding (name service) ====================== The problem to solve is to find the address of a server which is capable to perform some procedure and obtain a identifier for that procedure. In practice, the identifier commonly represents a communication endpoint to reach the address space of a target server (or directly the appropriate skeleton, if there is more than one skeleton for a process). Possible solutions: - centralized database (registry) providing registration and search services (very vulnerable to failure in the pure version) - ... Portmapper ---------- In Sun RPC, the problem of registering services and finding them is solved on registry base. The registry - called a portmapper - resides at each host which provides remote procedures. The name "portmapper" comes from the fact that each service registers itself at some (TCP or UDP) port and then starts to receive requests at a specified port. Since most of programs using remote procedures are site specific, it is not possible to reserve a well-defined port for each of them. Instead, server programs use ephemeral ports. The portmapper keeps track of registered services as a set of

Related Questions

Navigate

• Browse (All)
• Browse A
• Subjects

---

---

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.