On Thu, Oct 11, 2012 at 3:55 AM, Winfried Tilanus <[email protected]> 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
