II.1

Client/Server-Model:Remote Procedure Call

II.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

II.3

Remote Procedure Call

• Process– caller in waiting state– parameter- and call transfer to target system– procedure execution– confirmation– continuation of program execution

1. Call relocate 2. Call encoding3. Waiting

9. Decoding10. Results receipt11. Program Continuation

5. Decoding6. Execution7. Encoding

Caller (Client) Called Server

II.4

System architecture

Call

Packet

Import Export...

Client-computer Server-computerNetwork

send

receive

wait

call encoding

decoding

call

result

execute

decoding

encoding

receive

send

localcall

localresult

Result

Packet

Client Client-Stub

Runtime-system

Runtime-system

Server-Stub

Server

Sample system: DCE (Distributed Computing Environment)

II.5Communication: basic concepts

Directory Service

Client (for instance Point of Sale)

Server (for instance account server)

Binding process

Object-interaction

Account access

Interface description

Account access

Info-File

Status

10010111...

ExportImport12

3 4 5Status

Info-File

Basic communication

II.6Interface 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 definitionsconst long maxDoc=10; // maximum number of documentstypedef [string] char *String; // data type for character-strings

typedef struct {String documentName; // document nameString documentDescription; // textual descriptionlong size; // storage volume

} DocumentDescription; // document description

typedef struct {DocumentDescription desc; // document descriptionString header; // document headerchar *data; // document data

} Document; // document

II.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

II.8

Stub-Generating

document.idl

IDL-Compiler

document_cstub.o document_sstub.odocument.h

document_client.c document_server.c

document_client.o document_server.o

document_client.exe document_server.exe

#include

C compile

link link

II.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

II.10

Binding process

Directory-Server

Control table

Client

Import DocumentServer

Server Address S

Bind (S, DocumentServer)

RPC:fetchDocument(desc,document)

Server

Export DocumentServer• documentQuery• insertDocument• removeDocument• fetchDocument

Acknowledge (BindingNumber)

return(document);

Alternatives:- direct addressing- broadcast-request- Directory Services

II.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);

// ....

}

II.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

}

II.13

Explicit Binding via Client

rpc_ns_binding_import_begin

rpc_ns_binding_import_next

rpc_ns_binding_import_done

Client

Context

Binding Handle

Directory Service

/.:/DocumentServer

Name record:

II.14

Explicit Binding via Client

#define entry /.:/DocumentServer // name for Directorymain() {

unsigned status; // status of each callrpc_ns_handle_t context; // directory contextrpc_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, ...);

}

II.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

II.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)

II.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);

II.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

II.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

II.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

II.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

}

II.22

Processes on client-site

main() {Document *d[maxpar]; // allocated documentsDocumentDescription dd[maxpar]; // document descriptionspthread_t thread [maxpar];int i;inputDocumentDescription (dd); // input of document descriptionsfor (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 resultspthread_join (thread[i], &d[i]); // result receiptprintDocument (d[i]); // printing of obtained documents

}}

II.23

• Client-site:

• Server-site:

Example:

Simultaneous calls on several servers

Processing of several calls

Server 1 Server 3Server 2

Client 1 Client 2 Client 3 Client 4

Calls areprocessedparallel

1 call iswaiting

1 thread is idle

(Thread)

Use of threads: general view

II.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

II.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

II.26

Error semantics

Error classes

Error typeError-free execution

Messages losses

Additional server failure

Additional client failure

Execution: 1

Result: 1Maybe

At-Least-Once

Exactly-Once

Only-Once-Type-2

At-Most-Once

Only-Once-Type-1

Execution: 1

Result: 1

Execution: 1

Result: 1

Execution: 1

Result: 1

Execution: 0/1

Result: 0/1

Execution: >=1

Result: >=1

Execution: 1

Result: 1

Execution: 1

Result: 1

Execution: 0/1

Result: 0/1

Execution: >=0

Result: >=0

Execution: 0/1

Result: 0/1

Execution: 1

Result: 1

Execution: 0/1

Result: 0/1

Execution: >=0

Result: 0

Execution: 0/1

Result: 0

Execution: 1

Result: 1

=

II.27

Error semantics in DCE RPC

Attributes

default: at-most-once max. one execution with return value and if necessary explicit error report

idempotent possible repeated execution with return value and if necessary explicit error report

maybe possible repeated execution without return value and without error report

broadcast possible repeated execution at all relevant servers with return value of the first completed call

Semantics

II.28Problems 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

?

II.29

Problems of RPC

• Exchange of Client- / Server- roles– no equal communication partners– no interim result acknowledgments– no „callbacks“

• Multicast / Broadcast aren’t supported

C

S1

S2

S3

II.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

C S

global

ptr

?

?