httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Theo E. Schlossnagle" <je...@cnds.jhu.edu>
Subject Re: application level accept() filter for 1.3.x
Date Mon, 01 Jan 2001 02:35:52 GMT
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

Mime
View raw message