Closed xzippyzachx closed 7 months ago
The recently added connection metrics (4d9f259019a818ea363319e4955457b795aa7eb0) will help with monitoring bandwidth usage, so I'm not sure how necessary something like this still is.
That being said, the Socket.Poll
method (in SelectWrite
mode) could probably be used to determine if the send buffer is full/overflowing because if it is then I think it would return false. However, this wouldn't work for receiving (SelectRead
mode) as it will return true if there is available data and false if there isn't, but that says nothing about whether or not the receive buffer is anywhere near full/overflowing.
Perhaps checking Socket.Available
would be able to address that, but how important do you think something like this really is? If you compare the connection metrics with the socket's buffer sizes it should be relatively easy to ensure that you're not sending too much data too quickly, right? 🤔
We agreed that this feature is low priority and is most likely no longer needed since the new connection metrics (https://github.com/RiptideNetworking/Riptide/commit/4d9f259019a818ea363319e4955457b795aa7eb0) should be sufficient enough to monitor and warn of socket buffers overflowing.
It may be worth seeing if we can check how full a socket buffer is so we can possibly send warnings if the buffers are overflowing. This would help when debugging issues related to large bandwidth usage.