Lecture 008 - RPC

Abstraction

Client-Server model: request, reply

server always on, and powerful
client is personal computer
workstation (client) request service from server

Pear-to-pear: not-client server model

Remote Procedure Calls (RPC)

RPC: abstract away the network

handles message format, sending, receiving, timeout
make remote procedure calls as close to local function call as possible

RPC Package in Golang: (assume you have Golang on both side)

Provides access to the exported methods of an object across a network or other I/O connection.
A server registers an object, making it visible as a service with the name of the type of the object.
After registration, exported methods of the object will be accessible remotely.
A server may register multiple objects (services) of different types but it is an error to register multiple objects of the same type.

RPC Steps:

client procedure -> client stub
client stub -> client OS
client OS -> server OS
server OS -> server stub
server stub -> server procedure
server procedure -> server stub
server stub -> server OS
server OS -> client OS
client OS -> client stub
client stub -> client procedure

Stubs

Serialization, pickle, marshals: transform structure data to bytes

Client stub:

serialize arguments into machine-independent format
send request to server
wait for response
un-serialize result and return to caller

Server stub:

un-serialize arguments
call procedure
serialize result
reply

It is like ABI (Application binary interface)-Encoded Constructor Arguments

Example RPC: klzzwxh:0005 means "host to network byte order, long" (big-endian is standardized to deal with cross-platform variance) — Example RPC: `htonl()` means "host to network byte order, long" (big-endian is standardized to deal with cross-platform variance)

runtime: a process that runs in the background to provide service to other service

Interface Definition Language (IDL): a language to describe interface.

Abstractly, it replaces the stack of client machine by data sent from server. But then we need to know the exact size of returning data to copy.

With RPC, though. You can't pass everything. Pointers are problematic to pass to server. So pure functions are good in RPC.

Shallow integration:

user define how to format data
user register functions and invoke methods

Deep integration:

automatic serialization based on nested types, but it is programming language dependent
automatically register functions in an object

Challenges of RPC

memory access
latency
failure: communication failure, machine failure

It is sometimes impossible to distinguish machine failure from communication failures. It is a decision to and not to break transparency and make failure visible.

There are choices to tolerate network failure: (semantics)

Exactly once: impossible due to failure
At Least once: server is memoryless, server's application is idempotent (idempotent operations)
At Most once: message de-duping before go into server application (either zero or once), the client may or may not only send once. However, this is usually implemented as a fire-and-forget strategy like heartbeat.