WHACK (was: Re: [Standards-JIG] Reliable message delivery (the tcp problem))
mwild1+jig at gmail.com
Wed Apr 26 11:10:36 UTC 2006
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.
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.
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. 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.
That's what I think :)
On 4/26/06, Dave Cridland <dave at cridland.net> wrote:
> On Wed Apr 26 07:55:18 2006, Jacek Konieczny wrote:
> > On Tue, Apr 25, 2006 at 10:38:41PM +0100, Dave Cridland wrote:
> > > I think you're duplicating TCP level ACKs there needlessly
> > The problem is, that TCP level acks are very hard to utilize at
> > application level. Operating system knows which data was not
> > received by
> > the remote party, but there is no easy way for application to get
> > that
> > information and bind it to corresponding stanzas sent.
> Yes, this is also a problem. It's less of one than you might think,
> however, because it doesn't matter at all whether a stanza was
> delivered to the remote endpoint of the TCP virtual circuit, it only
> matters whether the application attached to that VC has processed it
> or not. (To use a different, more fitting, phrase, whether the
> application has "accepted" the stanza).
> However, you generally know this because a subsequent stanza sent a
> few seconds later doesn't generate a TCP error on send, or you
> receive some data, or whatever. The remote party always has to accept
> stanzas in order, so any command succeeding or failing is evidence
> that all prior stanzas have been accepted. (And that has to be the
> case now, for reasons too complex, and hopefully too obvious, to go
> > > In general, hop-by-hop reliability is only a problem in as much
> > as it > can be difficult to know whether the connection is still
> > alive.
> > ... and when it become dead, so the application is able to tell the
> > user
> > which messages could be lost. We could save some bandwith by not
> > trying
> > too keep exact account of stanzas delivered to link peer, but
> > application should be able to detect which stanzas were delivered
> > for
> > sure and which could be lost. And the number of "probably lost"
> > stanzas
> > should never be too big, so there is no need to buffer too much
> > (stanzas
> > sent) on application side.
> Exactly, hence my suggestion. Something like the client sending:
> <message from="foo at example.org" to="bar at example.net" ack:seq="25"/>
> And later, during a reconnect caused by the client detecting a
> So the client knows that the message above needn't be resent. (But
> all subsequent stanzas need to be).
> I'm guessing that'd need to be sent by the server either during/after
> resource binding or session startup, I'm not exactly sure where - I'm
> no expert with XMPP.
> This also gives the beginnings of a quick-reconnect protocol, for
> instance for roster resynchronization without having to download the
> entire thing again, in principle, but there's little point worrying
> over that now.
> There's also no need to send an ack:seq attribute on every stanza - a
> client need only send them on the last stanza in a pipelined set, or
> might choose not to send them on idempotent iq stanzas. I doubt that
> kind of thinking is worth the effort, but it's possible.
> 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