apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: [RFC] Network Abstraction Layer - redux
Date Wed, 13 Jun 2001 14:28:51 GMT

> On Tue, 12 Jun 2001, William A. Rowe, Jr. wrote:
>
> > From: <rbb@covalent.net>
> > Sent: Tuesday, June 12, 2001 10:41 PM
> >
> >
> > > I was under the impression that we had already decided, the last time this
> > > thread surfaced, that all of this was possible with filters.  We can
> > > redirect to different kinds of network primitives with a different "core"
> > > filter.  The "core" filters don't even need to use sockets, they can store
> > > their own communication medium in the conn_rec, and just use that.  The
> > > only drawback, is that Apache will still require a single socket to
> > > operate, but I am not sure that can't be worked around.  A REALLY QUICK
> > > grep through the source has us referencing the client socket 28 times
> > > directly from the conn_rec.  I am not convinced that some of those can't
> > > just be moved to inside a filter.
> > >
> > > I guess I am asking what this is supposed to accomplish.
> >
> > In all fairness,
> >
> > APR does bucket brigades.  It does socket management.  I think this would be a fine
> > addition to our APR arsenal.
> >
> > But can we, absolutely, postively, table any change that affects an httpd 2.0
> > release?  IOW, no samba-team iol into Apache 2.0.  Develop the API, impement the
> > code, go to town.  But I think we've reached a juncture...
> >
> >     not everything in apr exists for or is even used by Apache
> >
> > If what results can improve httpd 2.1, then fantastic!  If not, it's still fantastic
:-)
> > There's alot more to do on the net beyond Apache, if we can fuel those directions,
then
> > we really have a worthwhile library project, and not just an adjunct of httpd.
>
> The problem I have with this code idea isn't that it isn't useful to
> httpd.  It is that we have been down this road once, and the model wasn't
> flexible enough.  What problem are we trying to solve that the filter
> mechanism doesn't solve?  If the answer to that question is "filters are
> in Apache, and we want this out of Apache", then move filters out of
> Apache.

No way man :-)

> If the answer is, "We need a better way to abstract the network
> for x, y, and z", then cool let's do it.

I would argue that we do not have a good (read architecturally clean) way to abstract
network io with filters. The NAL is a perfect compliment to the filter code. Here are my
specific itches:

1.  My SSL library API uses a different model than OpenSSL. Specifically, it uses uses
secure_socket calls (e.g., secure_read(), secure_write(), etc.).  I -could- integrate SSL
into Apache 2.0 using filters, but I would have to replace core_inout_filter and
core_output_filter with my own filters, possibly implement special bucket types
(apr_bucket_secure_socket_t, etc.)  With NAL, I can just hook the network io primitives
with my own calls and use the filters already in Apache. I hope to use OpenSSL but that is
just not a possibility now. My itch is real to me even if you don;t feel it :-)

2. I gave a pitch about IBM's Fast Response Cache Accelerator (aka AFPA) at ApacheCon a
few years back. The AFPA implementation on Windows uses it's own socket API (afpa_read,
afpa_accept, afpa_send, et. al.).  Again, the NAL provides a clean way for my Apache
module to hook the right NAL implementing my specific network io primitives with the
minimum amount of shuffleing httpd code.

Can I do both of these with filters? Sure, but the code architecturally ugly as sin.
Allan Edwards solved both of these problems cleanly in early Apache 2.0 iterations using
Dean Gaudet's IOLs. NAL is essentially a scaled back version of Dean's IOLs (NAL is
focused just on network i/o, not filtering). And I know what Luke is talking about as
well.  Windows NT does implement filters (AFPA uses file system filters) in addition to a
network io abstraction layer.  NAL is a great compliment to filters.

Bill


Mime
View raw message