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 14:07:11 GMT

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