Alex, >> 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).
Okay, good to see you had the same hunch. > 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. Makes sense. > The other thing I was planning to look at was how modproxy-wstunnel > and friends work - they must face a similar problem. It looks like mod_proxy_wstunnel creates a pollset on the underlying sockets. Then it waits for incoming data on both, and writes/flushes (blocking, I think) any bytes received from one to the other. It makes me a little nervous that the module is polling on the socket while reading through the brigade, but I think at this point I'm going to try to retrofit that logic onto mod_websocket and see where it gets me. The key advantage is that there's only one thread reading and writing, which makes me much more comfortable... Polling has the issue that I need to wake up the brigade-owner-thread whenever I want to send a message from server to client. On *nix I would use a self-pipe; on Windows I'm not sure. Maybe APR has an abstraction for socketpair()? Jacob Champion LabVIEW R&D National Instruments
