Back out a change made some time ago, that would cause the NetBSD TCP
to ACK immediately any packet that arrived with PSH set. This breaks delayed ACKs in a few specific common cases that delayed ACKs were supposed to help, and ends up not making much (if any) difference in the case where where this ACK-on-PSH change was supposed to help. Per discussion with several members of the TCPIMPL and TCPSAT IETF working groups.
This commit is contained in:
parent
2da6c91259
commit
1b176d9395
|
@ -1,4 +1,4 @@
|
|||
/* $NetBSD: tcp_input.c,v 1.46 1998/03/31 22:49:09 thorpej Exp $ */
|
||||
/* $NetBSD: tcp_input.c,v 1.47 1998/03/31 23:44:09 thorpej Exp $ */
|
||||
|
||||
/*-
|
||||
* Copyright (c) 1997, 1998 The NetBSD Foundation, Inc.
|
||||
|
@ -149,13 +149,11 @@ extern u_long sb_max;
|
|||
|
||||
/*
|
||||
* Macro to compute ACK transmission behavior. Delay the ACK unless
|
||||
* the other side PUSH'd or we have already delayed an ACK (must send
|
||||
* an ACK every two segments).
|
||||
* we have already delayed an ACK (must send an ACK every two segments).
|
||||
*/
|
||||
#define TCP_SETUP_ACK(tp, ti) \
|
||||
do { \
|
||||
if ((ti)->ti_flags & TH_PUSH || \
|
||||
(tp)->t_flags & TF_DELACK) \
|
||||
if ((tp)->t_flags & TF_DELACK) \
|
||||
tp->t_flags |= TF_ACKNOW; \
|
||||
else \
|
||||
TCP_SET_DELACK(tp); \
|
||||
|
|
Loading…
Reference in New Issue