[Standards] switching between BOSH and TCP?

Stephen Pendleton stephenpendleton at hotmail.com
Mon Mar 31 16:14:24 UTC 2008

I don't see why this is silly. As it says in the BOSH XEP: [BOSH] is useful in situations where a device or client is unable to maintain a long-lived TCP connection to an XMPP server.

Also, BOSH uses TCP in most scenarios so we need to be careful when discussing "switching between BOSH and TCP". What is being discussed is actually "switching between BOSH and long-lived TCP sessions".

I believe that the offlist user was suggesting allowing a user to switch from a BOSH session back to the standard long-lived TCP connection and vice versa WITHOUT losing presence on the server. However, I would think this currently could be accomplished on the server side by simply logging in again with the same jid/resource and disconnecting the previous connection. Of course you still have the problem where we don't have a "fast reconnect" feature which would make it more economical to do this.

This would be useful in some cases since BOSH is eventually the way to go for many mobile clients. In particular I have implemented a BOSH solution where the session reconnect is triggered by a SMS message from the server to the client device. This saves lots of battery compared to the traditional long-lived TCP XMPP solutions since the data connection is not active when there is no "chat" activity.

-----Original Message-----
From: standards-bounces at xmpp.org [mailto:standards-bounces at xmpp.org] On Behalf Of Peter Saint-Andre
Sent: Friday, March 28, 2008 4:06 PM
To: XMPP Extension Discussion List
Subject: Re: [Standards] switching between BOSH and TCP?

> This seems silly to me.  BOSH is used when TCP is not possible.  If
> both are
> possible, you always pick TCP regardless of activity level.

I agree, but thought I'd mention it anyway. :)


Peter Saint-Andre

Test your Star IQ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080331/5d6324a6/attachment.html>

More information about the Standards mailing list