httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Champion <>
Subject Re: Debugging mod_websocket -- any others out there?
Date Thu, 26 Feb 2015 19:00:19 GMT
On 2/26/2015 7:23 AM, Eric Covener wrote:

> You might check out how mod_spdy shares a connection between threads.

Hi Eric, thanks for the suggestion! mod_spdy is interesting; IIUC, the
logic is basically

    output_block_time = 1 ms
    while (not stopped) {
        // Input cycle
        if no output is possible:
            block to read data
            read as much data as we have without blocking

        if we got data:
            process the data
            reset output_block_time to 1 ms

        // Output cycle
        if output is possible:
            wait up to <output_block_time> for output

        if we have output:
            write it to socket (blocking)
            output_block_time *= 2, max out at 30 ms

I'm assuming this approach was taken because SPDY is still (I think)
request-response based. For WebSocket, output is _always_ possible at
any time, which means we would never get to perform the "block to read
data" step. We'd have to introduce a maximum blocking time for input
too, so an idle-but-connected WebSocket would continually bounce between
waiting on input and waiting on output. The exponential backoff helps,
but the somewhat random spikes in latency mean it's definitely not my
first choice.

I'm interested in the TODO at the bottom of that block though:

> TODO(mdsteele): What we really want to be able to do is to block
> until *either* more input or more output is available. Unfortunely,
> there's no good way to query the input side (in Apache). One
> possibility would be to grab the input socket object (which we can
> do), and then arrange to block until either the socket is ready to 
> read OR our output queue is nonempty (obviously we would abstract 
> that away in SpdySessionIO), but there's not even a nice way to do
> that (that I know of).

In this case, if I can get the input socket, I might be able to
construct an APR_POLLSET_WAKEABLE pollset around it, and use
apr_pollset_wakeup() to break out of the poll whenever I want to write
output. I'm currently failing to find how to get a socket from a
request_rec, though. I'm guessing it's not supposed to be easy...

Jacob Champion
National Instruments

View raw message