diff options
author | Stefano Brivio <sbrivio@redhat.com> | 2025-02-11 20:19:05 +0100 |
---|---|---|
committer | Stefano Brivio <sbrivio@redhat.com> | 2025-02-12 19:43:55 +0100 |
commit | 90f91fe72673e36c8e071a1750e9c03deb20ab0f (patch) | |
tree | 03a2b15e048a50b3cc6d9bbee18c6dc10c0156cc /vu_common.c | |
parent | 472e2e930f6e17d9d8664d6cf44c47af1db58bb3 (diff) | |
download | passt-90f91fe72673e36c8e071a1750e9c03deb20ab0f.tar passt-90f91fe72673e36c8e071a1750e9c03deb20ab0f.tar.gz passt-90f91fe72673e36c8e071a1750e9c03deb20ab0f.tar.bz2 passt-90f91fe72673e36c8e071a1750e9c03deb20ab0f.tar.lz passt-90f91fe72673e36c8e071a1750e9c03deb20ab0f.tar.xz passt-90f91fe72673e36c8e071a1750e9c03deb20ab0f.tar.zst passt-90f91fe72673e36c8e071a1750e9c03deb20ab0f.zip |
tcp: Implement conservative zero-window probe on ACK timeout
This probably doesn't cover all the cases where we should send a
zero-window probe, but it's rather unobtrusive and obvious, so start
from here, also because I just observed this case (without the fix
from the previous patch, to take into account window information from
keep-alive segments).
If we hit the ACK timeout, and try re-sending data from the socket,
if the window is zero, we'll just fail again, go back to the timer,
and so on, until we hit the maximum number of re-transmissions and
reset the connection.
Don't do that: forcibly try to send something by implementing the
equivalent of a zero-window probe in this case.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'vu_common.c')
0 files changed, 0 insertions, 0 deletions