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