mirror of
https://github.com/KumoCorp/kumomta.git
synced 2026-09-07 08:00:56 +00:00
Wez Furlong
b5596183be
We've been trying to run down an issue where a user has reported that some sessions that are running via the proxy seem to hang waiting for a response from the peer. The common theme is that the size of the payload is approximately 1MB in size, and that the proxy is in use. I haven't been able to get it to reproduce at all, but in looking carefully at the code here, my splice(2) implementation used a pipe buffer that was 1MB in size, and doing non-blocking IO outside of tokio's internals is a bit of a black art, so I'd buy the theory that we might be getting stuck somewhere if we did fill up that pipe buffer. Since I couldn't catch it in the act, I've opted to go for the simple and safer route here, as a speculative remediation: * Added a `--no-splice` command line parameter to opt out of using `splice(2)` completely on Linux so that we can rule out weirdness with splice completely. The result will have lower theoretical max throughput, but a simpler internal implementation. * There now exists a `tokio-splice` crate that has the same functionality as my own splice_copy code does, but a different implementation. Adopt that for the `splice(2)` mode. * Switch away from splitting the stream into read/write halves: there are now utility functions available in tokio and tokio_splice that don't require splitting the streams, which further simplifies the implementation.