Reset streams after a timeout/Ctrl+C

[matttbe]

To me, if the goal is to measure the transfer during a certain time (vs. a fixed amount of bytes), it feels like the different streams should get reset to stop transferring as quickly as possible.

With the current way of waiting a bit to drain the different streams, it feels like it will be tricky to find a good timeout for that, plus retransmissions done on packets from the end of the queue might impact the results. I'm probably missing some downsides, but I think the default mode should force a reset of the different streams.

(But it might be good to keep it, if easy, for those who are interested in measuring the end of connections, or if it is planned to add a new option to send a certain amount of bytes instead of sending as much as possible until a timeout is reached.)

[lance0]

If you could take a look @ that PR if you get some spare time @matttbe that would be great!

[lance0]

Hey @matttbe — apologies for all the noise on the PR, had a bunch of kinks to work out. Here's where it landed:

Core fix (what you suggested): SO_LINGER=0 on Linux send paths. stream.shutdown().await was the real blocker — it was waiting for the bufferbloated send queue to ACK through the rate-limited path before returning, easily exceeding the 2s join timeout.

Accuracy correction: Paired with tcpi_bytes_acked clamping on stats.bytes_sent before close, so download/bidir tests don't overreport bytes that got discarded by the RST. Turned out the old behavior had a quiet ~5-10% overcount on bufferbloated links; this catches it.

Kept: 200ms receive-side drain (covers the WAN cancel race where the peer sees RST before its own cancel_tx fires). macOS falls back to graceful shutdown() since it lacks tcpi_bytes_acked.

No rush on a retest, but would appreciate one whenever you have a chance. I'll hold off cutting v0.9.8 until you give the thumbs up. Thanks again for the diagnosis and for pointing us directly at the fix.

[lance0]

Released in v0.9.8 — cargo install xfr or brew install lance0/tap/xfr to grab it. Whenever you have a chance to verify against your MPTCP + tc setup, would love to hear it. If anything's still off, happy to iterate.