Networking Discussion

[MDFL64]

Old Version

• Client requests voxel config once it sees a voxel entity.
• Server sends the config and adds an init task for the client.
• Chunks are sent in order.
• Every tick, send up 2kb (maybe a little more) worth of compressed chunks.
• Once all chunks are sent, send voxelate_init_finish. This tells the client it can start building chunks.

What Needs Changing

• ~Do as little shit in Lua as possible.~ Just make sure chunk data stays away from lua.
• Just send all configs on player join. Store them in a table so the entities dont need to be initialized. Init voxels when we get the entity or when we get the config, whichever happens later.
• Don't let the server tell us when we can and can't build chunks. Either set up our own timer to start generation, or only generate chunks with at least 3 neighbors (Need exceptions for very small voxel maps!)
• Keep a table of which chunks have been networked to each client. Alternate: Track the chunk the player/viewer entity is in and track which changes need to be networked to clients.
• For finite maps, just keep networking all the chunks, but possibly use one of the two systems above to accomplish it.
• For infinite maps, only network chunks in a certain range. We can probably just have client render all the chunks it knows about to simplify things.

New Version

Terminology:

• PUID: A security key used by the handshake.
• PeerID: ENet client identifier.
• Router: Singleton that handles all the networking for a given state.
• Channel: A single message 'type', can be named.
  • Is this part of ENet or something we've defined ourselves?
  • Can we just define these all in one spot? Currently the Auth and init channels are defined in two different spots.
  • Is the channel class even used? Side snark: Shoehorning excessive amounts of class-based OO into lua makes me want to go on a killing spree. If we wanted to make a better minecraft then why the hell are we writing this in Java?

Process:

• Client sends gmod_vox_sync, server responds with gmod_vox_sync containing the player's PUID.
  • Can we add the client's module version to the request? I don't think we have any version checking logic in the new version yet?
  • There's a separate Lua version. Okay. Why?
• Server listens for AuthHandshake, which contains the PUID.
  • Do we want to just boot the client if they fail?
• Configs are still requested.
  • I'd rather just send them indiscriminately unless you have a real good reason not to.
  • Is there any good reason to start adding sub-message types within individual channels? Seems like it kinda defeats the point of having channels.
• How exactly do we want to handle cases where the client loses connection in ENet but not source? Boot them?
• Also probably boot the client if they don't sync within a certain timeframe.

[SwadicalRag]

Every tick, send up 2kb (maybe a little more) worth of compressed chunks.

we can do better (i've started on this locally)

[SwadicalRag]

Chunks are sent in order

this will save like 12 bytes per chunk since chunk order is implied, I can see the benefit. Very well, we can add this to the VoxelWorldInit channel

[MDFL64]

Affirmative. I'm willing to bet a lot of the overhead was from dumping that data into Lua and then shoving it back into source's networking garbage, which I'm sure is even more jank under the hood.

Also I wouldn't keep sending them in order. Order is a little more subjective with huge worlds that you can't see all of.

[SwadicalRag]

Do as little shit in Lua as possible. Sending configs still fair game because serializing config struct would be an even bigger shitshow.

I'm willing to bet a lot of the overhead was from dumping that data into Lua and then shoving it back into source's networking garbage

I doubt using Lua for networking would put us at a disadvantage at this stage, since we're mostly using a single c-function to send the packet data and, optionally, a C-based bitbuffer to construct the data

It's still possible to send networking data from c++ (receiving from c++ is unimplemented still) but why bother really

[MDFL64]

Alright, I'm cool with it as long as we can avoid dumping the chunk data into the lua state, because that seems like a bad idea in general.

[MDFL64]

I've update my post with my attempts to understand what's going on, as well as my dumbass opinions.

[SwadicalRag]

Okay I'm neck deep in shit right now but I mostly agree with what your said. The init channel was only a test to see what I could do with this system and its totally optional to use the oop version of channels. (Just register the channel in shared and use router: Listen)

tbh OOP is appropriate at places, maybe just not channels? There's little overhead in using OOP anyway

Enet had its own channel which I used to separate c++ and Lua networking

[SwadicalRag]

There's a separate Lua version cause we have debug hotloading

[SwadicalRag]

I reckon just boot the client if it gives us a shit puid or disconnects from enet

[MDFL64]

Okay, I'm going to make some more minor modifications to the branch and on gm_f1atgrass until I get things working.

[SwadicalRag]

Ook I'll be available later tonight to help out

[MDFL64]

I've gotten some things working on my end. Physics work, but rendering doesn't as chunks are not networked right now.

Will push my changes in a minute.

[MDFL64]

dims-in-blocks branch in testbed has updated code.

[MDFL64]

There's still a lot of shit I want to fix/improve/remove/simplify, but I've had enough for the time being. Might get back to it later tonight, or tomorrow after my last test.

Note that there -may- be a crash bug hiding somewhere, but when I attached a debugger to try and find it I was unsuccessful.

[MDFL64]

Doing stuff.

[SwadicalRag]

done