Multiple services on one server/port #153
Comments
|
I think the former would follow from the latter, but we don't support the former. I was considering supporting it at one point but there was no demand and it seemed like a fairly nice feature. Can you tell me more about your requirements that could benefit from this? |
|
We have an API with a lot of functions, and we want to group them by concerns into services like it's usually done with gRPC ('separation of concerns'). (The alternative is to use long underscore function names like |
|
Ah ok, that makes sense! So I'd love to be able to support this use case, but it's a fairly radical departure from how things are done now. Right now tarpc is a pretty thin layer on top of tokio, which is nice from a maintenance perspective. Supporting multiple services per port would basically require a substantial rewrite, and I don't think I have the bandwidth for it any time soon. |
|
That's not to discourage anyone else from working on this! |
|
So....the substantial rewrite ended up happening. I believe you can now accomplish this in the transport layer, by having connecting clients do a handshake where they send a message with the service name. On the server side, there'd be a service registry, something like a Are you interested in working this? I think it'd be pretty cool to get a demo of this working! |
# Changes
## Client is now a trait
And `Channel<Req, Resp>` implements `Client<Req, Resp>`. Previously, `Client<Req, Resp>` was a thin wrapper around `Channel<Req, Resp>`.
This was changed to allow for mapping the request and response types. For example, you can take a `channel: Channel<Req, Resp>` and do:
```rust
channel
.with_request(|req: Req2| -> Req { ... })
.map_response(|resp: Resp| -> Resp2 { ... })
```
...which returns a type that implements `Client<Req2, Resp2>`.
### Why would you want to map request and response types?
The main benefit of this is that it enables creating different client types backed by the same channel. For example, you could run multiple clients multiplexing requests over a single `TcpStream`. I have a demo in `tarpc/examples/service_registry.rs` showing how you might do this with a bincode transport. I am considering factoring out the service registry portion of that to an actual library, because it's doing pretty cool stuff. For this PR, though, it'll just be part of the example.
## Client::new is now client::new
This is pretty minor, but necessary because async fns can't currently exist on traits. I changed `Server::new` to match this as well.
## Macro-generated Clients are generic over the backing Client.
This is a natural consequence of the above change. However, it is transparent to the user by keeping `Channel<Req, Resp>` as the default type for the `<C: Client>` type parameter. `new_stub` returns `Client<Channel<Req, Resp>>`, and other clients can be created via the `From` trait.
## example-service/ now has two binaries, one for client and one for server.
This serves as a "realistic" example of how one might set up a service. The other examples all run the client and server in the same binary, which isn't realistic in distributed systems use cases.
## `service!` trait fns take self by value.
Services are already cloned per request, so this just passes on that flexibility to the trait implementers.
# Open Questions
In the service registry example, multiple services are running on a single port, and thus multiple clients are sending requests over a single `TcpStream`. This has implications for throttling: [`max_in_flight_requests_per_connection`](https://github.com/google/tarpc/blob/master/rpc/src/server/mod.rs#L57-L60) will set a maximum for the sum of requests for all clients sharing a single connection. I think this is reasonable behavior, but users may expect this setting to act like `max_in_flight_requests_per_client`.
Fixes #103 #153 #205
|
#204 provides an extended example for how to do this. |
|
@tikue I am struggling to find an example anywhere in the project, has it been moved/removed? Any idea where I can go to find an example of this? |
|
@acidic9 I did remove some examples at some point! I don't know if I would endorse the particular example I was referencing, but if you're curious you can find it on the pull request. |
I don't see a way to serve multiple services (for different 'concerns') on one server/port. Is there a way (like in gRPC)?
Similarly, if one client executable wants to use multiple services, can it reuse the same connection among the different instantiated clients? (like in gRPC)
The text was updated successfully, but these errors were encountered: