* Re: Three way TCP handshake : can we avoid the third packet ?
2004-10-12 8:15 ` Three way TCP handshake : can we avoid the third packet ? Eric Dumazet
@ 2004-10-12 8:38 ` Eric Dumazet
2004-10-12 8:41 ` Henrik Nordstrom
1 sibling, 0 replies; 4+ messages in thread
From: Eric Dumazet @ 2004-10-12 8:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Henrik Nordstrom
Well... I discovered I can use this trick, with a NODELAY socket :
int defaccept = 1 ;
setsockopt(sockfd, SOL_TCP, TCP_DEFER_ACCEPT, &defaccept, sizeof(int)) ;
connect(sockfd, ...) ;
...
select()/poll()/epoll();
...
send(sockfd);
This way, the third packet (pure ACK) is not sent.
But I suspect this trick could be illegal in next kernel versions ... :(
Eric
Eric Dumazet wrote:
> Following this discussion on netdev, sorry to bother you again :)
>
> Currently, linux cannot easily avoids the third packet (ACK only) of TCP
> handshake, for connections initiated from linux side.
>
> The send(socket, data) is denied (EAGAIN) if the socket is in NODELAY
> mode and socket not yet connected (connect() done , but not in
> ESTABLISHED state).
>
> So basically, a daemon willing to avoid the third packet must use one
> thread for each outgoing pending connection, seting the socket in
> blocking mode and blocking in send()/write() syscall. In my case, I
> would need about 1000 threads :(
>
> Could we just delay (say up to 200ms) the ACK packet the tcp stack sends ?
>
> If the application uses send() or write() a short time after the
> established state is notified, then the ACK could be suppressed.
>
> This way, every application could benefit from this.
>
>
> Thank you
> Eric Dumazet
>
> Eric Dumazet wrote:
>
>> Henrik Nordstrom wrote:
>>
>>> On Tue, 21 Sep 2004, Eric Dumazet wrote:
>>>
>>>> I discovered today that some TCP stacks were able to initiate TCP
>>>> sockets with 2 packets "only".
>>>>
>>>> The third packet (ACK packet) is just delayed and integrated into the
>>>> data packet.
>>>
>>>
>>>
>>>
>>> The TCP standard even allows you to have data in the SYN packet if
>>> you like. There however needs to be an exchange of three packets
>>> before the connection is considered established. The SYN flag is just
>>> like "octet 0" in the data stream of from sending direction. SYN +
>>> data is just that. As having data in the SYN or SYN+ACK packets is
>>> very uncommon not all TCP stacks are prepared to handle this and is
>>> therefore not recommended.
>>>
>>> All should handle a data payload in the ACK packet I think however,
>>> but there may obviously be some odd ones which does not.
>>>
>>>> Is it possible to achieve the same thing with linux 2.4/2.6, for
>>>> connections initiated by us ?
>>>
>>>
>>>
>>>
>>> Looking at the kernel source... seems to be the case if you simply
>>> initiate a non-blocking connect and then queue some data to be sent
>>> on the connection while the connect is taking place. Testing.. yes
>>> this does work.
>>>
>>> set non-blocking
>>> connect
>>> set blocking
>>
>>
>>
>> Thank you for the hint. But the "set blocking" makes me nervous, since
>> I need to be sure not to block at write()/send() time...
>>
>>> write
>>>
>>> Regards
>>> Henrik
>>
>>
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-net" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Three way TCP handshake : can we avoid the third packet ?
2004-10-12 8:15 ` Three way TCP handshake : can we avoid the third packet ? Eric Dumazet
2004-10-12 8:38 ` Eric Dumazet
@ 2004-10-12 8:41 ` Henrik Nordstrom
1 sibling, 0 replies; 4+ messages in thread
From: Henrik Nordstrom @ 2004-10-12 8:41 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
On Tue, 12 Oct 2004, Eric Dumazet wrote:
> Following this discussion on netdev, sorry to bother you again :)
>
> Currently, linux cannot easily avoids the third packet (ACK only) of TCP
> handshake, for connections initiated from linux side.
>
> The send(socket, data) is denied (EAGAIN) if the socket is in NODELAY mode
> and socket not yet connected (connect() done , but not in ESTABLISHED
> state).
This is my observations as well.
> So basically, a daemon willing to avoid the third packet must use one thread
> for each outgoing pending connection, seting the socket in blocking mode and
> blocking in send()/write() syscall. In my case, I would need about 1000
> threads :(
>
> Could we just delay (say up to 200ms) the ACK packet the tcp stack sends ?
What would this do to the initial RTT measurements?
>From what I can see the RFCs only allow for delayed ACKs in response to a
data segment. Not sure if this includes SYN (or FIN).
Regards
Henrik
^ permalink raw reply [flat|nested] 4+ messages in thread