Hi David,
thank you very much for the answer. I wasn't able to finally test it,
because I am now having a different problem related to my post.
Suppose I have the following server implementation:
class ServerImpl:public ServerInterface::Server {
private:
std::vector<ClientInterface::Client> registered_clients_;
public:
kj::Promise<void> registerClientInterface(RegisterClientInterfaceContext
context) override {
this->registered_clients_.push_back(context.getParams().getClient());
}
// ...
}
class ComHandler {
public:
void Run(const std::string& ip_address, std::size_t port) {
capnp::EzRpcServer server(kj::heap<ServerImpl>(), ip_address, port);
kj::WaitScope &wait_scope = server.getWaitScope();
kj::NEVER_DONE.wait(wait_scope);
}
void InvokeFunctionOnClient() {
// Here I need access to ServerImpl owned by EzRpcServer.
// How would I do that?
}
}
I can only store the client capabilities in class "ServerImpl" since an
rvalue is needed for pushing to the vector. Since the object of
"ServerImpl" is owned by EzRpcServer, I do not have the possibility to
invoke a client's function from outside, e.g. from class "ComHandler".
How would I do that?
Best regards,
Jupp
On Sunday, July 3, 2016 at 9:47:27 PM UTC+2, David Renshaw wrote:
>
> Hi Jupp,
>
> To handle disconnects, the method signature could be something like:
>
> ```
> interface Server {
> registerClientInterface @0 (client :ClientInterface) -> (handle:
> Handle);
> }
> ```
>
> where `Handle` is an interface with no methods. The server's
> implementation of `Handle` could then have a destructor that does the
> appropriate deregistration when the client drops its reference to the
> returned `handle`.
>
> There's an example showing this pattern in the capnp-rpc-rust repo:
> https://github.com/dwrensha/capnp-rpc-rust/tree/master/examples/pubsub
>
> - David
>
>
>
>
> On Sun, Jul 3, 2016 at 3:33 PM, <[email protected] <javascript:>> wrote:
>
>> Dear Cap'n Proto users,
>>
>> I have a server application that is controlled by one or more connected
>> clients. In the past I used Protobuf for serialization, implementing my own
>> very basic RPC mechanism on top of it. I would like to replace the RPC
>> system with Capnproto. First tests invoking function calls on server site
>> were successful. Since the communication needs to be bidirectional on the
>> same connection, the server provides a function "registerClientInterface"
>> which takes the client interface capability as argument. The capability is
>> stored in an array so that the server can send the same function calls to
>> every connected client. My question is if this is the right design at all?
>> How would I handle disconnects deregistering the capability of the
>> disconnected client? Is this possible with EzRpcServer and EzRpcClient?
>> Any suggestions?
>>
>> Best regards and thanks in advance,
>> Jupp
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Cap'n Proto" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> Visit this group at https://groups.google.com/group/capnproto.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
Visit this group at https://groups.google.com/group/capnproto.
