Native JAI Port

[dbechrd]

Originally posted by @dbechrd in #213 (comment):

I just finished (mostly) doing a native port of Yojimbo (and Serialize/Reliable/Netcode) to Jai.

I made a few changes as I went, but it's mostly on par:

• I removed the per-client memory allocators temporarily, as Jai has a completely different way to do allocators that I will probably try to use later.
• I tried to remove the reference counting from the Message class, as it's quite error-prone in Jai (which doesn't have destructors), but I had to add it back to get the tests to pass. I think it may be causing a memory leak in certain rare scenarios (e.g. when the sequence buffer overflows in the tests), but I haven't been able to find it, so I don't know if that bug exists in the C++ version or not. I will probably try to remove/improve it again later.
• I stubbed out libsodium for now, to avoid the dependency while porting, but I will probably do a native port of the few functions in libsodium that Netcode relies on (ChaCha20-Poly1305, its extended variant, and the secure random bytes code); not because it's necessarily a good idea, but for fun.
• All the MessageFactory macros were removed completely. My MessageFactory is just an array of create/serialize function pointer pairs. Jai's macro system is completely different from C/++, so it wasn't possible to port it directly. The new version still needs some improvements, but it works.
• I removed a bunch of redundant functionality (e.g. why are there two different Address implementations, and two different SequenceBuffer implementations, and two different Queue implementations, etc.?). I also rewrote the Address class entirely to remove all system dependencies, and improve error reporting when the parse fails, and published it as a standalone Jai module (https://github.com/dbechrd/jai-ip-address).

Overall, it was a joy to read your code. Your test coverage is phenomenal and the port would have failed catastrophically if it weren't for the tests. I fixed at least 50 bugs in my implementation while porting the tests. I will say that the uber-C++-ified Yojimbo was the least fun part of the library to work on, and was quite difficult to understand since it's spread across tens of files and uses tons of inheritance/virtual/macros. The C libraries were extremely trivial to port in comparison, and felt much more straightforward and consistent. It would be cool to see a C version of Yojimbo one day.

I mostly did this project to learn Jai, and to better understand the internals of Yojmibo et al (which I was already using in an unreleased game written in C++). I don't plan to keep my port up-to-date with the main branch, and even if I publish it, I would still recommend people just generate bindings instead of using a point-in-time native port. I honestly didn't realize when I started this how often you're still updating the libraries (which is awesome!). I'm also not sure if my protocol is compatible with the C++ version, because I haven't implemented encryption yet so I can't test it. My original plan was to port Yojimbo, then use what i learned to refactor it heavily, perhaps into something else entirely, but I dunno what will come of that. I may also try to make a network traffic visualizer to provide more insight into how it works in a visual/interactive way. I'll let you know if anything cool comes of it.

FYI, I just published my Jai port as Jai modules here:

https://github.com/dbechrd/jai-serialize
https://github.com/dbechrd/jai-netcode
https://github.com/dbechrd/jai-reliable
https://github.com/dbechrd/jai-yojimbo

They also depend on these standalone modules:

https://github.com/dbechrd/jai-ip-address
https://github.com/dbechrd/jai-trivial

It's completely usable, aside from encryption which is stubbed out as mentioned above. I've set the project aside for now, but will probably revisit it whenever I get time to work on a multiplayer project again (e.g. to finish porting the libsodium stuff).