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