Client/Server-Model:
Download
1 / 30

Client/Server-Model: Remote Procedure Call - PowerPoint PPT Presentation


  • 124 Views
  • Uploaded on

Client/Server-Model: Remote Procedure Call. 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Client/Server-Model: Remote Procedure Call' - ruth-riley


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Client/Server-Model:

Remote Procedure Call


Remote procedure call
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


Remote procedure call1
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


System architecture
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


Communication basic concepts
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


Interface description idl interface definition language
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


Interface description idl
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


Stub generating
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


Variable parameter sizes
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


Binding process
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);


Export via server
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);

  • // ....

  • }


Import call via client
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

  • }


Explicit binding via client
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


Explicit binding via client1
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, ...);

  • }


Binding details
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


Run time support communication
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)


Transport protocols in dce
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);


Run time support processes
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


Process control in dce
Process control in DCE

  • Setup of a process pool during server initialization

  • #define maxConcCalls 3

  • rpc_server_listen ( maxConcCalls, & status);

  • // max. number concurrent calls


Processes on client site
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


Processes on client site1
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

  • }


Processes on client site2
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

  • }

  • }


Use of threads general view
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


Error processing in rpc
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


Error processing in rpc1
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


Error semantics
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


Error semantics in dce rpc
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


Problems of rpc
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


Problems of rpc1
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


Problems of rpc2
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


ad