apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: apr_socket_opt_set always sets TCP_DEFER_ACCEPT to 1
Date Tue, 22 Apr 2014 12:53:02 GMT
On Mon, Apr 21, 2014 at 1:17 PM, Brian J. France <brian@brianfrance.com>wrote:

> Just ran into a issue where httpd can only set TCP_DEFER_ACCEPT to 1.
> apr_socket_opt_set will always set the option value to either 0/1, so even
> adding a directive in httpd to allow tweaking the value it can't get it to
> the raw setsockopt call via apr functions.
> Right now we rebuilt our own version of apr with a default of 60, but want
> to work on getting a patch to allow getting a httpd directive.
> Thoughts on how what to tweak in apr?  Different apr_socket_opt_set type
> function for TCP_DEFER_ACCEPT?
> Brian

apr_socket_opt_set() can theoretically handle non-flag values; see

Here's my suggestion:

* Fix the API (code+doc) in APR trunk (future 2.x) to respect the exact
value of the "on" parameter, as with APR_SO_SNDBUF/APR_SO_RCVBUF.
* Applications using APR 1.x that need to set a value other than 1: Use
* If you are so motivated: Add non-default compile flag for APR 1.x that
causes the value passed via apr_socket_opt_set(APR_TCP_DEFER_ACCEPT) to be

We occasionally correct broken/limited API behavior that could conceivably
hurt some unknown piece of code somewhere on a minor version change, but it
seems simple enough for the APR 1.x app to handle directly rather than
prereq a certain APR version just for this minor tweak.


What is the big picture?  My Linux tcp man page says:

TCP_DEFER_ACCEPT (since Linux 2.4)
              Allow a listener to be awakened only when data arrives on the
socket.  Takes an integer value (seconds), this can bound the
              maximum number of attempts TCP will make to complete the
connection.  This option should not be used in code intended to be

I find that very unclear.  "ACCEPT" and "listener...awakened" implies
something with the httpd/kernel interaction, and "complete the connection"
is peer/peer interaction.

What happens if the 1 second timeout set now when setting
APR_TCP_DEFER_ACCEPT via APR expires?  Drop connection without waking up
server?  Wake up server which then has to wait for data?

If it is "drop connection without waking up server" then IMO we need to
really fix APR 1.5.x in the same manner that I suggested for trunk.

If it is "wake up server which then has to wait for data" then I wonder
what you really want.  No data came for 30 or 60 (or whatever) seconds then
the server has to reach its own timeout before we get rid of the
connection?  Why wait so long?  The hard-coded 1 second timeout doesn't
seem so bad here (though in the fullness of time the app should choose the
timeout).  The optimization for normal scenarios is working, and
httpd+kernel both get involved to clean up basket case connections.

Maybe TCP_DEFER_ACCEPT does something else.

I could test and see, but I'm ASSuming that you already know :)  TIA for

Born in Roswell... married an alien...

View raw message