This addresses the issues discussed in #66 by adding a 16ms delay between fragmented data packets. This value was chosen as 16ms is roughly equivalent to 1/60th of a second which is the refresh rate of many games. The intention was that if the networking code in the games is polling at that frequency we'd keep in sync with them, not overflowing the client's internal buffer.
I did try other values for this, going as low as 7ms and as high as 32ms but decided against it because:
For longer delays, the overall times to send the packets were increased
For shorter delays, occasionally packets were overflowing the queue resulting in the packet loss we want to avoid
There is potentially more that we could do here to make this smarter, but this drastically improves performance for large responses to the client. In the example update_and_get_all_information call with 100 friends. This speed up the response from 18 seconds to 2 seconds.
jonbarrow
commented
5 months ago
Resolves #66
Changes:
This addresses the issues discussed in #66 by adding a 16ms delay between fragmented data packets. This value was chosen as 16ms is roughly equivalent to 1/60th of a second which is the refresh rate of many games. The intention was that if the networking code in the games is polling at that frequency we'd keep in sync with them, not overflowing the client's internal buffer.
I did try other values for this, going as low as 7ms and as high as 32ms but decided against it because:
There is potentially more that we could do here to make this smarter, but this drastically improves performance for large responses to the client. In the example
update_and_get_all_informationcall with 100 friends. This speed up the response from 18 seconds to 2 seconds.