rytc / enet-jai

Native Jai port of the ENet Reliable UDP networking library

ENet Jai

This is a native Jai port (no c libraries needed, aside from the OS sockets) of the ENet reliable UDP networking library. Specifically this is of the zpl-c version that supports IPv6 and other features.

Current state

All ENet functionality is implemented, however it is not thoroughly tested.

What is ENet?

ENet evolved specifically as a UDP networking layer for the multiplayer first person shooter Cube.

Cube necessitated low latency communication with data sent out very frequently, so TCP was an unsuitable choice due to its high latency and stream orientation. UDP, however, lacks many sometimes necessary features from TCP such as reliability, sequencing, unrestricted packet sizes, and connection management. So UDP by itself was not suitable as a network protocol either. No suitable freely available networking libraries existed at the time of ENet's creation to fill this niche.

UDP and TCP could have been used together in Cube to benefit somewhat from both of their features, however, the resulting combinations of protocols still leaves much to be desired. TCP lacks multiple streams of communication without resorting to opening many sockets and complicates delineation of packets due to its buffering behavior. UDP lacks sequencing, connection management, management of bandwidth resources, and imposes limitations on the size of packets. A significant investment is required to integrate these two protocols, and the end result is worse off in features and performance than the uniform protocol presented by ENet.

ENet thus attempts to address these issues and provide a single, uniform protocol layered over UDP to the developer with the best features of UDP and TCP as well as some useful features neither provide, with a much cleaner integration than any resulting from a mixture of UDP and TCP.

Links

• ENet zpl-c fork https://github.com/zpl-c/enet
• ENet original https://github.com/lsalzman/enet
• ENet site http://enet.bespin.org/

enet-jai's Issues

Hang after running for a bit

There seems to be a bug that causes the server and client to hang after running for a while, especially when getting spammed with packets. The hang is caused by an infinite loop in protocol_send_reliable_outgoing_commands where it loops through the outgoing_reliable_commands list checking the window. Either window_wrap or window_exceeded ends up true, causing it to loop though all the commands in the list.

Either items in the outgoing_reliable_commands are not being removed, or possibly there is a bug causing the linked list to be cyclical. Or there could be a bug with this windowing system that's causing the checks here to not to pass.

I tend to think it's either the reliable commands are not being remove from the list or there is a bug in the linked list. Even if the window checks were incorrect, it should eventually run out of commands and break out of the while loop.

Buffers overflow on socket_send

Hey, I think I found another bug,

when I use the library on windows It tries to iterate over host.buffers with host.buffer_count which results in failed assertion, because host.buffer_count can be bigger than size of the buffers array which is currently set to MSG_MAXIOVLEN on Windows. This doesn't happen when I have short timeout for host_service() (1ms). If I change MAX_BUFFER_COUNT to the same value as other OSes (1+2*PROTOCOL_MAX_PACKET_COMMANDS), then it works even with large timeouts (30 seconds). Seems to me like there is some code that relies on host.buffers being bigger than they actually are?

Hopefully this could will help with solving this issue.

Daniel

Disconnect event on server doesn't contain peer's data pointer

Hello,

I come across an issue when .DISCONNECT (same for _TIMEOUT) event is received, the peer data has already been cleared. Is this desired behaviour? When I look at the demos of zpl enet, I see that they are using data in the .DISCONNECT event.

Thank you for any information.

Remove the toplevel `modules/` folder?

Is there a reason for the toplevel modules/ folder? Perhaps it would be better to remove it, this way you can download the code directly into your local project's modules/ folder it will work

Make the module a single file module and add more documentation

What do you think of plopping all the code into a single file, enet.jai, so that its a single file module? This would make searching the code easier since you can just Ctrl-f and find everything rather than needing to do some multi-file search thing. Its also nice to have as few tabs as possible related to other peoples code, currently when I work on networking stuff in my game I have a few tabs dedicated to just this module.

A separate point: there are a bunch of comments in the C repo which would be helpful to have here, what do you think about bringing them over? If we did the single file thing in a way which closely mirrors the positioning of functions in the C repository (https://github.com/zpl-c/enet) then even if we didn't port the documentation it would be easy to compare this code with theirs, this was a helpful thing to do when I was debugging the peer_reset function in an earlier PR. My preference would be do the single file thing as well as port the documentation though.

I am open to doing both of the above, I'm just checking how you feel about them before putting the work in :)