On Friday 09 November 2001 06:07 am, Bill Stoddard wrote: > > > 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. > > 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.
Bill, I do understand what you are looking for. Remember, I did do a little bit of work that has involved looking at the kernel cache before. Here is what I am saying, there are two ways to do this: 1) Make APR a wrapper around a bunch of different socket backends. This has the same problem as the DB backend issue and the lock backend issue. Namely, it is going to be next to impossible to do cleanly. It also introduces a bunch of logic that is really Apache specific. In fact, this isn't even Apache specific, there are a couple of modules that want this. 2) Use an Apache module to implement this, using filters and hooks. Option 2 will require investigating all of the places that we make socket calls in Apache. Core: Lingering close New connection This could probably move to later in the code get_remote_host get_server_name make_sock (only used if ap_listen_open created the socket) close_listeners_on_exec (only used if ap_listen_open created the socket) find_default_family (only used in ap_set_listener : Listen directive) alloc_listener (only used in ap_set_listener : Listen directive) disable_nagle (only used if ap_listen_open created the socket) pod_signal (client side) rfc1413.c (client side) add_common_vars check_hostalias check_serverpath MPM: accept accept error conditions A more exhaustive analysis might be good too, but the reality is that most of these calls are grouped into a few very small locations in the code. A lot of them could move all the way down to the core_output_filter, or possibly to the very first filter in the stack, which would always correspond to the lowest filter. The only really hard one is the accept stuff. That could be done with a simple hook. To ensure that the core never calls a regular socket operation on your socket, you would put your socket in a module's configuration structure. Ryan ______________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
