apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: [PATCH] APR Socket IOL
Date Fri, 09 Nov 2001 16:04:22 GMT

>     Just to add my (inflation-adjusted) 2 cents worth.
> I may be way off on this but it sounds like you're attempting to move the complexity
from your
> code down into the APR layer.

Well, yea. That is the whole story behind APR. Some folks in the Apache httpd project
think APR is a bad idea because it introduces excessive complexity. From their
perspactive, POSIX is a perfectly acceptable API and if an OS doesn't support POSIX then
Apache shouldn't bother running on that OS :-)

> I know that you can sometimes avoid a huge mess by making a
> small change in a lower layer of code however I'd question whether modifying a
general-purpose
> library for what seems to be a highly specific one off problem is a good idea. Sometimes
you
> just have to bite the bullet and duplicate-munge your code ....
>         G.

Yes, I completely understand and have the same concern. Thought I'd offer up a patch in
case there was common interest. If not, then I understand and will patch my copy of APR to
do what I need.

I am still interested in Roy and Ryan's assertion that this can be solved with filters.  I
don't see how this problem can be fixed with filters.

Bill

>
> Bill Stoddard wrote:
>
> > > > > What you are suggesting will not work at all. There are apr_socket(and
> > > > > related) calls in places other than the core_*_filters. And it is
not safe
> > > > > to make these calls (which will call BSD socket network io system
calls)
> > > > > using descriptors from a different network interface.
> > > >
> > > > Then I would consider the filtering logic broken.  If you can't replace
the
> > > > underlying network types, then we need to move all of the network calls
in
> > > > the core into new hooks, that can be bypassed if a different network mechanism
> > > > is required.
> > >
> > > Not really.  It just means that the network options being set on the sockets
> > > directly today should instead be set (in an abstract sense) on the top of
> > > the filter chain, which would propagate them down to the filter that is
> > > IO-specific.  In reality, there are only a couple types of filters that
> > > would ever have a legitimate reason to set socket options, and they are
> > > very close to the IO-specific filter in the chain.
> > >
> > > ....Roy
> >
> > Not sure you guys understand exactly why I think I need socket iol, so I'll try
to
explain
> > it in more detail. If there is a better, more extensible way to solve my problem,
I am
all
> > ears but I don;t see it yet.
> >
> > On Windows, I have a kernel resident HTTP GET engine that can serve static content
out
of
> > a cache very quickly. The cache is dynamically loaded by httpd as the server runs.
> >
> > httpd communicates with this cache via a custom API. This API consists of a cache
> > management API (put stuff into the cache, take stuff out of the cache, refresh the
cache,
> > etc.), an API to enable starting/stopping/restarting the cache engine, and a socket
like
> > network API for httpd to do io with the cache. It is the network API that is driving
my
> > desire for socket iols in APR.
> >
> > For reasons I don't want to delve into, we decided to implement a socket like API
for
> > httpd to do network io with/through the kernel resident cache. This API is for most
> > purposes symantically identical to the BSD socket API -for handling inbound
connections-.
> > It implements open(), close(), accept(), read(), write(), setopt(), etc. (an aside,
the
> > custom socket layer communicates with the Windows TCP/IP stack via the TDI interface
in
> > the Windows kernel. TDI documentation is piss poor at best and we had to reverse
engineer
> > the behaviour of many of the TDI calls which were documented incorrectly. I would
never
> > recommend anyone do TDI programming.)
> >
> > Consider the normal simple case of starting httpd listening on port 80. If the cache
is
> > enabled, the cache engine is started when httpd is started.  httpd tells the cache
engine
> > what address/port to listen for requests on (the cache engine actually listens on
the
> > port/ip address).  httpd uses it's custom socket API to handle requests 'punted'
to
httpd
> > from the cache engine (cache misses).
> >
> > The cache engine does not support SSL. So if SSL is also enabled in addition to
standard
> > port 80, httpd needs to listen for port 443 traffic using the standard socket APIs
(On
> > windows, we use seperate thread to listen on each port so there is no issue of doing
> > select on the two different style of socket descriptors).
> >
> > Hope this helps explain what I am looking for.
> >
> > Bill
>
>


Mime
View raw message