[Summit] [BOSH] BOSH discussion at Summit 12

Steffen Larsen zooldk at gmail.com
Sat Oct 13 08:32:16 UTC 2012


+10 extra on the remote participation or at least some video recording of the summit could be cool!, if people are up for it..

A discussion about bosh vs. web sockets (performance wise) and updating the xmpp over websokets (Jacks document) would be a great addendum. 
I have personally used tsung (through raw XML messages) for testing the bosh connections and optimisations on the server side etc.

/Steffen

On Oct 12, 2012, at 5:19 PM, Waqas Hussain <waqas20 at gmail.com> wrote:

> On Thu, Oct 11, 2012 at 3:55 AM, Winfried Tilanus <winfried at tilanus.com> wrote:
>> On 10/09/2012 05:17 PM, Peter Saint-Andre wrote:
>>> On 10/9/12 6:51 AM, Jack Moffitt wrote:
>> 
>> Hi,
>> 
>>> Agreed on remote participation. At least Google
>>> Hangouts use Jingle so we won't feel too guilty. ;-)
>> 
>> Great, I will get myself a webcam ;-)
>> 
>> Looking at my schedule and the time difference, it would suit me best to
>> have the discussion in the afternoon, Portland time. Any of the days are
>> fine with me.
>> 
> 
> +10 to remote participation! I'll note Google hangouts had a limit of
> 9 users the last time I checked.
> 
>>>> I think the websockets-only path would assume the same API in
>>>> browser, but the implementation would fall back to long polling.
>>>> This is probably not going to be as good as BOSH, so I think it
>>>> probably makes sense to keep BOSH since it's already widely
>>>> implemented. People will gradually quit using it as websockets
>>>> deployment grows.
>>> 
>>> Jack, could you clarify what you mean by "assume the same API" and
>>> "would fall back to long polling"? It seems to me that we might use
>>> the same API but if WebSocket is available then the implementation
>>> would use WebSocket, but it not then it would fall back to BOSH.
>> 
>> AFAIK websockets itself nor the JS APIs mandate any fallback mechanism,
>> so we are free to use whatever we like. And we happen to like BOSH. ;-)
>> 
>>> Furthermore, it would be very helpful to do some side-by-side tests of
>>> BOSH vs. WebSocket to figure out what the performance improvements are
>>> for using WebSocket.
>> 
>> Appr. 2 years ago Stefan Strigler did some benchmarking with the
>> experimental support for websockets that was added to JSJaC
>> (https://github.com/sstrigler/JSJaC/tree/websockets_deprecated) in
>> combination with the preliminary support for it in eJabberd. Compared to
>> BOSH in the same combo, it was remarkably fast. If Steve still has his
>> benchmarks around, it would be nice if he could step in here...
>> 
> 
> Regarding benchmarking, I'd like to point one thing out: Current BOSH
> servers are not optimized at all, e.g., ejabberd and Prosody 0.8 don't
> implement Connection: keep-alive. I added this in Prosody 0.9, along
> with faster HTTP parsing and other optimizations. The performance
> impact of keeping connections alive (as opposed to creating a new TCP
> socket for every request) was roughly an order of magnitude.
> 
> For a well-optimized server, the performance difference between BOSH
> vs websockets would just be extra bandwidth used by HTTP headers and
> the header parsing required. It seems to me that this would be small
> enough to not matter unless your bandwidth or CPU or ports are
> saturated.
> 
> I'll try to find some time to benchmark Prosody's mod_bosh vs
> mod_websocket. If there are existing benchmarking tools available,
> that would be great, though I suspect we might have to write our own
> (with normal XMPP benchmarking we found servers often being faster
> than existing benchmark tools, thus the benchmarks turning into
> benchmarks of the benchmarking tool...).
> 
>>>> As for the XMPP over websockets spec being unpolished, I'm happy
>>>> to take suggestions. As far as I know it's current with the
>>>> websockets spec. Perhaps you are referring to the existing
>>>> implementations and not the internet draft?
>> 
>> I assumed that the changes to the websocket protocol in the last years
>> would also need an update of the XEP, probably that assumption is
>> incorrect. But I would like to know for sure.
>> 
>>> I'd be happy to take a look at the Internet-Draft again as well.
>> 
>> Thanks, that would be very useful.
>> 
>> Winfried
> 
> --
> Waqas Hussain



More information about the Summit mailing list