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 17:12:16 GMT
> > > 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 :-)
>
> Why not?

"No way man" is my answer to your question about possibly removing filters from Apache.
Filters are good. :-)

>
> > > 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 :-)
>
> I'm not saying your itch isn't real, I'm saying I disagree with how you
> want to scratch 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.
>
> I'm saying that the code doesn't need to be architecturally ugly.  The
> problem, is that our core filters are big and do too much, IMNSHO.  Break
> out the core filters to smaller chunks that are available to other
> filters, and I believe this will solve your problem completely.
>

I think you are saying that you believe it is possible to make the 'last filter'
(currently the core_[input|output]_filter) a very thin filter whose primary purpose is to
do network io; either via an apr_network_io interface, or via a custom interface? Is that
about right?   If so, I think that has some problems (perhaps solvable in a clean way).

First problem is with where the network abstraction occurs. In the NAL, the abstraction is
at the lowest possible level, at the core network io primitive level.  With your solution,
the abstraction occurs at the apr_network_io level. This means that my primitives will
have to reimplement a lot of the buffering/locking/whatever code that is currently
implemented in the apr_network_io code.  Custom network io primitives must be semantically
identical to the network io primitives they are replacing. It is much easier to do this at
the socket level than at the apr_network_io level.

Second, not all the network i/o we do is in the core filters.  MPMs do network operations
(accept, lingering close, etc.).

Third, all the network io is done via apr_socket_t structs which are created in the MPMs
and propogated to other parts of Apache.  By definition, I am not interested in dealing
with apr_socket_t structs (slightly modfied apr_socket_t structs maybe).  How do we handle
each place in the Apache code where we frob (look at, call an API with, whatever) an
apr_socket_t and expect a real 'socket'?  Where do I store my custom structure I use for
networkio? I would like to be able to use the apr_socket_t structure and tweak it slightly
for my custom calls, but that structure is opaque to Apache.

Bill




Mime
View raw message