summaryrefslogtreecommitdiff
path: root/sys/src/cmd/vnc/devdraw.c
diff options
context:
space:
mode:
authorcinap_lenrek <cinap_lenrek@felloff.net>2019-01-27 22:12:50 +0100
committercinap_lenrek <cinap_lenrek@felloff.net>2019-01-27 22:12:50 +0100
commit8152e9d075e507d36b6edb48ac1e15082fabeed5 (patch)
treea5b92a4952182a3d21e14bf37d749c8056409cb5 /sys/src/cmd/vnc/devdraw.c
parent63a0d519bcdb02b226023b1c07343bc52791a677 (diff)
devip: tcp: Don't respond to FIN-less ACKs during TIME-WAIT (thanks Barret Rhoden)
Under the normal close sequence, when we receive a FIN|ACK, we enter TIME-WAIT and respond to that LAST-ACK with an ACK. Our TCP stack would send an ACK in response to *any* ACK, which included FIN|ACK but also included regular ACKs. (Or PSH|ACKs, which is what we were actually getting/sending). That was more ACKs than is necessary and results in an endless ACK storm if we were under the simultaneous close sequence. In that scenario, both sides of a connection are in TIME-WAIT. Both sides receive FIN|ACK, and both respond with an ACK. Then both sides receive *those* ACKs, and respond again. This continues until the TIME-WAIT wait period elapses and each side's TCP timers (in the Plan 9 / Akaros case) shut down. The fix for this is to only respond to a FIN|ACK when we are in TIME-WAIT.
Diffstat (limited to 'sys/src/cmd/vnc/devdraw.c')
0 files changed, 0 insertions, 0 deletions