On Sun, 8 Jul 2001, Brian Pane wrote:
> So I guess the ideal algorithm for retrieving the initial request
> from a client is:
>
> OS with working TCP_DEFER_ACCEPT or equivalent: select first, then read
> OS without working TCP_DEFER_ACCEPT or equivalent: read first
isn't it the other way around?
if TCP_DEFER_ACCEPT exists, then you don't get an accept() event until the
first data packet has arrived -- so you can (should) assume that a read()
will succeed.
if TCP_DEFER_ACCEPT doesn't exist, then you're probably (as long as modem
users still exist) going to get EAGAIN on the first read(). but i dunno.
maybe someone wants to hack up a production server with some debugging
code to measure if this happens?
maybe you were right to begin with and i should just set
APR_INCOMPLETE_READ by default so we always try read() first :)
> It's probably worth the complexity to support TCP_DEFER_ACCEPT on
> platforms where it's available. My rationale for this is that if
> some idiot decides to open a thousand connections to your httpd and
> never send anything, it's more lightweight to buffer each one in
> a node in a kernel list while awaiting a timeout than to buffer it
> in a connection_rec in the httpd.
oh yeah it's definitely a win. i'm just not sure what the APR API should
be given that freebsd and linux's implementations differ so much. it
should also be a run time config option.
-dean
