On 6/5/20 7:57 AM, Christoph Paasch wrote:
> On Thu, Jun 4, 2020 at 6:28 PM Eric Dumazet <eric.duma...@gmail.com> wrote:
>>
>>
>>
>> On 6/4/20 4:18 PM, Christoph Paasch wrote:
>>> +Eric & Leif
>>>
>>> Hello,
>>>
>>>
>>> (digging out an old thread ... ;-) )
>>>
>>
>> Is there a tldr; ?
>
> Sure! TCP_DEFER_ACCEPT delays the creation of the socket until data
> has been sent by the client *or* the specified time has expired upon
> which a last SYN/ACK is sent and if the client replies with an ACK the
> socket will be created and presented to the accept()-call. In the
> latter case it means that the app gets a socket that does not have any
> data to be read - which goes against the intention of TCP_DEFER_ACCEPT
> (man-page says: "Allow a listener to be awakened only when data
> arrives on the socket.").
>
> In the original thread the proposal was to kill the connection with a
> TCP-RST when the specified timeout expired (after the final SYN/ACK).
>
> Thus, my question in my first email whether there is a specific reason
> to not do this.
>
> API-breakage does not seem to me to be a concern here. Apps that are
> setting DEFER_ACCEPT probably would not expect to get a socket that
> does not have data to read.
Thanks for the summary ;)
I disagree.
A server might have two modes :
1) A fast path, expecting data from user in a small amount of time, from peers
not too far away.
2) A slow path, for clients far away. Server can implement strategies to
control number of sockets
that have been accepted() but not yet active (no data yet received).
I have attended many conferences with bad wifi networks to pretend that 3WHS +
headers can always
be completed in X seconds.
>
>
> Thanks,
> Christoph
>
