Hello, On Sun, Jun 7, 2020 at 3:00 AM Florian Westphal <f...@strlen.de> wrote: > > 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).
to add to that: There are indeed scenarios where TCP-SYN/... without payload go through fine but as soon as the packet-size increases WiFi/Cell has problems because of smaller grants given by the AP/tower. But even those connections should be able to get the data through within a "reasonable" timeframe. Anything beyond that timeframe will anyways have such a bad user-experience that it is pointless to continue. So, a use-case here would be where the user is in such a slow network and a TCP-split proxy is deployed (such proxies are very common in cellular networks). That proxy will be ACKing the server's SYN/ACK retransmission at the end of the defer-accept period, while the client is still trying very hard to get the data through to the proxy (or even, the client might have gone totally out-of-service). For those kinds of scenarios it would make sense to have a different DEFER_ACCEPT-behavior (maybe with a separate socket-option as Florian suggested). Christoph > > So we can't change DEFER_ACCEPT behaviour. > Any objections to adding TCP_DEFER_ACCEPT2 with the behaviour outlined > by Christoph?
