41
edits
Difference between revisions of "Myths"
Jump to navigation
Jump to search
no edit summary
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
(Draft blog post) | (Draft blog post) | ||
== Introduction to this wiki page == | |||
Hi. I'm Dave Cridland. There's a note just up there which says "(Draft blog post)", and that's been there from the start - but when I asked for some feedback from the public standards@xmpp.org mailing list, people posted it on Twitter, and then it got onto Hacker News. Which is all cool, it's not secret, but... | |||
This has not been properly reviewed yet (though the community is starting to), and so may contain inaccuracies, errors, or simply bad wording that's inadvertently as misleading as some of the comments I'm trying to rebut, and so feedback is genuinely welcomed. | |||
Also equally welcome is feedback of the kind that says "Yeah, but I think that XMPP is entirely made by KILLING KITTENS", or whatever, so I can either write a rebuttal, or agree with you and try to get the community to fix it. | |||
This is, currently, my personal opinion, and may not represent that of the XMPP community or the XMPP Standards Foundation. | |||
Just for the record, I don't think we kill any kittens. | |||
Dave. ([xmpp:dwd@dave.cridland.net IM]/[mailto:dave@cridland.net Mail]/[https://twitter.com/DwdDave Twitter]) | |||
== Myths and Legends == | == Myths and Legends == | ||
| Line 48: | Line 61: | ||
SATCOM links tend to run at around 9600 - that's the same speed as a GSM data call, which won't help you because you'll have never made one. The latency is around 30s. HF, on the other hand, runs considerably lower, and is half-duplex to boot - it'll run down to around 9 bits/s, and with radio turnaround times at the 2 minute mark every time you need to switch direction, that's almost glacial. | SATCOM links tend to run at around 9600 - that's the same speed as a GSM data call, which won't help you because you'll have never made one. The latency is around 30s. HF, on the other hand, runs considerably lower, and is half-duplex to boot - it'll run down to around 9 bits/s, and with radio turnaround times at the 2 minute mark every time you need to switch direction, that's almost glacial. | ||
Yet XMPP still works - at least as well as anything else. | Yet XMPP still works - at least as well as anything else. Isode have an excellent whitepaper on this: [http://www.isode.com/whitepapers/xmpp-constrained-bandwidth.html M-Link Support for XMPP over Constrained Networks], but the majority of XMPP running over SATCOM are ordinary open source servers such as Openfire. | ||
On mobile, the most concerning cost is the stream startup time - because it uses a sequence of round trips - but extensions such as XEP-0198 can help reduce this substantially. | On mobile, the most concerning cost is the stream startup time - because it uses a sequence of round trips - but extensions such as XEP-0198 can help reduce this substantially. | ||
| Line 65: | Line 78: | ||
The fact: XMPP typically uses reliable stream transports, so even without extensions it's pretty reliable. | The fact: XMPP typically uses reliable stream transports, so even without extensions it's pretty reliable. | ||
There's a classic problem in computer communications called the Two generals problem. I'll wait here for you to read the Wikipedia page. | There's a classic problem in computer communications called the Two generals problem. I'll wait here for you to read the [https://en.wikipedia.org/wiki/Two_Generals%27_Problem Wikipedia page]. | ||
Back? OK. | Back? OK. | ||
| Line 78: | Line 91: | ||
But if you don't get one back, there's no way to tell if it was the message that was lost or the ack, and there's no very obvious way to handle the situation anyway. Do you send another? Or will the client get the message from offline storage? Do you care? | But if you don't get one back, there's no way to tell if it was the message that was lost or the ack, and there's no very obvious way to handle the situation anyway. Do you send another? Or will the client get the message from offline storage? Do you care? | ||
This is where XEP-0198, Stream Management, comes in. The community developed this extension because TCP sessions are a lot less reliable over mobile — now a number of servers support it, and many mobile clients (particularly the Android ones) will use it if available. | |||
XEP-0198 extends TCP's reliability across multiple sessions, and also extends it through to the application. It, too, sends acks on request, but only across a single link. So a client and server can maintain a buffer of sent stanzas, and if they're not acked (and they must be acked in sequence, just like TCP) then when the client reconnects, it can resume the XMPP session (and both ends can resend any missed stanzas). | XEP-0198 extends TCP's reliability across multiple sessions, and also extends it through to the application. It, too, sends acks on request, but only across a single link. So a client and server can maintain a buffer of sent stanzas, and if they're not acked (and they must be acked in sequence, just like TCP) then when the client reconnects, it can resume the XMPP session (and both ends can resend any missed stanzas). | ||
| Line 83: | Line 98: | ||
This mitigates the Two Generals to the point that only the last few messages sent within a session are subject to it, and only then if resuming the session was somehow impossible. | This mitigates the Two Generals to the point that only the last few messages sent within a session are subject to it, and only then if resuming the session was somehow impossible. | ||
The | So wait, doesn't this mean that XMPP, even with all these extensions, is still unreliable in some cases? Isn't the hypothesis - that XMPP stanzas can be lost sometimes - still true? Sure it is. The Two Generals problem is provably insoluble - anyone claiming that their communications system is 100% reliable is making the network communications equivalent of saying they have a perpetual motion machine, and I'm not *that* much of an idiot. | ||
XMPP is, however, as reliable as a protocol can practically be. | |||
== Myth Five : XMPP is unsuited to the web. == | == Myth Five : XMPP is unsuited to the web. == | ||