Strophe.js and WebSockets?
DustMason
Strophe.js? I would love to reward my users who keep their browsers
upgraded with a better experience while keeping the long-polling
solution for the rest.
I recently came across an interesting solution that someone creating
using node.js and socket.io to create a bridge between the browser and
XMPP that leverages web sockets: http://forrst.com/posts/Socket_io_XMPP_Chat-58N
This is, of course, a simple proof of concept and doesn't even scratch
the surface of the functionality you get with Strophe and XMPP. Would
there be some way to take advantage of the work done on socket.io's
client-side javascript to allow support of a wide variety of transport
mechanisms in Strophe? It currently exposes a websockets-like API
which sits on top of WebSocket, Flash, forever iframe, XHR long
polling and XHR multipart encoded connections.
https://github.com/LearnBoost/Socket.IO
Jamie Dyer
Unfortunately it's taking a while for the standards to be defined
regarding WebSockets/XMPP so the ejabberd guys aren't going to be
adding native support for a little while as far as I understand. I
think this is a shame and would have liked the community to jump on
this technology, it's a massive improvement over BOSH which is
essentially a hack to get a socket like connection working over http.
Jack Moffitt
The Websockets standard is still in major flux, and breaking changes
are happening all the time. I'm not even sure if the debate over basic
framing or any of the handshakes have reached consensus yet. It's a
little early to be spending a lot of time on implementations.
Also, as far as I know, Chrome is the only browser that supports
Websockets out of the box, and it's support is for an old draft of the
spec which is no longer current. It's possible that the Chrome team
have updated this in the dev builds; I haven't been paying real close
attention for the last two months.
That said, I'm absolutely interested in getting Strophe, ejabberd, and
XMPP all working great over Websockets. It definitely has some
advantages over BOSH. But please don't forget that BOSH has several
advantages of its own that Websockets cannot replicate. I don't think
either technology will be right for all problems. It's also the case
that many handshake proposals have more roundtrips than BOSH does, and
so there is some talk that performance oriented implementations will
need to start with BOSH and then switch to Websockets in order to get
the lowest latency.
jack.
DustMason
browsers is holding us back... but at least we know its coming right?
The reason I pointed out Socket.IO was to suggest that maybe
Strophe.js' could benefit from separating the "transport layer" (BOSH)
from the XMPP-specific code. I'm not familiar enough with XMPP to know
if this a stupid suggestion, but I would hope that doing it this way
reduces the dev work needed to just a server-side implementation of
WebSockets (which might be a huge task, i'm not familiar enough with
the spec to know). Socket.IO has gained a healthy user community and
apparently powers WebSockets solutions for a handful of live apps
already. Using it - or something like it - would allow Strophe to
operate without having to worry about whether its connected via BOSH,
WebSockets, etc.
Sorry if this is an ignorant suggestion.
Eric Cestari
We have a working implementation of websockets in ejabberd and I have
ported StropheJS to support websockets.
I use the -00 websocket draft, which happens to be supported by the
major browsers in their current version.
Given the speed at which the browsers move their implementations, we
have time to port the server side with little hassle.
The results are quite good : Full digest authentication* goes from 1.5
sec to around 400ms on localhost.
Unfortunately there's no tls and compression support (yet) in
websockets.
I've written my Strophe.Websocket code without removing code from
Strophe.Connection, meaning that we can have an easy fallback to BOSH.
The other great implementation improvement I am looking forward to is
to switch from XML to JSON for encoding XMPP stanzas.
Full digest authentication goes down from 400ms to 60-70ms. (the DOM
toll bridge is expensive).
Combined with some extensions we wrote for fast rebinding to an
existing connection (written originally for OneTeam for iPhone) you
get incredible performance on page load.
I also do have a working implementation in ejabberd and StropheJS with
JSON-encoded stanzas. (not too happy by my Strophe stanza parsing code
for the moment, and you can't use jQuery anymore), but I managed to
rewrite Gab (from metajack's book) with websocket-json support.
(*full digest authentication: from stream opening to resource binding)
Best regards,
Eric
--
Process One
http://www.process-one.net/
Charlie Johnson
any chance that you can post the websocket-json mod of Gab somewhere?
I think I had the exact same thoughts last night. "Why all this xml?
Why not json?". So you can imagine that i'm quite interested in this.
And what do you exactly mean by "....and you can't use jQuery
anymore...". Thanks :)
Jack Moffitt
> Why not json?". So you can imagine that i'm quite interested in this.
JSON is not extensible. XML is. XMPP relies very heavily on protocol
extensions which are based on XML namespaces and other extension
mechanisms.
The data models are not really compatible. You can certainly represent
any given XML fragment in JSON (in many different ways!), but I've not
yet seen it done in a way that is still extensible or still looks at
all like JSON.
I'll take XPath (or even jQuery's selector engine) over working with
raw JSON any day. Luckily, at least that part should be easy to
translate to JSON :)
jack.
Tuomas Koski
Hear hear!
Cheers,
--
tuomas
Eric Cestari
Le 30 nov. 2010 à 14:00, Charlie Johnson a écrit :
> Hi Eric,
>
> any chance that you can post the websocket-json mod of Gab somewhere?
> I think I had the exact same thoughts last night. "Why all this xml?
> Why not json?". So you can imagine that i'm quite interested in this.
I will do that. There are few things I'd like to work on before deploying it somewhere public, but I really hope that we can deploy something soon.
I also hope that the XSF will consider the work
> And what do you exactly mean by "....and you can't use jQuery
> anymore...". Thanks :)
jQuery is usually used to parse and traverse the XML stanzas and extract information.
That, you can't do with JSON. But you can access message.to or message.$.body.value.
Eric Cestari
Le 30 nov. 2010 à 17:32, Jack Moffitt a écrit :
>> I think I had the exact same thoughts last night. "Why all this xml?
>> Why not json?". So you can imagine that i'm quite interested in this.
>
> JSON is not extensible. XML is. XMPP relies very heavily on protocol
> extensions which are based on XML namespaces and other extension
> mechanisms.
>
> The data models are not really compatible. You can certainly represent
> any given XML fragment in JSON (in many different ways!), but I've not
> yet seen it done in a way that is still extensible or still looks at
> all like JSON.
The code I wrote maps xmlelement ejabberd records to JSON.
I am currently less than happy by my Strope modifications handling JSON, and loosing jQuery selector is certainly something I regret.
I am not saying we should ditch XML. JSON is not as readable and the toolchain is very inferior to XML's.
As a matter of fact, on a BOSH connection, the performance improvement is quite negligible, and it's not really worth it to rewrite a BOSH only application to JSON, and loose the jQuery flexibility. Most of the time is spent on the network connection, buffering and POST'ing.
And on client non web applications, there is not DOM "context switching" as there is in the browser.
The JSON stanzas are just another representation (in the REST sense) of the same XML stanza.
But performance is so incredibly superior over websockets I think it's totally worth investigations. I'm especially thinking of mobile applications, but even desktop browsers love JSON over websocket.
I know websockets are not done yet, consensus is far from achieved, but we will have websockets someday, everyone will agree (even on the hybi mailing list :) ). Let's get ready for the future and improve our application performance tenfold.
Cheers,
Eric
Jack Moffitt
It will, certainly. The Websockets group is also looking for such work.
If you'd like some help with this stuff, I'd be happy to lend a hand.
It was on my task list anyway as part of both groups.
jack.
Jack Moffitt
This is the part I don't understand. Can you share how this is
measured, the details of the system, etc?
I assume that perhaps the parse time for XML is really bad or
something, or else this is the classic XML parsing problem that you
are building a new parser for every packet?
jack.
Eric Cestari
Le 1 déc. 2010 à 16:38, Jack Moffitt a écrit :
>> But performance is so incredibly superior over websockets I think it's totally worth investigations. I'm especially thinking of mobile applications, but even desktop browsers love JSON over websocket.
>
> This is the part I don't understand. Can you share how this is
> measured, the details of the system, etc?
I took the Gab code from the book, and customized it in two flavors, JSON and XML.
Both version can either connect over BOSH and Websockets.
I then measured the time from connecting to the ejabberd server (on localhost, the fastest server on the net) to the "connected" event in Strophe.
>
> I assume that perhaps the parse time for XML is really bad or
> something, or else this is the classic XML parsing problem that you
> are building a new parser for every packet?
You're onto something, I guess :)
My parsing function looks like this :
_parseTree: function(s) {
try {
var r = XmlDocument.create("body","foo");
if (typeof(r.loadXML) != 'undefined') {
r.loadXML("<body xmlns:stream='foo' >" + s + "</body>");
return r.documentElement.firstChild;
} else if (window.DOMParser)
return (new DOMParser()).parseFromString(s, "text/xml")
.documentElement.firstChild;
} catch (e) { Strophe.error("Error : " + e) }
return null;
},
I did not give it much thoughts, but now that I look at the code again I see there's certainly room for optimization.
E
John Greene
Maybe the differences in efficiency in the transport layers contribute to the performance difference also?
John
Jack Moffitt
Most packets are small, so I kind of doubt this. It is something that
is easily testable though. I often here people talking of how JSON is
much smaller than XML, but I have never seen any data on that.
After compression, I assume they are equivalent even if they aren't before.
jack.
Eric Cestari
Le 1 déc. 2010 à 21:36, Jack Moffitt a écrit :
>> Maybe the differences in efficiency in the transport layers contribute to the performance difference also?
>
> Most packets are small, so I kind of doubt this. It is something that
> is easily testable though. I often here people talking of how JSON is
> much smaller than XML, but I have never seen any data on that.
I've come to believe that this is a fallacy.
All measures I've done with the mapping I use tend to make JSON stanza at least as big as their XML readability.
The only case I have for JSON is performance compared to XML. But Jack pointed out that my XML parsing code could run faster. If it's not sufficiently faster, JSON looses much of its appeal. Because XML trumps JSON on readability and toolchain.
Eric
John Greene
Thats true, but there's also the request and response headers which can be large, even for a tiny payload, and are entirely absent in websockets if I understand correctly.
John Greene
Thats true, but there's also the request and response headers which can be large, even for a tiny payload, and are entirely absent in websockets if I understand correctly.
Jack Moffitt
This is equally true for JSON and XML both. The massive amounts of
header overhead is one of my most hated things about XMLHttpRequest:
http://metajack.im/2008/11/10/user-agent-headers-request-headers-out-of-control-in-general/
jack.