Tokio + serde rewrite

[Selicre]

Since async programming is getting quite popular, I decided to test out tokio's codecs and it turns out that they are very well suited for minecraft's protocol, since it's effectively length-delimited. I haven't touched encryption or compression yet, but the former seems to be quite easy to write a Read/Write adapter for and the latter should be pretty much the same as the synchronous implementation.

I also figured that it's possible to use serde to automatically deserialize the vast majority of packets, and use the fact that the protocol is pretty consistent with how arrays are length-prefixed, and enums are id-prefixed with varints. There will definitely be packets for which (de)serializing will be much more complex, but it's easy to simply parse the packet manually if that is the case.

As a bonus, it would be much easier to translate packets between versions - all you need to do is just serialize them in a self-describing format such as CBOR and then read them back. Not foolproof, but it should work for simple cases.

I've made an initial implementation that works here: https://hyper.is-a.cat/gogs/x10A94/mcproto/ - note that most of the packets aren't implemented yet, in part due to their complexity, and are simply stubbed out.

[C4K3]

Sounds good. I had gotten it working with mio but never got it cleaned up enough to push. I'll take a look at what you've done this weekend.

[Selicre]

mio is extremely low-level, and it does seem like it'd be hard for people to use. On the other hand, tokio is much more user-friendly, with all the futures-based abstractions that it offers.

[NyxCode]

Did you make any progress on this? Sounds really promising!

[Selicre]

Sadly, I do not have the time to update my framework to 1.14; if you manage to get it to work, I'll publish my implementation on github so that you can make a pull request.

[Songtronix]

I don't know if that's a good idea especially when async/await syntax will come soontm

[Selicre]

I don't know if that's a good idea especially when async/await syntax will come soontm

The general structure will not change - not only that, you don't need to rewrite existing async functionality, for the most part, as Futures aren't going away regardless, and the majority of my rewrite deals with automatically generating packet definitions from the structs themselves, not networking.