Tonic support next steps #8
Description
#4 Brought in initial support for Tonic, but it is incomplete and there are several issues which makes it difficult to use.
-
@LucioFranco mentioned that we should provide our own transport for Tonic. I believe this entails providing an implementation of
tower_service::Service
which internally dispatches to theEnvironment
handle for new connections. -
To improve ergonomics a bit, it would be nice new
Environment
handles could be registered with a hostname, and the hostname be used to resolve network endpoints. I imaging something like:let server1 = runtime.handle("server1.cluster.local"); let server2 = runtime.handle("server2.cluster.local"); server1.spawn(start_server()); server1.connect("server2.cluster.local").await;
-
The
simulation-tonic
bank.rs
test currently uses timeouts to drop send/receive futures. This seems to result in occasional errors returned by Tonic.server error: grpc-status: Unknown, grpc-message: "http2 error: protocol error: unspecific protocol error detected
It would be good to figure out how these can be better reported to users. Additionally, Tonic
seems to support [automated reconnects] .
(https://github.com/hyperium/tonic/blob/master/tonic/src/transport/service/reconnect.rs).
Simulation users should be able to take advantage of this in their applications.