Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Tue, 2 Jan 2001 09:29:38 -0800 (PST)
From: dean gaudet <dgaudet-list-new-httpd@arctic.org>
To: <new-httpd@apache.org>
Subject: Re: application level accept() filter for 1.3.x
In-Reply-To: <3A4FED08.C2F0A9CC@cnds.jhu.edu>
Message-ID: <Pine.LNX.4.30.0101020925020.26920-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

i didn't read your patch i was just commenting on your comment that linux
didn't have accept filtering :)

an HTTP session goes like this:

client -> server:  SYN
server -> client:  SYN|ACK
client -> server:  SYN|ACK
   accept() succeeds here
client -> server:  data
   read() succeeds here

with the TCP_DEFER_ACCEPT and the "dataready" kernel filters, the
accept() is deferred until after that 4th packet is received.  as far
as i understand your patch, it defers passing the accepted socket to a
heavyweight httpd child until that 4th packet appears as well.

when i referred to "first packet" i actually meant that 4th packet... the
first packet of actual data transfer.  the first 3 are handshakes you
can't do much about.  (TTCP which lets data go in the first packet is not
secure / not useable on an open network.)

-dean

On Sun, 31 Dec 2000, Theo E. Schlossnagle wrote:

> I saw this...  I think this is great, though I haven't tested how well it work
> -- we don't run 2.4 anywhere yet.  As for comparing an application filter and
> a kernel filter, I don't see how an app filter (my patches specifically) won't
> perform as well.
>
> I don't do anything but a select on the accepted socket to see if there is
> data ready.  So it serves the same purpose but it doesn't live in the kernel,
> so it induces more context switching.  A kernel level filter, assuming it is
> written correctly, should beat the pants off my "parental accept" patch.
>
> MSIE and netscape can't send the data in the first packet right?  You have to
> send a few packets to establish the session first.  The problem is latency (of
> a modem or shotty network connection) between the establishment and that first
> data packet.
>
> Am I losing my mind?  I have seen this sort of thing frequently across very
> high traffic sites.
>
> With that said, if you are having lulls between connect() and read() on the
> server side and you OS doesn't support accept filtering.  The "parental
> accept" patch should solve the problem.
>
> dean gaudet wrote:
> > as of linux 2.4 there is a TCP_DEFER_ACCEPT option which behaves like
> > freebsd's "dataready" filter.
> >
> > i'd actually be curious to know how much the "http" filter actually gains
> > over just plain dataready... given that MSIE always sends the headers in
> > the first packet; and so does netscape unless its POSTing.  (netscape
> > splits the headers before the Content-Length/post body.)
>
> --
> Theo Schlossnagle
> 1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E  2DC2 72C2 AD05 A8EB CF8F
> 2047R/33131B65/71 F7 95 64 49 76 5D BA  3D 90 B9 9F BE 27 24 E7
>