Current thoughts on how RPC could be implemented as a BSP client:
-
Each procedure call is encoded as a message
-
The arguments may be marshalled into the message itself (pass by value) or its dependencies (pass by reference)
-
The response is a message that depends on the call
-
The client may wish to garbage collect calls that have been answered, or keep them, e.g. for auditing
-
Sync semantics mean that calls are automatically retried idempotently -- the call semantics are "eventually exactly once"
-
If the RPC library offers a conventional interface (i.e. one that resembles a local procedure call), the caller will be responsible for holding program state until the call returns
-
Alternatively, since a conventional RPC interface may not be well suited to a delay-tolerant implementation, the caller could use the library to save its state and retrieve it when the call was answered or abandoned
-
The state could be saved as metadata or unshared data
-
We could get elaborate with this -- each stack frame could be a message with a dependency on the previous frame, allowing the live program state to be replicated. Obsolete frames popped off the stack would be garbage collected
-
But this is getting a long way from what's normally thought of as RPC