httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <dgaudet-list-new-ht...@arctic.org>
Subject Re: Extraneous socket read?
Date Tue, 10 Jul 2001 08:04:49 GMT


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


Mime
View raw message