Provisional network protocol

[nevyn]

I sat down with the visor once and looked at the different network classes... I've already built a network engine on TCP thinking I'd switch it to UDP, but never getting around to that and tcp for gamedev SuuuUUUUUCKS so I was hoping to do UDP off the bat. but building your own reliable comms over UDP is harddd and I don't want to do it myself, so I looked into unity's built in networking classes and found their "reliable udp" proto LLAPI aka NetworkTransport aka UNet. It's open source but only C# and seems a bit over engineered so I did NOT want to implement it from scratch. And then I gave up.... In the best of worlds I would like to use a tiny C webrtc library on both client and server side; but there isn't one. I would use RakNet if it wasn't dead. But it might still be usable...

[nevyn]

Actually it's silly to implement the same protocol in Erlang, C# and C (server, client, appliance). Let's make a C library on top of raknet that all three can use instead.

For Erlang I found https://github.com/mhsjlw/ExRakLib, but it's GNU and only supports unreliable, so it's a nogo. Raknet for C# is easy from asset store. But from C there's no work at all, so let's do that, and then foreign-interface it into unity and erlang. It'll be a great mm process in erlang :)

[nevyn]

okay raknet doesn't even compile anymore, abandoned by oculus four years ago. enet looks intriguing. can't quite make up my mind if I should use enet as-is from C# and elixir, or wrap it in a c library first.

actually, if I'm gonna write an appliance later, it'll definitely need a high level C API anyways. so it still makes sense to write a c library. buut it also makes sense to prototype that c library by making three implementations in three languages, as that will delineate a common api surface. e g I dunno if I should make a blocking or nonblocking api, etc.

• C: https://github.com/lsalzman/enet
• Erlang: https://github.com/flambard/enet
• C#: maybeee https://github.com/nxrighthere/ENet-CSharp

[nevyn]

screw good ideas, I accidentally started working on that stupid C API :P C# bridging looked so easy, and I know how to do Erlang bridges, so.

https://github.com/alloverse/allonet

[nevyn]

• Very rudimentary server and client APIs implemented in C
• Server is slightly more fleshed out, and its polling-with-clock API is designed for roughly how I think I'd implement it in erlang
• Client is much more rough, not really designed
• client actually takes keyboard input and can send rudimentary intents to server
• server can create avatars and serialize entity list over to connected clients
• uses both reliable and unreliable channels :) performance should be better than my previous attempts

I might've made a mistake putting so much server logic in C. Maybe it shouldn't know what an entity is, and just send json blobs. I don't mind it like it is now for testing though.

Now, I'll try to bridge this client to unity, and get it working from there. Should be straightforward.

Then, I'll bridge over the server stuff to erlang and replace stuff as it makes sense. This will be a bit harder to get pretty+efficient.

then we'll get to the interesting stuff, like state diffing and RPC.

[nevyn]

allonet works for both server and client now.