> On Thursday 08 November 2001 03:53 pm, Roy T. Fielding 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. > > Yeah, that is another way to do this. Either way, this is the correct way to > replace the underlying network code. > > Ryan
I don't grok what either of you (Roy or Ryan) is saying. I have an socket-like API. I need to issue my_accept(), my_setsockopt(), my_recv(), my_send(), my_sendfile(), et. al. These calls are scattered all across httpd. Are you saying I need an accept() filter, a recv() filter, et. al? Or that there needs to be a set of generic filter APIs created specific to manipulating network options? And that each filter should grok these APIs and pass them down all the way to the network layer? I have to solve this problem one way or the other. I would prefer to do it open source because the idea seems generally useful. Bill
