+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 <[email protected]> wrote: > 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
