Tonic support next steps
#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::Servicewhich internally dispatches to theEnvironmenthandle for new connections. -
To improve ergonomics a bit, it would be nice new
Environmenthandles 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-tonicbank.rstest 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 detectedIt 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.