Windows TCP backpressure enhancements #4081
Assignees
Comments
ponylang-main
added
the
discuss during sync
SeanTAllen
added a commit
that referenced
this issue
Nov 19, 2022
Our prior setting of backpressure for TCP writes on Windows was naive. It was based purely on the number of buffers currently outstanding on an IOCP socket. The amount of data didn't matter at all. Whether more data could be accepted or not, also wasn't taken into consideration. This commit greatly improves the situation by only applying backpressure when Windows tells us that it is applying backpressure. No more guessing. Two runtime API methods have been updated on Windows. The Windows version of `pony_os_writev` will now return the number of buffers accepted or zero if backpressure is encountered. All other errors still cause an error that must be handled on the Pony side of the API via a `try` block. The Windows version of `pony_os_send` will now return the number of bytes accepted or zero if backpressure is encountered. All other errors still cause an error that must be handled on the Pony side of the API via a `try` block. I consider these changes non-breaking as previously, the return values from both functions had no meaning. Closes #4081
SeanTAllen
added a commit
that referenced
this issue
Nov 22, 2022
Our prior setting of backpressure for TCP writes on Windows was naive. It was based purely on the number of buffers currently outstanding on an IOCP socket. The amount of data didn't matter at all. Whether more data could be accepted or not, also wasn't taken into consideration. This commit greatly improves the situation by only applying backpressure when Windows tells us that it is applying backpressure. No more guessing. Two runtime API methods have been updated on Windows. The Windows version of `pony_os_writev` will now return the number of buffers accepted or zero if backpressure is encountered. All other errors still cause an error that must be handled on the Pony side of the API via a `try` block. The Windows version of `pony_os_send` will now return the number of bytes accepted or zero if backpressure is encountered. All other errors still cause an error that must be handled on the Pony side of the API via a `try` block. I consider these changes non-breaking as previously, the return values from both functions had no meaning. Closes #4081
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
When I put in the backpressure work in TCPConnection, I knew nothing about IOCP and Windows and as such, it is technically hooked up but may not be very effective or it might be overly effective. This issue is going to collect improvements that could be made:
pony_os_writev
For writing, in
writevandwrite_finalinTCPConnectionthe Windows,pony_os_writevis called. Currently on Windows, it always returns 0. However,pony_os_writevcallsWSASendwhich handles all errors that aren'tWSA_IO_PENDINGas a fatal error and shuts down. I believe thatWSAEWOULDBLOCKshould be handled differently and if it is encountered, that is our signal to trigger backpressure more than_pending_sentlength.Moving away from
_pending_sentwould mean that we want to improve the logic in_complete_sentto not making release backpressure purely based on_pending_sentsize.pony_os_send
Also uses
WSASendin the same way aspony_os_writevbut it isn't called by anything in the standard library or runtime. We can improve the windows interface to indicate backpressure and document it.iocp_send_to
iocp_send_tousesWSASendTofor datagrams which could also be told there is backpressure and could be adjusted as could its callers, however, we currently have no backpressure in the UDPsystem on POSIX either so this could reasonably be skipped for now and done as part of "backpressure for UDP" which... well, I'm not sure what that would look like. I've never considered backpressure for UDP.The text was updated successfully, but these errors were encountered: