We are starting to write an XMPP chat app for Android. I managed to get the Smack 4.1 beta1 version up and running very quickly, enabling two people to chat. Because the app is running on mobile, the connection to the XMPP server are short-lived by nature. Happily I have read that beta1 includes the Stream Management extension.
Another extension that draw my attention is BOSH which uses XMPP over HTTP solving the issue of unreliable connections and also Firewalled TCP ports (because it uses 80 which is usually open). Smack supports BOSH according to this:
Another extension that draw my attention is BOSH which uses XMPP over HTTP solving the issue of unreliable connections and also Firewalled TCP ports
BOSH certainly allows XMPP where only a unblocked HTTP(S) connection is available. But it does not automatically solve the issue of unreliable connections.
This is not due BOSH itself but because the BOSH code lacks a developer who takes care of it. All I did was to fork jbosh over to ignite realtime and include the patches from aSmack to make jbosh Android compatible (basically replacing the HTTP client library and fixing a regex). But since I personally don’t use the code I only take care that everything compiles and looks ok. That’s why smack-bosh’s description reads “This API is considered beta quality”.
jbosh itself has some issues (e.g. the unit tests a non-deterministic), and requires some attention.
I’ve reports that it works more or less, but that there are delays up to a few minutes (just search the forum). This is most likely related to how polling is implemented. But since I don’t use BOSH, it’s not on my todo list to look into this.
I hope that one day some skilled developer appears, willing to take care of BOSH, providing some good unit, stress and integration tests.
Should I use BOSH, Stream Management or both together (is that even possible)?
Using XEP-198 over BOSH adds no value. BOSH is already a “managed stream” over HTTP.
I tend to disagree here. The following (from XEP-0198) is true for BOSH as well:
it is desirable to quickly resume the former stream rather than complete the tedious process of stream establishment, roster retrieval, and presence broadcast.
Also, what if a client connects with BOSH, then disconnects due to network failure, but the server doesn’t recognizes it fast enough (usually only after the polling interval has exceeded, which is usually 60 seconds). The BOSH connection manager would return the HTTP response with some messages, but it wouldn’t receive the user and would probably get lost.
If SM would have been negotiated, the client could resume the old stream, inform the server about its stanza count and the server would deliver them.
The BOSH connection manager would return the HTTP response with some messages, but it wouldn’t receive the user and would probably get lost.
Wouldn’t that case be handled by response acknowledgements (XEP-124 § 9.2)?
Still wondering about the interaction (if any) between BOSH and SM, especially about the stream resumption part.
As BOSH-based XMPP streams could span multiple TCP connections, there is implicit resumption built-in.
Note that I expect the same to be true for the new XMPP Websocket soon-to-be-RFC.
I conclude that for Android, the obvious choice will be XMPP with TCP bindings with Stream Management. Long polling and and web sockets are not such a good fit after all, moreover the implementation is not ready.
Ahh right, I remember the thread on standards now. And thanks for pointing out that RFC 7395 mentions XEP-198. I was somehow under the assumption that websockets would keep the state just like BOSH does.
Long polling and and web sockets are not such a good fit after all, moreover the implementation is not ready.
“not good fit” hmm, I’d say that if you can use XMPP over plain TCP then this is the preferred solution as it does not come with an additional overhead.
BOSH only advantage compared to XMPP over TCP + XEP-198 is that it could be successful when most outgoing connections are blocked/firewalled.
Maybe a silly question, but could we not run the XMPP service under port 80 instead of 5222 to bypass Firewalls?
Depends on the “firewall”. If it does not perform packet inspection then the answer is “likely yes”. But if something involved in the firewall concept that expects HTTP to be spoken, think e.g. of a Proxy server, then it won’t work.