Protocol Stability & Backwards Compatibility

[alextechcc]

I really love a lot of the ideas this crate has for using entities with components to represent sessions, IO connections - and I think I'd like to replicate the patterns myself if this doesn't work out.

I have a use-case where protocol stability and even interoperability outside of Rust is desired. Am I correct in assuming that these are not the intended use of this crate? I.E. the format of the transport header is not guaranteed to be stable over time - and so each instance of a game would have to be on the same aeronet_transport version? And - given that the README implies that there's considerable use of aeronet_transport - swapping it out for my own versioned protocol layer may be challenging?

[aecsocket]

Yeah, the design goal of aeronet_transport does not include any guarantee of protocol stability. This gives me the freedom to optimize it in the future, and keep in mind that this is still a very young project. Even in the recent 0.12 release I released a breaking internal change to the protocol, so I have definitely not found the optimal way to lay it out yet. I wouldn't be against stabilizing the protocol in the future, and releasing an "aeronet_transport protocol v1", "v2", etc. (this will probably not follow the semver of the crate itself, but I'm not sure yet).

About swapping out aeronet_transport for your own stabilized layer: this is something that I've also been considering how to handle. Fundamentally, the problem is that higher-level crates (aeronet_replicon, a potential aeronet_lightyear, your own game code, etc.) need to use some Rust item to represent e.g. a message key identifier (MessageKey), a fn send(), etc. This means that aeronet_transport is inherently both the reliability+ordering interface and implementation. I'm hesitant to split the two because it means I'll have to solve questions like:

• What is the "universal" MessageKey type layout?
  • Currently it's a LaneIndex + MessageSeq, but these are also concepts specific to aeronet_transport
  • I'm hesitant to just use a raw u64 because what if some implementation only needs u32 to store a key? Or needs more than u64? It just seems like an arbitrary type to choose
• What's the interface for enqueueing and polling messages from the transport?
  • The current TransportSend::send is nice because there's no dynamic dispatch, there's no indirection, you just query a component and perform some concrete logic. If we split interface and implementation, we'd need some kind of indirection.

It is possible to fork aeronet_replicon or any other crate to use a different transport layer to aeronet_transport, however obviously this isn't a scalable solution. And I'm also hesitant to split the interface and implementation of aeronet_transport because of the problems laid out above - any aeronet_transport_api would end up being highly specialized for aeronet_transport_impl, and would introduce unnecessary indirection + complexity. Of course, if you write higher-level features like replication yourself, then you don't have to deal with aeronet_transport at all, and can use aeronet_io directly, which might be perfect for your use case. I had the foresight to at least split the IO/transport layer for this reason 😀

Tldr: I don't want to split aeronet_transport into an API and implementation, so higher-level integration crates will still depend directly on aeronet_transport. So I think the long-term solution is to stabilize the protocol format, however I'm hesitant to do this now because the protocol and crate is still so young. I'd want to add a lot more unit tests, fuzz tests etc. before stabilization is on the table.