Re: Three way TCP handshake : can we avoid the third packet ?

[Eric Dumazet <dada1@cosmosbay.com>]

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
>>
>>
> 
>