Giters

vorner / tokio-jsonrpc

Some experiments with JSON RPC in rust and tokio

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Server sending requests to clients

bluetech opened this issue · comments

commented

Hello! I stumbled across this project, hopefully you don't mind some random premature question.

I am not very familiar with futures/tokio yet. I wonder how you would handle a scenario such as this:

  • An async server SERVER serving multiple concurrent clients.

  • A client CLIENT connects to SERVER.

  • SERVER sends multiple concurrent requests & notifications to CLIENT.

  • CLIENT processes the requests and returns replies after a while, not necessarily in order.

Usually a client sends requests to a server, here it's inverted.

I assume SERVER would want to spawn a task per client, build up a future of the entire interaction with the client in that task, and wait on it?

In other languages, I would create a future per request, which I'll store in a pending requests map (mapped by the request ID) in the task. When a reply comes in, I match it to the request in the pending requests map and resolve the future. This way the mechanics of the RPC protocol are hidden, and for the caller, an RPC call is just Request -> Future<Response>.

Thanks!

commented

Hello

Maybe I haven't thought about the higher-level details yet, but I can't say I see a problem with this being reversed. After you either connect or accept a connection, it's up to you what you do with that connection. If you put the server structure/handling on the end that connected and client on the end that listened, than everything should work.

Furthermore, I intend to get to a place where one endpoint may be both the client and server at the same time, so this scenario would definitely be supported.

But as you said, this is a bit premature, because even the low-level parts aren't finished yet. So, I must admit I don't know yet how I'll reach that goal.

commented

Thanks! And good luck with the project.