[Standards] Binary data over XMPP
fabio.forno at gmail.com
Wed Nov 7 23:29:47 UTC 2007
On Nov 7, 2007 11:53 PM, Dave Cridland <dave at cridland.net> wrote:
> (Hmm, this reminds me, I need to get around to finishing and
> publishing an I-D before the deadline on fast reauth).
Perhaps I'm missing something... Fast reauth? You mean just a speedup
in the login process (e.g. a token for rebinding a session) or also
some optimizations such as avoiding the initial presence burst when
One of the reasons I tend to use id bosh is the ability of keeping the
session open when the client temporary disconnects
> > and therefore we prefere bosh based
> > connections.
> I do think that BOSH is an exceedingly good design. But, FWIW, I use
> long-lived TCP connections over mobile networks quite a lot, and I
> find they work fine, even when moving between cells. (I use XMPP, but
> also IMAP and ACAP, all of which have server initiated data
> transfers, or "push" as the media calls it).
I'm aware of this. We support also long lived TCP connections and they
work fine (well, the main reason is that we're not ready, yet, for
proxying through bosh all the possible traffic, and public servers, at
present, support almost only tcp connections). Also BOSH, when
implemented on pipelined http 1.1, exploits a long lived TCP sockets
and the conections are pretty robust. The real advantage of BOSH id
that packets are implicitely framed by http requests/responses and
it's very easy to recover from any error, and it's also easy to
interleave other types of packets. Unfortunately TCP streams don't
have this kind of framing and any attempt of inserting somenthing
between the raw socket and the xml stanzas is dangerous...
> As far as I know, the OMA are increasingly interested in long-lived
> TCP based protocols, too, so the stability of mobile networks will
> hopefully improve.
The problem is that 100% reliable connections are impossible and a
framed binding such as bosh helps in recovering ;) Baiscally my
rationale is: why putting a lot effort and resources for recovering
from a very small failure rate, knowing that fixing everything is
impossible, when a smarter data protocol does all the job?
> You're absolutely right - right now, exchanging large amounts of
> binary data over long thin pipes is a very unlikely state of affairs.
> I think this will change, primarily due to encryption, and - as a
> much more minor issue - due to increased "rich messaging". (I'm
> thinking about radio stations showing you pictures of the band now
> playing, and such things, which certainly some mobile companies are
> very keen on).
Yeah, but also in this cases but encryption, I don't think that in
band binary stuff is really necessary.
Perhaps there is only one practical reason: many platforms (i'm
thinking of j2me) don't allow opening new connections without user
authorization, so receiving obb data may be annoying as user
Fabio Forno, PhD
Istituto Superiore Mario Boella
Jabber ID: xmpp:ff at jabber.bluendo.com
** Try Jabber http://www.jabber.org
More information about the Standards