WHACK (was: Re: [Standards-JIG] Reliable message delivery (the tcp problem))
dave at cridland.net
Wed Apr 26 12:35:29 UTC 2006
On Wed Apr 26 12:10:36 2006, Matthew Wild wrote:
> As a user I do find XMPP an unreliable protocol. It has happened
> I have been sent messages, which the other party assumed I
> recieved. A
> particularly bad network connection at the time meant I never saw
> those messages reach my client.
It's even possible they did, but your client detected the termination
of the TCP socket before it processed all the outstanding data. I've
seen that happen in other protocols, so I don't hold much hope that
XMPP clients are all perfectly programmed.
> As a developer, whacks are easy to implement, and I don't think they
> need to be tied to particular stanzas, however. If 1 whack is
> generated by the recipient from each stanza, if you send a stanza,
> don't recieve the whack in a reasonable amount of time, you know
> something's up. That means, if you were a server, you would notify
> client of the error, if you are a client, notify the user.
Yes, but what are you notifying them of? Do they need to resend the
message, or was the message received, but the ACK lost? Does the ACK
you just received relate to the stanza you just sent, or did it cross
on the wire?
No, if you have to do whacks, it has to be one per stanza, and even
then you're not solving the problem.
If you're whacking one per stanza, you have to count the stanzas in
order to detirmine which stanza wasn't ACKed.
In which case, you might as well number them explicitly, ditch the
whacks, and have the server note which was the last processed on a
particular session, because it actually gains you much more for very
> Whatever it is, I think something in the RFC's would be better than
> JEP in this case. People argue we are doing the job of TCP, and XMPP
> shouldn't do that.
No, it's *not* doing the job of TCP. TCP makes the socket's data
stream to be ordered and reliable - in other words, it's possible to
lose a packet, and the upper levels have no idea it happened.
What TCP doesn't protect against is, amongst other things, a server
segfaulting during processing of a stanza.
> However, if you really want XMPP to be independant
> of the underlying protocol, I think you need this in the XMPP layer,
> and to assume any underlying protocols are untrustworthy. _That_
> make XMPP network independant.
But it's an unrealistic assumption. It should always be possible to
assume that the underlying network is a reliable ordered stream, and
if there's insufficient support in the underlying network, then the
binding of XMPP to that network should solve that, not XMPP.
Incidentally, none of this relates to end-to-end receipts, which is
an entirely different problem, being worked on with much anguish in
the SIMPLE working group, too - people interested in end-to-end
receipts might want to skim the archives there to get an overview of
the problems they've run into.
You see things; and you say "Why?"
But I dream things that never were; and I say "Why not?"
- George Bernard Shaw
More information about the Standards