My patience with this topic is very low at this point, so I apologize in advance for being somewhat curt.
On Windows, Mio does not work properly. See here for additional context. The end result is packet loss on Windows is much greater than on macOS or Linux. The effect of this will depend mostly on the application.
In an FPS, it might result in rubberbanding if the packet contained player position updates, for example.
When we started this, the goal was to build a low-level networking library that was rock-solid, reliable, stable, and fast. People using this library and building games or other applications on top of it should not have to worry about performance drops or other non-deterministic behavior across OSes.
Windows has the bulk of the gaming market. My personal opinion is that we are not being true to our goals if we ignore such a glaring discrepancy.
Below I will present the options I’ve thought of to deal with this, and hopefully we can have a productive discussion. We’ve been mired in this issue for weeks trying to decide if it should even be dealt with. We need to make a decision and move on.
Here we go!
Option 1: Ignore It
If our reliability system is good enough, and we make developers aware of the issue so they can code around it, we could potentially ignore this issue for now and hope it will be fixed in Mio in the future.
Option 2: Fix Mio Ourselves
This would require some work, but we could dedicate a chunk of time to fixing the Windows subsystem of Mio, and try to contribute it back. My guess is this would take a few weeks.
Option 3: Stay With Threads
Since we are UDP based, we only need 3 threads:
- Listener thread
- Thread that processes and multiplexes the packets
- Thread that monitors for timeouts
This has the advantage of being dead simple to code, and is proven to work on all OSes. On the downside, we have to have mutexes or figure out a lockless data structure to manage connection status.
Option 4: Conditional Compilation
We could use Mio for macOS and Linux, and use the Windows OS API directly and switch it to Mio if it ever gets fixed. Windows has async sockets that would work fine and are much simpler to work with than iocp.
Option 5: Remove Mio
We could remove Mio entirely and code using the OS APIs directly. This has the benefit of removing a lot of dependencies and layers of abstraction. The downside is that it is a lot of coding.
Those are the ideas I have. Please put in more if you have some. We just need to get this resolved and move on.