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: Debugging mod_websocket -- any others out there?
Date Wed, 25 Feb 2015 21:29:03 GMT
Jacob,

> It looks like half your fixes were pulled upstream; the remainder
> involves a new allocator and mutex [2]. Anything else I'm missing?

Not that I recall.

> This is a Windows 64-bit build. I can reproduce this easily, usually
> within seconds of running my tests. I can try to work up a minimal
> reproduction case if anyone else turns up and is interested.

Well, that's an improvement on 20 hours of youtube video over VNC
over websockets ...

> My suspicion is that the two-brigade approach clashes with the fact that
> OpenSSL can read from the socket during its writes and vice-versa. But
> that's only a suspicion -- for all I know, mod_ssl and/or Apache might
> have synchronization techniques that make parallel brigades safe.

My guess was that it worked without SSL as the brigades have separate
allocators. However, SSL can write when it's reading and vice versa
(to implement the SSL protocol), and this caused problems. You want
as multi-core a machine as possible to demonstrate it (my single core
VM was not a good plan).

>> I spent many many hours on this, ultimately unsuccessfully (I've
>> moved to mod_proxy_wstunnel plus a libwebsockets C based thing).
> 
> Tangent: I tried libwebsockets about six months back. I had trouble with
> heavy load with it too -- the architecture didn't seem to handle the
> case where the network stack could only accept a partial write, which
> led to a lot of spurious disconnects when streaming massive amounts of
> data. Have you run into that as well?

I tried libwebsockets originally (years ago) and ran into that issue, or
something similar. I then tried again, and it's no longer an issue as far
as I can tell. I'm using the external poll stuff, and getting the flow
control right was a little hairy. On the specific issue (large writes
of data towards the client), I think I limit the amount in each ws
packet (for streaming, that's irrelevant); perhaps that just hides the
issue.

FWIW I'm now using modproxy-wstunnel in apache to unwrap the SSL,
then an external program to unwrap the websockets and (in essence)
forward as a TCP session. It would be really nice if that could be
done in modproxy-wstunnel (i.e. say 'unwrap the websocket too').

>> FWIW if I hadn't made the above move, my plan was to eliminate
>> doing most of the work in the apache thread by using a bucket
>> brigade thate ended in a socketpair (I can't remember the correct
>> apache terminology here, but the point was to have apache
>> do the read/write from one end of the socketpair), then set
>> up two new threads to read and write from the other end
>> of the socketpair, encoding/decoding as we go. This means that
>> once the connection is live the module code itself wouldn't
>> actually touch any apache memory-managed data.
>> 
>> IE:
>> 
>> Apache <==> Socket+Socket <===> Decode/Encode <===> Whatever
> 
> Interesting. So, if I've got this right, you'd try to artificially
> terminate the chain in a pair of file descriptors, and then handle those
> directly using select/poll/whatever from more threads?

Yes

> Are there any existing modules in Apache that take a similar approach?

Not to my knowledge. Which is why I backed off doing it!

I couldn't even find any real documentation for the thing that
ended a brigade in a pipe/socketpair; I found the code by accident
while hunting the above bug.

The other thing I was planning to look at was how modproxy-wstunnel
and friends work - they must face a similar problem.

-- 
Alex Bligh





Mime
View raw message