Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upServer shuts down before it has finished processing a client request #321
Comments
|
Or maybe I have just greatly misunderstood how to use the library. Any input is greatly appreciated! :) |
|
Hey, thanks for the interest! Quick plug of our discord channel, which is good for longer-form discussions.
Try this: BaseChannel::with_defaults(server_transport)
.respond_with(HelloServer(client_addr).serve())
.execute()
.await; |
|
By the way, I'd appreciate any PRs to make the documentation more helpful! |
|
Awesome! Thanks. Fewer types involved and fewer hacks needed ( |
|
Hey @faern, anything else you need help with? Can I close this issue? |
|
Thanks for the new example. That's awesome. I still think there is some documentation that can be improved. But I have not had the time to play more with this since you provided additional information.
It seems this documentation is not entirely true since the future completes before the response are fully completed? And it's not immediately clear to me that "connection is closed" refers to the listening server socket and not all the client sockets. |
|
The discord invite does not work. Maybe it expired or I'm not good enough at understanding discord Do you link to the discord anywhere except randomly in issues? It's not in the main readme. It would be a great way to find the community. |
|
There's a discord badge in the readme |
This refers to the one client connection managed by the channel. It does not refer to a server listening on a socket. |
|
Thanks! Badges does not work for ctrl-f |
But you just said the opposite:
.. Or I'm too tired :D |
|
I think the confusion is that there are multiple |
I took the example crate from this repository,
example-service, and started converting it towards usingtarpc::serde_transport::new. I want to learn how to use this crate in a transport agnostic way[1].I then changed the server to only accept a single TCP connection and create a tarpc server for that single connection[2]. I took inspiration from the server example code in the main crate documentation using
.incoming(stream::once(future::ready(server_transport))).I ended up with this: https://github.com/faern/tarpc/blob/a1ffbec2a8c7c6ebbd3c5701f1654ee13829cf6d/example-service/src/server.rs.
However the server would die and the client would print
Error: Kind(ConnectionReset). I realizedserver.awaitreturned before it was done processing the client request. Adding an ugly sleep made it work again: faern@0ac9f34#diff-31d1194bbeab9b1b6afdc652567b5a0193287d4e8bba43bc13b4ccbb648320d0.Another way to hack around it is with this solution: https://github.com/faern/tarpc/blob/9e9f6306f54c524557829a43fffa1029e2edea1f/example-service/src/server.rs#L68-L74
I think the first type of solution (the one not working properly) is the cleaner from the aspect of consuming
tarpc. I don't need to pull out a singleChannelout of the stream withnext()etc. I just give it a single transport and tell it to process that entire transport. The problem is that it does not process my entire transport, it aborts prematurely.[1]: I'm ultimately going to use this over virtual serial ports and domain sockets. So personally I would love if this crate had an abstraction level where it could be used without any predefined transport being mixed in.
[2]: My use case is to host an RPC server in a virtual machine where some hypervisor administrator process will talk to it over a virtual serial port. As a result there will only ever be one "client" to this RPC server (the serial port file). I would love if the crate allowed expressing this in a nice way.