Currently if rpc handler returns smart pointer rpc will try to serialize
the pointer object as opposite to an object the ptr is pointing to.
This patch fixes it by serializing real object instead of a pointer.
This adds a counters to net protocol client.
The client would holds counter for the successfully completed, the
exception recieved and as the sent queue is based on the future queue
a counter for pending to sent messages.
The number of messages that waiting for reply is retrieved from the size
of the outstanding table.
The counters are updated by the helper send function as part of the
messages sending flow.
The counters are part of the stat structure and the client has an
internal getter to be able to change their values and a getter that
returns a copy of the counters.
Currently it is not possible because a type is instantiated before been
deserialized. Fix that by allocating space for an object by using
std::aligned_storage.
Currently it is not possible because a type is instantiated before been
deserialized. Fix that by allocating space for an object by using
std::aligned_storage.
Unmarshalling function should not throw, but in case it does move
connection to an error state and report the error to an rpc client.
Currently all errors are reported as rpc::closed_error().
When call to marshall fails with an exception the exception future is
stored in dst.out_ready(). During next send sent future will not be
signaled because marshall() will never be called. Fix that by moving
sent future signaling to consider dst.out_ready() state too.
rpc::no_wait is too "no_wait" currently. When client sends a no_wait
message it immediately gets ready future in return, so client cannot
know when data is actually sent and can be discarded. This patch fixes
this by returning a future that will become ready when data is no longer
needed.
Client connection may outlive its do_until() loop. Make connection
point shared to overcome this. If connection dies while async handler
is running it will not be deleted until the handler is executed.
If rpc handler needs locally held information about rpc client that
making a call it may have client_info as a first parameter of rpc
handler. Rpc framework will pass it to the callback during invocation.
To register rpc handler func(param1, param2, param3) both server and client
auto remote_func = myrpc.register_handler(id, func);
This call will return another function that client can use to invoke RPC
calls like this:
remote_func(client, param1, param2, param3);
This call will return future<> with func() result.
