Once we have the client and server daemons communicating, the latency of operations will need to be measured to ensure that the connection is good enough to remain in the connected state (vs. emulating state).
There are two (simple) possibilities here. We could either add this functionality to the NOP RPC, or every RPC. Either way, the RPC request should include a timestamp field containing the current time at the client when the request was sent. The corresponding response will simply copy the timestamp and send it back. Upon receipt, the client can figure out the latency of the operation.
NOP
Just add the uint64_t to the request and response structs.
Generic
Add the uint64_t to the command header request and response structs, and fill them in generically.
Once we have the client and server daemons communicating, the latency of operations will need to be measured to ensure that the connection is good enough to remain in the connected state (vs. emulating state).
There are two (simple) possibilities here. We could either add this functionality to the NOP RPC, or every RPC. Either way, the RPC request should include a timestamp field containing the current time at the client when the request was sent. The corresponding response will simply copy the timestamp and send it back. Upon receipt, the client can figure out the latency of the operation.
NOP
Just add the
uint64_tto the request and response structs.Generic
Add the
uint64_tto the command header request and response structs, and fill them in generically.