apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Nicholls <gr...@bellsouth.net>
Subject Re: [PATCH] APR Socket IOL
Date Fri, 09 Nov 2001 17:47:31 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
code down into the APR layer. 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 ....

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
> > > > 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
> ears but I don;t see it yet.
> On Windows, I have a kernel resident HTTP GET engine that can serve static content out
> 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
> 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
> 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
> 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

View raw message