httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Bligh <a...@alex.org.uk>
Subject Re: mod_websocket ownership (and fixes)
Date Fri, 11 Sep 2015 17:02:03 GMT

On 10 Sep 2015, at 23:26, Jacob Champion <champion.p@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





Mime
View raw message