Re: asynch websockets tunnel
On Wed, Jun 12, 2013 at 10:15 AM, Jim Jagielski j...@jagunet.com wrote: re-looking at this, it would be nice if we could abstract out the callback itself as simply some event, where the callback and the baton itself is self-contained enuff to define what the event is... eg register_anevent_callback :) FWIW I need to table this for a while if anyone is interested in continuing/morphing it, i won't have any parallel local changes going on. (beginning a tough stretch at work travel)
Re: asynch websockets tunnel
Anyone opposed if I commit to trunk? On Fri, Jun 14, 2013 at 06:04:36PM -0400, Eric Covener wrote: On Wed, Jun 12, 2013 at 10:15 AM, Jim Jagielski j...@jagunet.com wrote: re-looking at this, it would be nice if we could abstract out the callback itself as simply some event, where the callback and the baton itself is self-contained enuff to define what the event is... eg register_anevent_callback :) FWIW I need to table this for a while if anyone is interested in continuing/morphing it, i won't have any parallel local changes going on. (beginning a tough stretch at work travel) -- === Jim Jagielski [|] j...@jagunet.com [|] http://www.jaguNET.com/ Great is the guilt of an unnecessary war ~ John Adams
Re: asynch websockets tunnel
On 15 Jun 2013, at 12:40 AM, Jim Jagielski j...@jagunet.com wrote: Anyone opposed if I commit to trunk? +1 to commit to trunk, that's where this stuff takes shape :) Regards, Graham --
Re: asynch websockets tunnel
On Fri, Jun 14, 2013 at 7:05 PM, Graham Leggett minf...@sharp.fm wrote: On 15 Jun 2013, at 12:40 AM, Jim Jagielski j...@jagunet.com wrote: Anyone opposed if I commit to trunk? +1 to commit to trunk, that's where this stuff takes shape :) +1
Re: asynch websockets tunnel
I'm a big +1 on Eric folding this into trunk!
Re: asynch websockets tunnel
re-looking at this, it would be nice if we could abstract out the callback itself as simply some event, where the callback and the baton itself is self-contained enuff to define what the event is... eg register_anevent_callback :)
Re: asynch websockets tunnel
On Jun 5, 2013, at 10:45 AM, Eric Covener cove...@gmail.com wrote: On Wed, Jun 5, 2013 at 10:03 AM, Graham Leggett minf...@sharp.fm wrote: On 05 Jun 2013, at 3:00 PM, Eric Covener cove...@gmail.com wrote: I've been playing with this in my sandbox, it adds a socket readable callback to event, similar to the timed callback, which allows mod_proxy_wstunnel to hop on and off the thread like test/mod_dialup. http://people.apache.org/~covener/websocket-asynch-8.diff I was meaning to play around with a similar idea, but you beat me to it. What I had in mind was an API that passed conn_rec structures rather than raw sockets, which could then be processed using the same lifecycle that a server generated conn_rec's pass through (ap_run_process_connection()). Proxy could then pass the conn_rec it uses towards the backend to the core, and then obtain event driven events for ready-to-read and ready-to-write from the frontend and the backend, independently of one another. conn_rec is easy for the proxies, but could limit how other mods can take advantage of the service Yeah, I think conn_rec would make sense if we were a single-threaded server, but considering the hybrid that we are, the real thing we're concerned about are the raw sockets. This also makes more sense with things like SPDY, iirc. I also like the weirdness of the API (socket grouping)... it's more robust. I really, REALLY like this! ++1
Re: asynch websockets tunnel
On 07 Jun 2013, at 2:55 PM, Jim Jagielski j...@jagunet.com wrote: Yeah, I think conn_rec would make sense if we were a single-threaded server, but considering the hybrid that we are, the real thing we're concerned about are the raw sockets. This also makes more sense with things like SPDY, iirc. The reason I had conn_rec in mind wasn't to do with being single threaded, but rather to do with the supporting infrastructure like the logging API, etc taking a conn_rec. What would be less-than-ideal would be if we had a sudden proliferation of interfaces, each module trying to reinvent what conn_rec does. The conn_rec structure doesn't dictate any single threaded behaviour, it just contains metadata about the socket after all, and optionally a link to a filter stack (and the filter stack need not have any single threaded concept either). One thing I did notice - conn_rec contains all sorts of metadata about the socket, but not the apr_socket_t itself, and that isn't cool. Ideally we must fix that. I also like the weirdness of the API (socket grouping)... it's more robust. I really, REALLY like this! ++1 To be clear I really like this too. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: asynch websockets tunnel
On 05 Jun 2013, at 3:00 PM, Eric Covener cove...@gmail.com wrote: I've been playing with this in my sandbox, it adds a socket readable callback to event, similar to the timed callback, which allows mod_proxy_wstunnel to hop on and off the thread like test/mod_dialup. http://people.apache.org/~covener/websocket-asynch-8.diff I was meaning to play around with a similar idea, but you beat me to it. What I had in mind was an API that passed conn_rec structures rather than raw sockets, which could then be processed using the same lifecycle that a server generated conn_rec's pass through (ap_run_process_connection()). Proxy could then pass the conn_rec it uses towards the backend to the core, and then obtain event driven events for ready-to-read and ready-to-write from the frontend and the backend, independently of one another. The weird API for the socket callback, which treats a set of sockets as a group and only callbacks once per group, is to avoid hairy situations where something like wstunnel or mod_proxy_connect sees callbacks after the request has finished (or has to make sure this doesn't happen and use longer-lived pools for state). In theory these callbacks should be automagically registered with a pool cleanup, and should in theory be cleaned up automatically. It would be up to the caller to specify what pool they plan to tie the lifetime to. This is how conn_rec and request_rec work, ideally any new API should work the same way. The callbacks-as-a-group idea is really nice, what I've always wanted is a way to say call me when socket X is readable and socket Y is writeable, so I don't waste a lot of time trying to figure this out for myself. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: asynch websockets tunnel
On Wed, Jun 5, 2013 at 10:03 AM, Graham Leggett minf...@sharp.fm wrote: On 05 Jun 2013, at 3:00 PM, Eric Covener cove...@gmail.com wrote: I've been playing with this in my sandbox, it adds a socket readable callback to event, similar to the timed callback, which allows mod_proxy_wstunnel to hop on and off the thread like test/mod_dialup. http://people.apache.org/~covener/websocket-asynch-8.diff I was meaning to play around with a similar idea, but you beat me to it. What I had in mind was an API that passed conn_rec structures rather than raw sockets, which could then be processed using the same lifecycle that a server generated conn_rec's pass through (ap_run_process_connection()). Proxy could then pass the conn_rec it uses towards the backend to the core, and then obtain event driven events for ready-to-read and ready-to-write from the frontend and the backend, independently of one another. conn_rec is easy for the proxies, but could limit how other mods can take advantage of the service
Re: asynch websockets tunnel
On Jun 5, 2013 7:33 PM, Graham Leggett minf...@sharp.fm wrote: On 05 Jun 2013, at 3:00 PM, Eric Covener cove...@gmail.com wrote: I've been playing with this in my sandbox, it adds a socket readable callback to event, similar to the timed callback, which allows mod_proxy_wstunnel to hop on and off the thread like test/mod_dialup. http://people.apache.org/~covener/websocket-asynch-8.diff I was meaning to play around with a similar idea, but you beat me to it. What I had in mind was an API that passed conn_rec structures rather than raw sockets, which could then be processed using the same lifecycle that a server generated conn_rec's pass through (ap_run_process_connection()). Proxy could then pass the conn_rec it uses towards the backend to the core, and then obtain event driven events for ready-to-read and ready-to-write from the frontend and the backend, independently of one another. The weird API for the socket callback, which treats a set of sockets as a group and only callbacks once per group, is to avoid hairy situations where something like wstunnel or mod_proxy_connect sees callbacks after the request has finished (or has to make sure this doesn't happen and use longer-lived pools for state). In theory these callbacks should be automagically registered with a pool cleanup, and should in theory be cleaned up automatically. It would be up to the caller to specify what pool they plan to tie the lifetime to. This is how conn_rec and request_rec work, ideally any new API should work the same way. The callbacks-as-a-group idea is really nice, what I've always wanted is a way to say call me when socket X is readable and socket Y is writeable, so I don't waste a lot of time trying to figure this out for myself. Regards, Graham --
