Closed fanick1 closed 4 years ago
I have actually worked around the issue by having large amount of channels (254) for unreliable communication. The game runs at 60fps, so it burns approximately through 60 channels per second, leaving enough headroom for the late packets. I iterate through the channels for each packet sent, hoping that the occasional jitter would not span across ~254 game ticks (i.e. > 3 seconds)
You shouldn't use a large number of channels as that's not really what ENet is designed for. I have been unable to reproduce this problem based on your description, so I would appreciate a testcase that reproduces the issue so that I can actually just fix it rather than force people to use pretty horrific workarounds.
Hi @lsalzman , I have stitched together a little demo to demonstrate the bug. https://github.com/fanick1/enet_issue_134
repro steps are in the README.md (emphasis on the packet reordering setup via tc
)
I believe I fixed this in ENet now, so it should just work.
Perfect, it works in the testing project and also in the original game code. YOU ARE AWESOME! Thank you soo much. I would say this is worth a release :100:
Hi, I think there might be some bug in ENet that causes it to crash when the network conditions are crap.
I'm developing online gameplay for the game duel6 where the packets are being sent unreliably most of the time to transfer for example player's positions. I create the packets with flags
ENET_PACKET_FLAG_UNSEQUENCED | ENET_PACKET_FLAG_UNRELIABLE_FRAGMENT
(on separate channel from the reliable packets if that plays any role). In one test scenario I artifically induce delay and jitter on the server with the commandsudo tc qdisc change dev ens3 root netem delay 500ms 150ms 50%
- i.e. 500ms additional ping with 150ms variance with the next random element depending 50% on the last one. The amount of data is above the MTU of 1400 bytes, so some fragmentation needs to occur. (I'm doing this test to make sure the game actually works in real life network conditions that we have came across during game testing). In this scenario the game crashes in first seconds after client connects and the server starts pushing game state updates. if I remove the ENET_PACKET_FLAG_UNRELIABLE_FRAGMENT flag, the game does not crash also if I don't induce the jitter the game also does not crash.I have run the game with the valgrind with the following finding:
The ENet version used is the latest master version (5de0a6f76). I have previously used 1.3.12 (version available in Ubuntu repos) with the exact same result (game crashes when ENET_PACKET_FLAG_UNRELIABLE_FRAGMENT was used and network jitter applied).
I suspect the bug is in the function
enet_peer_dispatch_incoming_unreliable_commands
where theenet_peer_remove_incoming_commands
gets called.