Re: TCP_DEFER_ACCEPT wakes up without data

[Florian Westphal <fw@strlen.de>]

Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > 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).

So we can't change DEFER_ACCEPT behaviour.
Any objections to adding TCP_DEFER_ACCEPT2 with the behaviour outlined
by Christoph?