WHACK (was: Re: [Standards-JIG] Reliable message delivery (the tcp problem))

Dave Cridland 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 
> that
> 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, 
> and
> 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 
> the
> 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 
little extra.


> Whatever it is, I think something in the RFC's would be better than 
> a
> 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_ 
> would
> 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.

Dave.
-- 
           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 mailing list