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. 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.
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
