summaryrefslogtreecommitdiffstats
path: root/net/atm/br2684.c
diff options
context:
space:
mode:
authorJulian Anastasov <ja@ssi.bg>2009-10-19 10:01:56 +0000
committerDavid S. Miller <davem@davemloft.net>2009-10-19 19:19:01 -0700
commitd1b99ba41d6c5aa1ed2fc634323449dd656899e9 (patch)
tree06c2106cda7c565c08da8d510612d2c805fc3c33 /net/atm/br2684.c
parenta1a2ad9151c26d92e5c733a33d52108f5d3a5b57 (diff)
tcp: accept socket after TCP_DEFER_ACCEPT period
Willy Tarreau and many other folks in recent years were concerned what happens when the TCP_DEFER_ACCEPT period expires for clients which sent ACK packet. They prefer clients that actively resend ACK on our SYN-ACK retransmissions to be converted from open requests to sockets and queued to the listener for accepting after the deferring period is finished. Then application server can decide to wait longer for data or to properly terminate the connection with FIN if read() returns EAGAIN which is an indication for accepting after the deferring period. This change still can have side effects for applications that expect always to see data on the accepted socket. Others can be prepared to work in both modes (with or without TCP_DEFER_ACCEPT period) and their data processing can ignore the read=EAGAIN notification and to allocate resources for clients which proved to have no data to send during the deferring period. OTOH, servers that use TCP_DEFER_ACCEPT=1 as flag (not as a timeout) to wait for data will notice clients that didn't send data for 3 seconds but that still resend ACKs. Thanks to Willy Tarreau for the initial idea and to Eric Dumazet for the review and testing the change. Signed-off-by: Julian Anastasov <ja@ssi.bg> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/atm/br2684.c')
0 files changed, 0 insertions, 0 deletions