On 10 Sep 2015, at 23:26, Jacob Champion <champio...@gmail.com> wrote:
> On 09/10/2015 02:50 PM, Alex Bligh wrote: >> Here: https://github.com/abligh/apache-websocket >> >> in the vncproxy directory you will find a vncproxy (which is actually >> a generic tcpproxy as well, though it could be hugely simplified to >> do that alone) which you are welcome to have if you've not changed >> the API to the websocket modules. > > I'll take a look, thanks. Do you know how your implementation relates to > mod_proxy_wstunnel? mod_proxy_wstunnel forwards the websocket connection without interpreting the protocol (i.e. needs to be directed at a websocket server); my module (which just plugs into mod_websocket) forwards it as a TCP port. EG for VNC over Websockets you'd just need to point my module at port 5900, whereas with mod_websocket you'd need something further to decode it. (FWIW I switched from using mod_websocket + my code to mod_proxy_wstunnel and some C with libwebsockets at least in part because I couldn't fix what you seem to have just fixed) >> It would be really helpful if you could document how the threading / >> FD processing / bucket brigade runs now. Crucially you've put all the >> bucket brigade handling into a single thread (I think) which I take >> it is the same thread as apache itself uses - that's what I reckoned >> I needed to do to get it to work reliably with SSL. > > Right, the single thread is the key. The Git commit messages might help with > the understanding somewhat, since that's where I put the patch motivations > (and it's what I'm reading to remember what I did, heh). > > The main loop in mod_websocket_data_framing() is where the real work is done. > This is called on the original request thread from Apache. The loop > alternately checks for incoming data (with a nonblocking read) and outgoing > data (from any messages on the outgoing queue). Reading and writing to socket > is never done by anything but the framing loop; mod_websocket_plugin_send() > queues any cross-thread messages for later processing by the loop. This is > similar to a UI event dispatcher, if you've ever worked with a framework that > used one. > > The only "tricky" part in the architecture is that we don't want to busy-wait > if we have nothing to do, so there's an apr_pollset_t that is waited on when > we run out of work. > > Hopefully that makes sense -- any specific parts that still need > clarification? Thanks. Yes that makes sense I think. I sort of more meant that it would be useful in a README or something in the module itself, as I had difficulty grasping it when I was writing the vncproxy stuff. -- Alex Bligh
