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