On Nov 7, 2007 11:53 PM, Dave Cridland <[EMAIL PROTECTED]> 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 going online? 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 experience. -- Fabio Forno, PhD Istituto Superiore Mario Boella Jabber ID: xmpp:[EMAIL PROTECTED] ** Try Jabber http://www.jabber.org
