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