Client/Server-Model: Remote Procedure Call

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) Called Server • Call relocate • Call encoding • Waiting • 9. Decoding • 10. Results receipt • 11. Program Continuation • 5. Decoding • 6. Execution • 7. Encoding

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

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

6. Interface description: IDL (Interface Definition Language) [ uuid(765c3b10-100a-135d-1568-040034e67831), version(1.0), ] interface DocumentServer // interface for document-server { import “globaldef.idl”; // import of general definitions const long maxDoc=10; // maximum number of documents typedef [string] char *String; // data type for character-strings typedef struct { String documentName; // document name String documentDescription; // textual description long size; // storage volume } DocumentDescription; // document description typedef struct { DocumentDescription desc; // document description String header; // document header char *data; // document data } Document; // document

7. Interface description: IDL [idempotent] long documentQuery ( // document request [in] String documentName[maxDoc], // document names [out] DocumentDescription *dd[maxDoc], // descriptions [out] long *status); // status value of operation long insertDocument ( // document inserting [in] Document *d, // new document [out] long *status); // status value of operation long removeDocument ( // document removing [in] String name, // document name [out] long *status); // status value of operation long fetchDocument ( // document fetching [in] DocumentDescription *dd, // document description [out] Document *d); // 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 link document_client.exe document_server.exe

9. Variable parameter sizes • typedef struct { • DocumentDescription desc; // document description • String header; // document header • char *data; // document data • long numSubdoc; // number of partial documents • [size_is(numSubdoc)] ComplexDocument *subDocument[*]; • // variable array of partial documents • } ComplexDocument; // complex-structured document

10. Binding process • Alternatives: • direct addressing • broadcast-request • Directory Services Directory-Server Control table Client Server Import DocumentServer • Export DocumentServer • documentQuery • insertDocument • removeDocument • fetchDocument Server Address S Bind (S, DocumentServer) Acknowledge (BindingNumber) RPC: fetchDocument(desc,document) return(document);

11. Export via Server • #include DocumentServer.h // created by IDL-Compiler • #define entryName /.:/DocumentServer // name of DS record • main() • { unsigned status; // call status • rpc_binding_vector_t *bVec; // binding vector • // ... local initialization • // *** determines the vector of binding identifiers: *** • rpc_server_inq_bindings(&bVec, &status) • // .. further initialization operations • // ** exports the interface to the Directory Service : *** • rpc_ns_binding_export(rpc_c_ns_syntax_default, entryName, DocumentServer_v1_0_s_ifspec, bVec, NULL, &status); • // .... • }

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

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

14. Explicit Binding via Client • #define entry /.:/DocumentServer // 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, entryName, • DocumentServer_v1_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 = DocumentQuery(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 • logical names • first localization for binding during initialization time • re-localization due to errors Flexibility vs. Efforts

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 maxConcCalls 3 • rpc_server_listen ( maxConcCalls, & 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 /.:/DocumentServer • #include DocumentServer.h // contains among others „fetchDocument“ • #define maxpar 3 // maximum number of parallel calls • void docThread (pthread_addr_t arg) { // implementation of a thread • int status; // status value • Document *d = malloc(sizeof(Document)); // allocated document • DocumentDescription *dd = (DocumentDescription*) arg; • // transferred document descriptions • status = fetchDocument(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 • DocumentDescription dd[maxpar]; // document descriptions • pthread_t thread [maxpar]; • int i; • inputDocumentDescription (dd); // input of document descriptions • for (i=0; i<maxpar; i++) • pthread_create (&thread[i], pthread_attr_default, docTread, • (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 • printDocument (d[i]); // printing of obtained documents • } • }

23. Use of threads: general view • Client-site: • Server-site: • Example: Simultaneous calls on several servers Processing of several calls Server 1 Server 2 Server 3 1 thread is idle Calls are processed parallel 1 call is waiting (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 type Messages losses Additional server failure Additional client failure Error-free execution Error classes Execution: 1 Result: 1 Execution: 0/1 Result: 0/1 Execution: 0/1 Result: 0/1 Execution: 0/1 Result: 0/1 Maybe Execution: >=0 Result: 0 Execution: 1 Result: 1 Execution: >=1 Result: >=1 Execution: >=0 Result: >=0 At-Least-Once At-Most-Once Only-Once-Type-1 Execution: 1 Result: 1 Execution: 1 Result: 1 Execution: 0/1 Result: 0/1 Execution: 0/1 Result: 0 = Exactly-Once Only-Once-Type-2 Execution: 1 Result: 1 Execution: 1 Result: 1 Execution: 1 Result: 1 Execution: 1 Result: 1

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

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 • Chaining of processing units • rigorous Client- / Server semantics • no preliminary data forwarding • no direct control transfer via more than 2 partners ? C S1-C S2-C S3

29. Problems of RPC • Exchange of Client- / Server- roles • no equal communication partners • no interim result acknowledgments • no „callbacks“ • Multicast / Broadcast aren’t supported S1 C S2 S3

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