1 ClientServerModel Remote Procedure Call 2 Remote Procedure

1 Client/Server-Model: Remote Procedure Call

2 Remote Procedure Call • Extension of procedure call to remote call • Goal: syntactic and semantic uniformity – call mechanism – language elements – error semantics • Definition (by Nelson) – – – synchronous transfer of control thread level of programming language separate address spaces coupling via relatively narrow channels data exchange: call parameters and results

3 Remote Procedure Call • Process – – – caller in waiting state parameter- and call transfer to target system procedure execution confirmation continuation of program execution Caller (Client) 1. 2. 3. Call relocate Call encoding Waiting 9. Decoding 10. Results receipt 11. Program Continuation Called Server 5. Decoding 6. Execution 7. Encoding

4 System architecture Sample system: DCE (Distributed Computing Environment) Network Client-computer Client local call Client- Runtime. Stub system call send encoding wait local result Call Server-computer Runtime -system receive Server. Stub decoding Packet Server call execute Result decoding receive Import Packet . . . send encoding Export result

Communication: basic concepts Directory Service Import 2 Binding process Client (for instance Point of Sale) Server (for instance account server) Objectinteraction Account access Interface description Account access Info-File 3 1 Export Info-File Status 4 10010111. . . Basic communication Status 5 5

Interface description: IDL (Interface Definition Language) [ uuid(765 c 3 b 10 -100 a-135 d-1568 -040034 e 67831), version(1. 0), ] interface Document. Server // interface for document-server { import “globaldef. idl”; // import of general definitions const long max. Doc=10; // maximum number of documents typedef [string] char *String; // data type for character-strings typedef struct { String document. Name; String document. Description; long size; } Document. Description; // document name // textual description // storage volume // document description typedef struct { Document. Description desc; String header; char *data; } Document; // document description // document header // document data // document 6

7 Interface description: IDL [idempotent] long document. Query ( [in] String document. Name[max. Doc], [out] Document. Description *dd[max. Doc], [out] long *status); // document request // document names // descriptions // status value of operation long insert. Document ( [in] Document *d, [out] long *status); // document inserting // new document // status value of operation long remove. Document ( [in] String name, [out] long *status); // document removing // document name // status value of operation long fetch. Document ( [in] Document. Description *dd, [out] Document *d); // document fetching // document description // requested document

8 Stub-Generating document. idl IDL-Compiler document_cstub. o document. h document_sstub. o #include document_client. c document_server. c C compile document_client. o document_server. o link document_client. exe document_server. exe

9 Variable parameter sizes typedef struct { Document. Description desc; // document description String header; // document header char *data; // document data long num. Subdoc; // number of partial documents [size_is(num. Subdoc)] Complex. Document *sub. Document[*]; // variable array of partial documents } Complex. Document; // complex-structured document

10 Alternatives: - direct addressing - broadcast-request - Directory Services Binding process Client Import Document. Server Address S Bind (S, Document. Server) RPC: fetch. Document(desc, document) Directory-Server Control table Server Export Document. Server • document. Query • insert. Document • remove. Document • fetch. Document Acknowledge (Binding. Number) return(document);

11 Export via Server #include Document. Server. h // created by IDL-Compiler #define entry. Name /. : /Document. Server // name of DS record main() { unsigned status; // call status rpc_binding_vector_t *b. Vec; // binding vector //. . . local initialization // *** determines the vector of binding identifiers: *** rpc_server_inq_bindings(&b. Vec, &status) //. . further initialization operations // ** exports the interface to the Directory Service : *** rpc_ns_binding_export(rpc_c_ns_syntax_default, entry. Name, Document. Server_v 1_0_s_ifspec, b. Vec, NULL, &status); //. . }

12 Import/call via Client setenv RPC_DEFAULT_ENTRY /. : /Document. Server #include Document. Server. h // contains “fetch. Document“ among others main() { Document d; Document. Description dd; int status; // created document // document description // status value input. Document. Description(&dd); status = fetch. Document(&dd, &d); if (status == OK) print. Document(&d); } // input of document description // RPC; introduces automatic Binding // printing of obtained document

13 Explicit Binding via Client Directory Service rpc_ns_binding_import_begin Context rpc_ns_binding_import_next Binding Handle rpc_ns_binding_import_done Name record: /. : /Document. Server

14 Explicit Binding via Client #define entry /. : /Document. Server // name for Directory main() { unsigned status; // status of each call rpc_ns_handle_t context; // directory context rpc_binding_handle_t binding; // searched Binding Handle // *** set Directory context for Binding process: *** rpc_ns_binding_import_begin (rpc_c_ns_syntax_default, entry. Name, Document. Server_v 1_2_c_ifspec, NULL, &context, &status); // *** searches for exporting server: *** rpc_ns_bindung_import_next ( context, &binding, &status); // *** (repeated call if necessary) *** // *** terminates interaction with Directory Service : *** rpc_ns_binding_import_done ( &context, &status); // ** procedure call with explicit binding : *** status = Document. Query(binding, . . . ); }

15 Binding: Details • Caching of Binding Information – information on the client-site is global for all processes – recognition of out-dated information (for instance Timeout) – limited binding information on the server-site (scalability, recovery/warm restart) • Time point of Binding – – compile time link time dynamic mixed techniques Flexibility vs. Efforts • logical names • first localization for binding during initialization time • re-localization due to errors

16 Run-time support: Communication • Standard transport protocols – TCP/IP or UDP/IP – error processing, sequence ordering, duplicate recognition • Special transport protocols – – – no connection setup (only implicit) response time active/passive connection state limited storage of sequence numbers only implicit connection release (Timeout) no assignment of own processes to the connections (only connection per machine less connections)

17 Transport protocols in DCE • TCP / IP • UDP / IP • Vendor specific Example: rpc_server_use_protseq( ncacn_ip_tcp , rpc_c_protseq_max_reqs_default, &status); rpc_server_use_all_protseq (rpc_c_protseq_max_reqs_default, &status);

18 Run-time support: Processes • Process control – assignment of processes to procedure execution, deadlock handling – „lightweight“ processes (Threads) : • common address space • fast creation and process switching • large number of processes possible use in RPC-Server - implementations use in Client, too asynchronous – Process assignment • process creation per call or • process - Pool – buffer transfer via references via further protocol layers efficiency

19 Process control in DCE Setup of a process pool during server initialization #define max. Conc. Calls 3 rpc_server_listen ( max. Conc. Calls, & status); // max. number concurrent calls

20 Processes on client-site • Process creation: – explicit via pthread_create – transfer of start routine and parameters – process fields are possible • RPC: – embedded in separate threads – return value via pthread_exit • Synchronization: – blocking via pthread_join – separately for all threads

21 Processes on client-site setenv RPC_DEFAULT_ENTRY /. : /Document. Server #include Document. Server. h #define maxpar 3 // contains among others „fetch. Document“ // maximum number of parallel calls void doc. Thread (pthread_addr_t arg) { // implementation of a thread int status; // status value Document *d = malloc(sizeof(Document)); // allocated document Document. Description *dd = (Document. Description*) arg; // transferred document descriptions status = fetch. Document(dd, d); // RPC; uses automatic Binding if (status != OK) exit (-1); // error case pthread_exit((pthread_addr_t) d); // document return as result }

22 Processes on client-site main() { Document *d[maxpar]; // allocated documents Document. Description dd[maxpar]; // document descriptions pthread_t thread [maxpar]; int i; input. Document. Description (dd); // input of document descriptions for (i=0; i<maxpar; i++) pthread_create (&thread[i], pthread_attr_default, doc. Tread, (pthread_addr_t) &dd[i]); // creation of processing threads for (i=0; i<maxpar; i++) { // wait on all results pthread_join (thread[i], &d[i]); // result receipt print. Document (d[i]); // printing of obtained documents } }

23 Use of threads: general view • Client-site: • Server-site: Simultaneous calls on several servers Processing of several calls Example: Server 1 Server 2 Calls are processed parallel Server 3 1 call is waiting 1 thread is idle (Thread) Client 1 Client 2 Client 3 Client 4

24 Error processing in RPC • Error cases: 1. Errors during procedure processing 2. Transfer errors • Error reasons: – failure of a participating computer • server-site endless wait of client Timeout • client-site further processing via server as „Orphan“ – inaccessibility of the target node dynamic binding – controlled procedure - export information dynamic binding

25 Error processing in RPC • error semantics (Spector) : – Maybe • single execution without notification in the case of errors only for “non-important” operations – At - least - once • at least once execution • only for idempotent operations – At - most - once • duplicates recognition and removing • execution only if there is no computer failure – Exactly - once • exactly once execution • masks computer failure too transaction concepts with warm restart and recovery of components

26 Error semantics Error classes Maybe At-Least-Once At-Most-Once Only-Once-Type-1 Exactly-Once Only-Once-Type-2 Error-free execution Messages losses Execution: 1 Execution: 0/1 Result: 1 Additional server failure 0/1 Additional client failure 0/1 Result: 0/1 Execution: >=1 Execution: >=0 Result: >=1 Result: >=0 Result: 1 0 Execution: 1 Execution: 0/1 Result: 1 1 = Error type 0/1 0 Execution: 1 Result: 1 1

27 Error semantics in DCE RPC Attributes Semantics default: at-most-once max. one execution with return value and if necessary explicit error report idempotent maybe broadcast possible repeated execution with return value and if necessary explicit error report possible repeated execution without return value and without error report possible repeated execution at all relevant servers with return value of the first completed call

28 Problems of RPC • Transfer of large data volumes – synchronous mechanisms small transfer unit – no connection-oriented transfer – no flow control and buffering – response time – instead of throughput optimization ? C S 1 -C S 2 -C S 3 • Chaining of processing units – rigorous Client- / Server semantics – no preliminary data forwarding – no direct control transfer via more than 2 partners

29 Problems of RPC • Exchange of Client- / Server- roles – no equal communication partners – no interim result acknowledgments – no „callbacks“ • Multicast / Broadcast aren’t supported S 1 C S 2 S 3

30 Problems of RPC • Transparency violations – variable parameters and type numbers (for instance printf ( %s%d , x 1, x 2); ) – pointer parameters (for instance char *x, . . . ) – global variables – error semantics global C ptr ? ? S