When checking to see if a window update should be sent to the remote peer,
don't force a window update if the window would not actually grow due to window scaling. Specifically, if the window scaling factor is larger than 2 * MSS, then after the local reader has drained 2 * MSS bytes from the socket, a window update can end up advertising the same window. If this happens, the supposed window update actually ends up being a duplicate ACK. This can result in an excessive number of duplicate ACKs when using a higher maximum socket buffer size. Reviewed by: bz MFC after: 1 month
This commit is contained in:
parent
5d253e418f
commit
da84b2e6c5
@ -564,11 +564,19 @@ after_sack_rexmit:
|
||||
long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) -
|
||||
(tp->rcv_adv - tp->rcv_nxt);
|
||||
|
||||
/*
|
||||
* If the new window size ends up being the same as the old
|
||||
* size when it is scaled, then don't force a window update.
|
||||
*/
|
||||
if ((tp->rcv_adv - tp->rcv_nxt) >> tp->rcv_scale ==
|
||||
(adv + tp->rcv_adv - tp->rcv_nxt) >> tp->rcv_scale)
|
||||
goto dontupdate;
|
||||
if (adv >= (long) (2 * tp->t_maxseg))
|
||||
goto send;
|
||||
if (2 * adv >= (long) so->so_rcv.sb_hiwat)
|
||||
goto send;
|
||||
}
|
||||
dontupdate:
|
||||
|
||||
/*
|
||||
* Send if we owe the peer an ACK, RST, SYN, or urgent data. ACKNOW
|
||||
|
Loading…
x
Reference in New Issue
Block a user