Transcript pptx

REMOTE PROCEDURE CALLS
EE324
일과 행복
2

억지로 잘하려고 하기 보다 좋아하려고 노력하기

억지로 좋아하려고 하기 보다 열정을 가지기

억지로 열정을 가지려하기 보다 주어진 일에 몰입하기

억지로 몰입하려고 하기보다 즐거움으로 최선을 다 하기
Building up to today

Abstractions for communication
 Internetworking
protocol: IP
 TCP masks some of the pain of communicating across unreliable IP

Abstractions for computation and I/O
 Process:
A resource container for execution on a single machine
 Thread: pthread and synchronization primitives (sem, mutex, cv)
 File (later)
Now back to Distributed Systems: remember?
4
A distributed system is:
“A collection of independent computers that appears to its users as a sin
gle coherent system”

"A distributed system is one in which the failure of a computer you didn't
even know existed can render your own computer unusable." – Leslie La
mport
Distributed Systems
5

The middleware layer extends over multiple machine
s, and offers each application the same interface.
What does it do?
6
Hide complexity to programmers/users
Hide the fact that its processes and resources are
physically distributed across multiple machines.
Transparency in a Distributed System
How?
7

The middleware layer extends over multiple machine
s, and offers each application the same interface.
Starter for Today

Splitting computation across the network
What programming abstractions work well to split
work among multiple networked computers?
Many ways


Request-reply protocols
Remote procedure calls (RPC) or Remote method invocation (RMI)
Recommended reading :
Distributed Systems: Concepts and Design 5th edition, by Coulouris, et al.
(CDK5) chapter 5
Request-reply protocols
Client
Hey, do something
working {
Done/Result
Server
Request-reply protocols

E.g., your PA1 (binary protocol)
struct foomsg {
u_int32_t len;
}
send_foo(char *contents) {
int msglen = sizeof(struct foomsg) + strlen(contents);
char buf = malloc(msglen);
struct foomsg *fm = (struct foomsg *)buf;
fm->len = htonl(strlen(contents));
memcpy(buf + sizeof(struct foomsg),
contents,
strlen(contents));
write(outsock, buf, msglen);
}
Then wait for response, handle timeout, etc.
Request-reply protocols: text protocol

HTTP
 See
the HTTP/1.1 standard:
 http://www.w3.org/Protocols/rfc2616/rfc2616.html
 Done with your PA2 yet?
Remote Procedure Call (RPC)


A type of client/server communication
Attempts to make remote procedure calls look like local ones
{ ...
foo()
}
void foo() {
invoke_remote_foo()
}
figure from Microsoft MSDN
RPC Goals




Ease of programming
Hide complexity
Automate a lot of task of implementing
Familiar model for programmers (just make a function call)
Historical note: Seems obvious in retrospect, but RPC was only invented in
the ‘80s. See Birrell & Nelson, “Implementing Remote Procedure Call” ... or
Bruce Nelson, Ph.D. Thesis, Carnegie Mellon University: Remote
Procedure Call., 1981 :)
Remote procedure call
15

A remote procedure call makes a call to a remote service look like a l
ocal call
 RPC
makes transparent whether server is local or remote
 RPC allows applications to become distributed transparently
 RPC makes architecture of remote machine transparent
RPC
16

The interaction between client and
server in a traditional RPC.
Passing Value Parameters (1)
17

The steps involved in a doing a
remote computation through RPC.
But it’s not always simple



Calling and called procedures run on different machines, with different
address spaces
 And perhaps different environments .. or operating systems ..
Must convert to local representation of data
Machines and network can fail
Marshaling and Unmarshaling





(From example) hotnl() -- “host to network-byte-order, long”.
 network-byte-order (big-endian) standardized to deal with crossplatform variance
Note how we arbitrarily decided to send the string by sending its length
followed by L bytes of the string? That’s marshalling, too.
Floating point...
Nested structures? (Design question for the RPC system - do you support
them?)
Complex data structures? (Some RPC systems let you send lists and maps
as first-order objects)
“stubs” and IDLs



RPC stubs do the work of marshaling and unmarshaling data
But how do they know how to do it?
Typically: Write a description of the function signature using an IDL -interface definition language.
 Lots of these. Some look like C, some look like XML, ... details don’t
matter much.
SunRPC


Venerable, widely-used RPC system
Defines “XDR” (“eXternal Data Representation”) -- C-like language
for describing functions -- and provides a compiler that creates stubs
struct fooargs {
string msg<255>;
int baz;
}
And describes functions
program FOOPROG {
version VERSION {
void FOO(fooargs) = 1;
void BAR(barargs) = 2;
} = 1;
} = 9999;
More requirements

Provide reliable transmission (or indicate failure)
 May

have a “runtime” that handles this
Authentication, encryption, etc.
 Nice
when you can add encryption to your system by changing a few lines
in your IDL file
 (it’s
never really that simple, of course -- identity/key management)
XML-RPC request/response example
<?xml version="1.0"?>
<methodCall>
<methodName>examples.getStateName</methodName>
<params>
<param> <value><i4>40</i4></value> </param>
</params>
</methodCall>
<?xml version="1.0"?>
<methodResponse>
<params>
<param> <value><string>South Dakota</string></value>
</param>
</params>
</methodResponse>
RPC vs. LPC
26
 Memory
access
 Partial failures
 Latency
But it’s not always simple

Properties of distributed computing that make achieving
transparency difficult:
Calling and called procedures run on different machines, with different
address spaces
 Machines and network can fail
 Latency is much longer for RPC because it involves in network transmission
and marshalling/unmarshalling

Passing Reference Parameters
28


Replace with pass by copy/restore
Need to know size of data to copy
 Difficult

in some programming languages
Solves the problem only partially
 What
about data structures containing pointers?
 Access to memory in general?
Partial failures
29

In local computing:
 if

machine fails, application fails
In distributed computing:
 if
a machine fails, part of application fails
 one cannot tell the difference between a machine failure and network failure

How to make partial failures transparent to client?
RPC failures




Request from cli -> srv lost
Reply from srv -> cli lost
Server crashes after receiving request
Client crashes after sending request
Strawman solution
31

Make remote behavior identical to local behavior:

Every partial failure results in complete failure



You abort and reboot the whole system
You wait patiently until system is repaired
Problems with this solution:
Many catastrophic failures
 Clients block for long periods


System might not be able to recover
Real solution: break transparency
32

Possible semantics for RPC:

Exactly-once


At least once:


Zero, don’t know, or once
Zero or once


Only for idempotent operations
At most once


Impossible in practice
Transactional semantics
At-most-once most practical

But different from LPC
RPC semantics: Exactly-Once?



Sorry - no can do in general.
Imagine that message triggers an external physical thing (say, a
robot fires a missile)
The robot could crash immediately before or after firing and lose its
state. Don’t know which one happened. Can, however, make this
window very small.
RPC semantics

At-least-once semantics
 Keep

retrying...
At-most-once
 Use
a sequence # to ensure idempotency against network retransmissions
 and remember it at the server
Implementing at-most-once


At-least-once: Just keep retrying on client side until you get a response.
 Server just processes requests as normal, doesn’t remember anything.
Simple!
At-most-once: Server might get same request twice...
 Must re-send previous reply and not process request (implies: keep
cache of handled requests/responses)
 Must be able to identify requests
 Strawman: remember all RPC IDs handled. -> Ugh! Requires infinite
memory.
 Real: Keep sliding window of valid RPC IDs, have client number them
sequentially.
Summary: expose remoteness to client
36


Expose RPC properties to client, since you cannot hide them
Application writers have to decide how to deal with partial fail
ures
 Consider:
E-commerce application vs. game
RPC implementation issues
37
RPC implementation
38

Stub compiler
 Generates
stubs for client and server
 Language dependent
 Compile into machine-independent format
 E.g.,
XDR
 Format
describes types and values
RPC protocol
 RPC transport

Writing a Client and a Server (1)
39

The steps in writing a
client and a server in
DCE RPC.
Writing a Client and a Server (2)
40




Three files output by the IDL compiler:
A header file (e.g., interface.h, in C terms).
The client stub.
The server stub.
RPC protocol
41
Guarantee at-most-once semantics by tagging requests and res
ponse with a nonce
 RPC request header:

 Request
nonce
 Service Identifier
 Call identifier

Protocol:
 Client
resends after time out
 Server maintains table of nonces and replies
RPC transport
42

Use reliable transport layer
 Flow
control
 Congestion control
 Reliable message transfer
Performance



As a general library, performance is often a big concern for RPC
systems
Major source of overhead: copies and marshaling/unmarshaling
overhead
Zero-copy tricks:
 Representation: Send on the wire in native format and indicate that
format with a bit/byte beforehand. What does this do? Think
about sending uint32 between two little-endian machines
 Scatter-gather writes (writev() and friends)
Complex / Pointer Data Structures


Very few low-level RPC systems support
 C is messy about things like that -- can’t always understand the
structure and know where to stop chasing
 Hard to go with C like language
Java RMI (and many other higher-level languages) allows sending
objects as part of an RPC
 But be careful - don’t want to send megabytes of data across
network to ask simple question!
 Java support object serialization (remember python?)
Important Lessons
45



Procedure calls
 Simple way to pass control and data
 Elegant transparent way to distribute application
 Not only way…
Hard to provide true transparency
 Failures
 Performance
 Memory access
 Etc.
How to deal with hard problem  give up and let programmer deal with it
 “Worse is better”