lkml.org 
[lkml]   [2000]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: TCP_DEFER_ACCEPT possible bug + documentation patch for tcp.7
On Sun, Oct 22, 2000 at 04:25:39PM +0400, kuznet@ms2.inr.ac.ru wrote:

> Until actively connecting client will send some data,
> service will and must retransmit syn-ack. Otherwise you will lose connection.

I don't see why. This is a trace with my patch applied, can you tell me
what's wrong with it?

$ telnet 0 2500
27.253640 l.1192 > l.2500: S 1201711948:1201711948(0) win 32280 <mss 16152,sackOK,timestamp 142864 0,nop,wscale 0> (DF) [tos 0x10]
27.253756 l.2500 > l.1192: S 1189762934:1189762934(0) ack 1201711949 win 32280 <mss 16152,sackOK,timestamp 142864 142864,nop,wscale 0> (DF)
27.253825 l.1192 > l.2500: . ack 1 win 32280 <nop,nop,timestamp 142864 142864> (DF) [tos 0x10]
Connection established, and I send no data

After half a minute, I send 'quit':
08.195229 l.1192 > l.2500: P 1:7(6) ack 1 win 32280 <nop,nop,timestamp 146959 142864> (DF) [tos 0x10]
08.195383 l.2500 > l.1192: . ack 7 win 32274 <nop,nop,timestamp 146959 146959> (DF)
08.350985 l.2500 > l.1192: P 1:39(38) ack 7 win 32274 <nop,nop,timestamp 146974 146959> (DF)
08.351032 l.1192 > l.2500: . ack 39 win 32242 <nop,nop,timestamp 146974 146974> (DF) [tos 0x10]
08.376599 l.2500 > l.1192: P 39:82(43) ack 7 win 32274 <nop,nop,timestamp 146977 146974> (DF)
08.376644 l.1192 > l.2500: . ack 82 win 32199 <nop,nop,timestamp 146977 146977> (DF) [tos 0x10]
08.379948 l.2500 > l.1192: F 82:82(0) ack 7 win 32274 <nop,nop,timestamp 146977 146977> (DF)
08.380253 l.1192 > l.2500: F 7:7(0) ack 83 win 32696 <nop,nop,timestamp 146977 146977> (DF) [tos 0x10]
08.380312 l.2500 > l.1192: . ack 8 win 32274 <nop,nop,timestamp 146977 146977> (DF)
Connection is gone.

This looks exactly correct to me. I don't see why we'd need repeated SYNACKs
between establishment of the connection and the arrival of the first data
packet. Why would we lose the connection?

> DEFER_ACCEPT (like data_ready filter) applies only
> to sessions, which expect some data from client as beginning
> of transaction. F.e. HTTP.

Of course, but I see no reason to send spurious SYNACKs which have clearly
been ACKed.

I am but a humble amateur in TCP/IP matters, so please explain your
reasoning.

Regards,

bert hubert

--
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.051 / U:4.324 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site