Eric Dumazet <eric.duma...@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?
