Outline: RPC
- RPC model
- Sun RPC
- T/TCP
- x-kernel RPC:
RPC Model
- local procedure call involves:
- calling a specific procedure with arguments (if any)
- arbitrarily long suspension of the caller
- the caller is awakened when the called procedure returns
results (if any)
- remote procedure call involves:
- calling a specific procedure on a specific processor
and passing any arguments
- arbitrarily long suspension of the caller
- the caller is awakened when the called procedure returns
any (or no) results, or the communication failed
RPC Model -- details
- transaction ID (XID) identifies an exchange
- Asymmetric protocol: client sends requests, receives replies, server
receives requests, sends replies.
- arguments are:
- marshaled (converted to a standard form) on the client
- sent with the request
- unmarshaled (checking for errors) on the server
- return values and status are:
- marshaled on the server
- sent with the reply
- unmarshaled on the client
Sun RPC
- Developed and standardized by Sun Microsystems.
- Functions: synchronization of requests and replies, reliability, and
demultiplexing.
- "RPC" is generic for "remote procedure call", Sun RPC identifies
a specific protocol.
Sun RPC:
synchronization and reliability
- Client sends request, waits. Server receives request, processes, {\em
always} sends a reply. Client receives reply, starts up caller thread.
- A reply always carries a status as well as data.
- Request is retransmitted until a reply with matching transaction ID
is received (reliability).
Sun RPC: reliability
- Problems: Transaction ID not stored in client, only stored for short
time in server.
- If client re-uses the same ID quickly, the server might
think it's a retransmission, and re-send the old reply.
- If a long-delayed request arrives at the server, the server might not
realize it's a duplicate.
- RPC provides two fields, credentials and verifier, that
can be used for authentication.
Sun RPC: demultiplexing
- Sun RPC uses 3 32-bit fields for demultiplexing: program number, version
number, and procedure number.
- Sun RPC runs over UDP. Which UDP port does server X use? (e.g., NFS).
- Port Mapper is a server that (using RPC) maps program numbers to UDP
port numbers. Port Mapper binds to the well-known port 111.
Sun RPC: Summary
- Procedure Call model (synchronous). Sun RPC also includes XDR for
argument and result marshaling.
- Asymmetric protocol: client sends requests, receives replies, server
receives requests, sends replies.
- Many different RPCs.
T/TCP
- TCP extensions for transactions (request/response interactions), RFC 1644
- TCP Accelerated Open (TAO):
- server can cache TCP connection information
- SYN packet carries request and also has FIN bit set
- SYN-ACK packet carries reply and also has FIN bit set
- transaction is complete by an ACK packet
- a connection counter distinguishes successive requests/replies
(at-most-once semantics)
- TAO both opens and closes the connection
- falls back to three-way-handshake if server does not have
connection cached
x-kernel RPC
- Blast: fragmentation, acknowledgement, retransmission, but not
a reliable protocol (may give up).
- Chan: basic RPC, with channel ID, transaction ID, at-most-once semantics
- Select: called-procedure identification
- non-standard RPC protocol built from general-purpose "building blocks"
Blast protocol
- receiver sends a selective retransmission request (SRR -- a
combination positive and negative ack) when:
- the last segment arrives
- a timer expires that was started when the first fragment arrives
- a retry timer expires that was started when we first sent SRR for
missing packets
- sender keeps packet for a fixed time, or until a completely positive
SRR is received
- more reliable than IP fragmentation (retransmits missing fragments),
but not as reliable as TCP (will give up after a certain time)
- at most 32 fragments per packet, since the SRR has a 32-bit bitmask
Chan protocol
- interfaces below to a send/receive (asynchronous) protocol, and
above to an RPC (synchronous) protocol
- retransmits until ack is received
- reply is ack for request, next request is ack for reply
- probe packets assure that the server is still working
- "boot ID" prevents errors, allows message ID counter to start at 0
rather than random number