WHACK (was: Re: [Standards-JIG] Reliable message delivery (the tcp problem))
dave at cridland.net
Wed Apr 26 07:58:08 UTC 2006
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
> 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
> ... and when it become dead, so the application is able to tell the
> which messages could be lost. We could save some bandwith by not
> too keep exact account of stanzas delivered to link peer, but
> application should be able to detect which stanzas were delivered
> sure and which could be lost. And the number of "probably lost"
> should never be too big, so there is no need to buffer too much
> 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