...
The RAMCloud RPC header will consist of the following fields. The usage of these
fields are explained below.
| Code Block |
|---|
<--------------32 bits--------------> +--------+--------+--------+--------+ | Connection ID | Flag Flags | +--------+--------+--------+--------+ | RPC ID | +--------+--------+--------+--------+ | Fragment ID | Total Fragments | +--------+--------+--------+--------+ |
...
The ``Connection ID'' field identifies the connection that exists between a
pair of
machines. This connection is one way onlyRPC requests can travel in one direction only through a
connection. That is, the connection identifies
the pipe that flows from machine 1 can do an RPC to machine 2 . The pipe from on one connection,
but a if machine 2 to
machine 1 is represented by another, then wants to do an RPC to machine 1, it would need another,
different, Connection ID.
RPCs in a connection are performed sequentially. That is, only one RPC at a time
is performed using a particular connection. If a client wants to perform
multiple RPCs in parallel, it must open mutliple multiple connections.
RPC ID
The ``RPC ID'' field uniquely identifies an RPC belonging to a particular
connection. Together, the server, the ``Connection ID'' and the ``RPC ID''
uniquely identify
any RPC in the RAMCloud system.
When a new connection is established, an RPC ID will be chosen by the client at
random. Every new RPC made on that conneciton connection will have an ID that is one
greated greater than the previous RPC ID.
...
The ``Fragment ID'' field is used to identify a particular ethernet Ethernet frame sized
fragment belonging to an RPC. RPCs that are large enough to consist of mutliplemultiple
ethernet Ethernet frames will thus have more than one fragment. The Fragment ID starts
at 0.
...
The Request flag is set when the packet is part of an RPC request . That is, from the
client sends the packet to the server requesting an RPC.
Reply flag
The Reply flag is when the packet is part of an RPC reply. That is, the server
sends the packet ot to the client as a reply for a RPC request that it received.
...
- The control bit will be set.
- The opcode (first byte of the payload) will be 0x02.
- The rest of the payload will be a bit map representing the status of all the
fragmetns fragments of the payload. If a bit is 01, it means the corresponding fragment was
not received, and if a bit is 1, it means the corresponding fragment was
received with no errors.
The ACK reply flag has not been given its own bit in the Flag Byte because it
will not be piggy-backed on normal data packets.
Use cases:
Single packet
...
request is lost
When an RPC request that consists of only a single packet is lost, the client
will time out while waiting for the server to reply. When it times out, the
client will resend the entire request. The client will perform a fixed number
(X) of these resends before giving up and throwing an exception.
...
When an RPC response that consists of only a single packet is lost, the client
will time out, and resend the request just like in the previous case where a
single packet requset request is lost.
For each connetionconnection, the server maintains the most recent RPC response it
generated in memory.
When the resent request is received by the server, it will simply take the RPC
resposne response it has already comuted computed from its history list and send it back to the
client. Thus, it need not perform the computation required by the RPC once again.
...
When all fragments of a multi fragment response are lost, this case becomes
simliar similar to the single packet response is lost case, and the same steps are
followed.
When only some fragments are lost, the client times out and sends an ``ACK
Reply'' packet, even though it has not recevied received an ``ACK Request'' packet. When
the server receives this ``ACK Reply'' packet, it resends all the fragmens fragments that
were lost. The client will now have a full RPC response, as long as none of the
resent packets were lost as well.
...