CSE 124 Lecture Notes - Lecture 11: Distributed Object Communication, Nine Network, Server-Side
27 Apr 2018
School
Department
Course
Professor
A Day in the life of an RPC
1. Client calls “stub” function (pushes params on stack)
2. Stub marshals parameters to a network message
3. OS sends a network message, sends it TO stub
4. Server OS receives message, sends it UP to stub
5. Server stub un-marshals params, calls server function
6. Server function runs, returns a value
7. Server stub marshals the return value, sends msg
8. Server OS sends reply back across the network
9. Client OS receives the reply and passes up to stub
10. Client stub un-marshals return value, returns to client
We want to limit the IDL that can be ported to different PLs
- create “common patterns” shared by PLs
The Server Stub is Really 2 Parts
Dispatcher - determines “which” code to execute
- Receives a client’s RPC request
- Identifies appropriate server-side method to invoke
Skeleton
- Unmarshals params to server-native types
- Calls the local server procedure
- Marshals the response, sends it back to the dispatcher
Note: all of this is hidden from the programmer!
What could POSSIBLY go wrong?
1. Client may crash and reboot
2. Packets may be dropped
3. Server may crash and reboot
4. Network or server might just be very slow
Note: 2-4 are indiscriminable to the client!
Failures, From Client’s Perspective
- again, the cause of the failure is hidden from the client
At-Least-Once Scheme
-”simplest” scheme for handling failures
1. Client stub waits for response
2. If NO response arrives after a timeout, client stub re-sends the response
3. If NO response after a few times, return an error to the application
ALO and Writes
put(x, value), then get(x): expect answer to be value
Document Summary
We want to limit the idl that can be ported to different pls. Marshals the response, sends it back to the dispatcher. Note: all of this is hidden from the programmer! What could possibly go wrong: client may crash and reboot, packets may be dropped, server may crash and reboot, network or server might just be very slow. Again, the cause of the failure is hidden from the client. Simplest scheme for handling failures: client stub waits for response, if no response arrives after a timeout, client stub re-sends the response, if no response after a few times, return an error to the application. Alo and writes put(x, value), then get(x): expect answer to be value. Client thinks value is 20, but the server thinks the value is 10! Eg read a key"s value in the db. If they are read-only operations w/ no side effects. If application has its own functionality to cope w/ duplication and reordering .
