lkml.org 
[lkml]   [2000]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectTCP_DEFER_ACCEPT possible bug + documentation patch for tcp.7
On Sat, Oct 21, 2000 at 08:50:54AM +0200, Andi Kleen wrote:

> Linux 2.4 has the "dataready" filter in form of the (currently undocumented)
> TCP_DEFER_ACCEPT option.

Patch follows beneath. On a related note, I'm not sure if this is right
(connecting to a daemon using TCP_DEFER_ACCEPT)

# tcpdump -i lo &
$ telnet 0 2500
20:46:04.646941 localhost.2030 > localhost.2500: S 2082276900:2082276900(0) win 32280 <mss 16152,sackOK,timestamp 3147004 3144088,nop,wscale 0> (DF) [tos 0x10]
20:46:04.647053 localhost.2500 > localhost.2030: S 2083048556:2083048556(0) ack 2082276901 win 32280 <mss 16152,sackOK,timestamp 3147004 3147004,nop,wscale 0> (DF)
20:46:04.647128 localhost.2030 > localhost.2500: . ack 1 win 32280 <nop,nop,timestamp 3147004 3147004> (DF) [tos 0x10]
Connected to 0.
Escape character is '^]'.
20:46:08.442729 localhost.2500 > localhost.2030: S 2083048556:2083048556(0) ack 2082276901 win 32280 <mss 16152,sackOK,timestamp 3147384 3147004,nop,wscale 0> (DF)
20:46:08.442824 localhost.2030 > localhost.2500: . ack 1 win 32280 <nop,nop,timestamp 3147384 3147004> (DF) [tos 0x10]

20:46:14.842753 localhost.2500 > localhost.2030: S 2083048556:2083048556(0) ack 2082276901 win 32280 <mss 16152,sackOK,timestamp 3148024 3147384,nop,wscale 0> (DF)
20:46:14.842858 localhost.2030 > localhost.2500: . ack 1 win 32280 <nop,nop,timestamp 3148024 3147004> (DF) [tos 0x10]

20:46:27.642750 localhost.2500 > localhost.2030: S 2083048556:2083048556(0) ack 2082276901 win 32280 <mss 16152,sackOK,timestamp 3149304 3148024,nop,wscale 0> (DF)
20:46:27.642856 localhost.2030 > localhost.2500: . ack 1 win 32280 <nop,nop,timestamp 3149304 3147004> (DF) [tos 0x1

20:46:51.642733 localhost.2500 > localhost.2030: S 2083048556:2083048556(0) ack 2082276901 win 32280 <mss 16152,sackOK,timestamp 3151704 3149304,nop,wscale 0> (DF)
20:46:51.642803 localhost.2030 > localhost.2500: . ack 1 win 32280 <nop,nop,timestamp 3151704 3147004> (DF) [tos 0x10]

20:47:39.642730 localhost.2500 > localhost.2030: S 2083048556:2083048556(0) ack 2082276901 win 32280 <mss 16152,sackOK,timestamp 3156504 3151704,nop,wscale 0> (DF)
20:47:39.642805 localhost.2030 > localhost.2500: . ack 1 win 32280 <nop,nop,timestamp 3156504 3147004> (DF) [tos 0x1

The SYN/ACK handshake appears to go well, and telnet reports a connection
(the daemon doesn't, no data has been sent). However, Linux keeps sending
SYNs, which keep getting ACKed. I'm not sure if this is desired behavior. It
appears to be a side effect of the TCP_DEFER_ACCEPT timeout implementation,
which seems to hijack the SYNACK_RESEND timeout.

Also, this timeout is not quite the number of seconds specified to
setsockopt, because of this.

Oh well: the patch

diff -c -r old/tcp.7 new/tcp.7
*** old/tcp.7 Sat Oct 21 20:42:10 2000
--- new/tcp.7 Sat Oct 21 20:41:50 2000
***************
*** 209,214 ****
--- 209,222 ----
.BR sendfile (2),
or for throughput optimization. This option cannot be combined with
.BR TCP_NODELAY .
+ .TP
+ .B TCP_DEFER_ACCEPT
+ Instruct the kernel to do connection preprocessing and not to wake the
+ process until the first packet of real data has arrived. Especially useful
+ for webservers, which needn't pay attention during the time between completion
+ of the TCP handshake and the arrival of the first data packet. The integer value
+ passed is interpreted as the time to wait before the arrival of data before
+ giving up the connection.
.SH IOCTLS
These ioctls can be accessed using
.BR ioctl (2).




--
PowerDNS Versatile DNS Services
Trilab The Technology People
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:0.065 / U:1.684 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site