Open Thomasdezeeuw opened 3 years ago
One open question is how to do cancellation in RPC? A simple solution is to send a cancellation message when the client sees the RPC is dropped, but I'm not sure how effective that is.
A possibly better solution would be to set a deadline/timeout for each RPC, giving the (external) server knowledge of when the RPC should be cancelled.
There is also the question of compression. Depending on the message size this might not even be worth it, but zstd seems quite fast with a respectable compression ratio.
For tracing/logging, maybe allow/suggest an request-id.
New crate that does Heph specific communication between two nodes both running Heph. It's design is based on #307 and #473, where the cross-network communication is done by an actor behind a local
ActorRef
.A lot of requirements are already outlined in #188, so I'll just put the results/design decisions in this issue.
Protocol: UDP. Intra-datacentre communication using UDP doesn't drop too many packets, furthermore users should already be working with the expectation that not all message arrive. All we have to do is deal with packet duplication. In the future we can support TCP as well, or even newer protocol like QUIC.
Message (de)serialisation: to support forwards and backwards compatibility, without forcing the user to write an external type declaration (e.g. using Cap 'n Proto or Protocolbuffers), we need a schema-less serialisation, i.e. the messages must explain their own format. Two good candidates are MessagePack and CBOR, or possibly JSON.
For encryption we're blocked on issue #225, but using encryption with UDP is quite a challenge. I haven't found any (widely used) protocols for it and I'm not going to make my own.
Related #473.