This page documents design decision made regarding the RPC API.
It was decided that we should have three different types of RPCs:
- Traditional synchronous RPCs - where the sender blocks until a reply is received.
- Two phase send/wait synchronous RPCs - a process sends an RPC, does other work, and then waits on the reply of the RPC
- Callback type RPC - Completely asynchronous, where the sender of an RPC does not wait for a reply, but supplies a continuation function or callback which is invoked when a reply is received.
Current RPC API:
void handleRPC(void *callback_fn); void (*callback_fn) (struct sock_addr, RCBuf* payload);
It was decided to instantiate RPCObj objects for every RPC. The RPCObj object class will contain information pertaning to this RPC, such as address information of the sender and receiver, error codes, etc.
getReply throws an Exception if the RPC returned an error code.
void RPCObj::startRPC(struct sockaddr, RCBuf* payload); void* RPCObj::getReply() throws Exception;
Other issues to talk about next week:
- Should opcode be separate from the payload that is passed as the parameter to the RPC functions? If we need the opcode, can't we just look into the payload.
- What is a machine id? How do we identify services on the same machine?
- Semantics for handleRPC (on the server)
- Handle the case where backup fails while the master is writing to it.
- Thread dispatching mechanism on the server.
- How do we handle RPCs larger than the 8 MB
limit set at the driver level?