Remote Procedure Calls Adapted from: Paul Krzyzanowski - - PowerPoint PPT Presentation

▶
remote procedure calls
SMART_READER_LITE
LIVE PREVIEW

Remote Procedure Calls Adapted from: Paul Krzyzanowski - - PowerPoint PPT Presentation

Mar 22, 2023 219 likes •663 views

Remote Procedure Calls Adapted from: Paul Krzyzanowski pxk@cs.rutgers.edu ds@pk.org Except as otherwise noted, the content of this presentation is licensed under the Creative Commons Attribution 2.5 License. Page 1 Network Transfer Protocols

slide-1
SLIDE 1

Page 1

Remote Procedure Calls

Adapted from: Paul Krzyzanowski pxk@cs.rutgers.edu ds@pk.org

Except as otherwise noted, the content of this presentation is licensed under the Creative Commons Attribution 2.5 License.

slide-2
SLIDE 2

Page 2

Network Transfer Protocols

Connection Oriented

  • often reliable, stream based
  • analogous to making a direct phone call
  • TCP (Transmission Control Protocol) is a connection-based

protocol that provides a reliable flow of data between two computers

Connectionless

  • unreliable, datagram based
  • analogous to sending letters via the postal service
  • UDP (User Datagram Protocol) is a protocol that sends

independent packets of data, called datagrams, from one computer to another with no guarantees about arrival. UDP is not connection-based like TCP.

slide-3
SLIDE 3

Page 3

Internet Protocol and the TCP/IP Protocol Suite

  • IP (Internet Protocol) provides an unreliable,

connectionless datagram delivery service.

  • TCP/IP is a set of protocols created specifically to allow

development of network and internetwork communications

  • n a global scale.
  • TCP/IP is the most commonly used protocols within the

internet.

  • TCP/IP is normally considered to be a four-layer system

Client

Host A

TCP IP Driver

Server

Host B

TCP IP Driver

Network

slide-4
SLIDE 4

Page 4

Sockets

  • Sockets ( Berkley sockets) are one of the most widely used communication APIs.
  • A socket is an object from which messages and are sent and received.
  • A socket is a network communication endpoint.
  • In connection-based communication such as TCP, a server application binds a socket to a specific

port number. This has the effect of registering the server with the system to receive all data destined for that port. A client can then rendezvous with the server at the server's port, as illustrated here:

  • Data transfer operations on sockets work just like read and write operations on files. A socket is

closed, just like a file, when communications is finished.

  • Network communications are conducted through a pair of cooperating sockets, each known as

the peer of the other.

  • Processes connected by sockets can be on different computers (known as a heterogenous

environment) that may use different data representations.

  • Data is serialized into a sequence of bytes by the local sender and deserialized into a local data

format at the receiving end.

slide-5
SLIDE 5

Page 5

Problems with sockets

Sockets interface is straightforward

– [connect] – read/write – [disconnect]

BUT … it forces read/write mechanism

– We usually use a procedure call

To make distributed computing look more like centralized:

– I/O is not the way to go

slide-6
SLIDE 6

Page 6

RPC

1984: Birrell & Nelson

– Mechanism to call procedures on other machines

Remote te P Pro roce cedu dure re C Call ll Goal: it should appear to the programmer

that a normal call is taking place

slide-7
SLIDE 7

Page 7

Regular procedure calls

Machine instructions for call & return but the compiler really makes the procedure call abstraction work:

– Parameter passing – Local variables – Return data

slide-8
SLIDE 8

Page 8

Regular procedure calls

You write:

x = f(a, “test”, 5); The compiler parses this and generates code to:

  • a. Push the value 5 on the stack
  • b. Push the address of the string “test” on the stack
  • c. Push the current value of a on the stack
  • d. Generate a call to the function f

In compiling f, the compiler generates code to:

  • a. Push registers that will be clobbered on the stack to save the values
  • b. Adjust the stack to make room for local and temporary variables
  • c. Before a return, unadjust the stack, put the return data in a register,

and issue a return instruction

slide-9
SLIDE 9

Page 9

Implementing RPC

No architectural support for remote procedure calls Simulate it with tools we have (local procedure calls)

Simulation makes RPC a language-level construct instead of an

  • perating system construct
slide-10
SLIDE 10

Page 10

Implementing RPC

The trick:

Create stub functions to make it appear to the user that the call is local Stub function contains the function’s interface

slide-11
SLIDE 11

Page 11

Remote Procedue Calls

  • Enable procedure calls across host boundaries
  • Call interfaces are defined using an Interface

Definition Language (IDL)

  • RPC compiler generates presentation and

session layer implementation from IDL

slide-12
SLIDE 12

Page 12

ISO/OSI Presentation Layer

Resolution of data heterogeneity Common data representation Transmission of data declaration Marshalling and Unmarshalling

slide-13
SLIDE 13

Page 13

Marshalling and Unmarshalling

  • Marshalling: Disassemble

(encode) data structures into transmittable form

  • Unmarshalling: Reassemble

(decode) transmitted form into

  • riginal complex data structure.
slide-14
SLIDE 14

Page 14

Method Call vs. Object Request

Called Stub Stub Caller Called Caller Caller Transport Layer (e.g. TCP or UDP)

slide-15
SLIDE 15

Page 15

Stubs

  • Creating code for marshalling and

unmarshalling is tedious and error-prone.

  • Code can be generated fully automatically

from interface definition.

  • Code is embedded in stubs for client and

server.

  • Client stub represents server for client,

Server stub represents client for server.

  • Stubs achieve type safety.
  • Stubs also perform synchronization.
slide-16
SLIDE 16

Page 16

client server

Stub functions

network routines server functions

server stub (skeleton)

network routines

  • 1. Client calls stub (params on stack)

client functions

client stub

slide-17
SLIDE 17

Page 17

client server

Stub functions

server functions

server stub (skeleton)

network routines

  • 2. Stub marshals params to net message

client functions

client stub

network routines

slide-18
SLIDE 18

Page 18

client server

Stub functions

  • 3. Network message sent to server

client functions

client stub

network routines server functions

server stub (skeleton)

network routines

slide-19
SLIDE 19

Page 19

client server

Stub functions

  • 4. Receive message: send to stub

client functions

client stub

network routines server functions

server stub (skeleton)

network routines

slide-20
SLIDE 20

Page 20

client server

Stub functions

  • 5. Unmarshal parameters, call server func

client functions

client stub

network routines server functions

server stub (skeleton)

network routines

slide-21
SLIDE 21

Page 21

client server

Stub functions

  • 6. Return from server function

client functions

client stub

network routines server functions

server stub (skeleton)

network routines

slide-22
SLIDE 22

Page 22

client server

Stub functions

  • 7. Marshal return value and send message

client functions

client stub

network routines server functions

server stub (skeleton)

network routines

slide-23
SLIDE 23

Page 23

client server

Stub functions

  • 8. Transfer message over network

client functions

client stub

network routines server functions

server stub (skeleton)

network routines

slide-24
SLIDE 24

Page 24

client server

Stub functions

  • 9. Receive message: direct to stub

client functions

client stub

network routines server functions

server stub (skeleton)

network routines

slide-25
SLIDE 25

Page 25

client server

Stub functions

  • 10. Unmarshal return, return to client code

client functions

client stub

network routines server functions

server stub (skeleton)

network routines

slide-26
SLIDE 26

Page 26

Benefits

  • Procedure call interface
  • Writing applications is simplified

– RPC hides all network code into stub functions – Application programmers don’t have to worry about details

  • Sockets, port numbers, byte ordering
  • RPC: presentation layer in OSI model
slide-27
SLIDE 27

Page 27 Page 27

RPC has issues

slide-28
SLIDE 28

Page 28

Parameter passing

Pass by value

– Easy: just copy data to network message

Pass by reference

– Makes no sense without shared memory

slide-29
SLIDE 29

Page 29

Pass by reference?

1. Copy items referenced to message buffer

  • 2. Ship them over
  • 3. Unmarshal data at server
  • 4. Pass local pointer to server stub function
  • 5. Send new values back

To support complex structures – Copy structure into pointerless representation – Transmit – Reconstruct structure with local pointers on server

slide-30
SLIDE 30

Page 30

Representing data

No such thing as in incompatibil ibilit ity p probl blems on local system Remote machine may have:

– Different byte ordering – Different sizes of integers and other types – Different floating point representations – Different character sets – Alignment requirements

slide-31
SLIDE 31

Page 31

Where to bind?

Need to locate host and correct server process 1. Maintain centralized DB that can locate a host that provides a particular service (Birrell & Nelson’s 1984 proposal)

  • 2. A server on each host maintains a DB of

locally provided services

slide-32
SLIDE 32

Page 32

Transport protocol

Which one?

  • Some implementations may offer only one

(e.g. TCP)

  • Most support several

– Allow programmer (or end user) to choose

slide-33
SLIDE 33

Page 33

When things go wrong

  • Local procedure calls do not fail

– If they core dump, entire process dies

  • More opportunities for error with RPC:
  • Transparency breaks here

– Applications should be prepared to deal with RPC failure

slide-34
SLIDE 34

Page 34

When things go wrong

  • Semantics of remote procedure calls

– Local procedure call: exact ctly ly o

  • nce

ce

  • A remote procedure call may be called:

– 0 times: server crashed or server process died before executing server code – 1 time: everything worked well – 1 or more: excess latency or lost reply from server and client retransmission

slide-35
SLIDE 35

Page 35

RPC semantics

  • Most RPC systems will offer either:

– at t least on t once semantics – or at m t mos

  • st on

t once semantics

  • Understand application:

– idempotent functions: may be run any number of times without harm – non-idempotent functions: side-effects

slide-36
SLIDE 36

Page 36

More issues

Performance

– RPC is slower … a lot slower

Security

– messages visible over network – Authenticate client – Authenticate server

slide-37
SLIDE 37

Page 37

Programming with RPC

Language support

– Most programming languages (C, C++, Java, …) have no concept of remote procedure calls – Language compilers will not generate client and server stubs Common solution: – Use a separate compiler to generate stubs (pre- compiler)

slide-38
SLIDE 38

Page 38

Interface Definition Language

  • Allow programmer to specify remote

procedure interfaces

(names, parameters, return values)

  • Pre-compiler can use this to generate client

and server stubs:

– Marshaling code – Unmarshaling code – Network transport routines – Conform to defined interface

  • Similar to function prototypes
slide-39
SLIDE 39

Page 39

RPC compiler

IDL

RPC compiler

client code (main) server functions client stub headers server skeleton data conv. data conv.

compiler compiler server client

Code you write Code RPC compiler generates

slide-40
SLIDE 40

Page 40

Writing the program

Client code has to be modified

– Initialize RPC-related options

  • Transport type
  • Locate server/service

– Handle failure of remote procedure call

Server functions

– Generally need little or no modification

slide-41
SLIDE 41

Page 41

RPC API

What kind of services does an RPC system need?

  • Name service operations

– Export/lookup binding information (ports, machines) – Support dynamic ports

  • Binding operations

– Establish client/server communications using appropriate protocol (establish endpoints)

  • Endpoint operations

– Listen for requests, export endpoint to name server

slide-42
SLIDE 42

Page 42

RPC API

What kind of services does an RPC system need?

  • Security operations

– Authenticate client/server

  • Internationalization operations
  • Marshaling/data conversion operations
  • Stub memory management

– Dealing with “reference” data, temporary buffers

  • Program ID operations

– Allow applications to access IDs of RPC interfaces