[Standards-JIG] Re: WHACK
stpeter at jabber.org
Wed Apr 26 19:28:15 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
Dave Cridland wrote:
> On Wed Apr 26 16:12:25 2006, Michal vorner Vaner wrote:
>> On Wed, Apr 26, 2006 at 03:29:10PM +0100, Dave Cridland wrote:
>> > Secondly, if you never get an ACK, you don't know if the stanza you
>> > sent was lost, or the ACK was lost.
>> Well, but this is problem of quite any acking, thet if you do not get
>> ack, you do not know what of these two got lost. But, as said, it
>> happens only when the connection dies and I guess receiving a message
>> twice is generally better than not receiving it at all. And the more
>> probable thing on TCP (or whatever) is that the messages got lost, since
>> the acking would be in short sequence after the message.
> Yes, of course it only happens when the connection dies. But if the
> connection doesn't die, the data is never lost, and yet that's when all
> these ACKs happen.
> Now you say it's more probable that the message gets lost than the ACK,
> and I'd agree, but if we can avoid using probabilities to detirmine a
> reaction to a dead connection, I'll be much happier. If you want to go
> the ACK route, just call it "slightly less unreliable messaging
> extension" or something.
Does anyone have data on the reliability (or "unreliability" if you
like) of existing XMPP connections / networks? Slightly less unreliable
messaging might be enough for most people. 100% reliability may be too
difficult to achieve. In general I tend to think that perfection is not
> And it's possible to get actual reliability, and - I think - quite easy.
You mean 100% reliability?
> You just add an optional sequence number to each stanza, specific to a
> session, and the server keeps a note of what sequence number was last
> dealt with from which session, and when a client connects and explicitly
> requests that session identifier again, the server tells the client what
> it last dealt with.
This sounds quite similar to the Request IDs that we use in the HTTP
In XMPP, session identifiers are not requested by the client, they are
generated by the server. But we could have a protocol whereby the client
could request the last handled sequence number for its previous session.
> You can add an iq to get an explicit ack if you like, but it's not
> terribly important unless a series of large stanzas have just been
> transmitted by the client, in which case it might want to know when it
> can forget them. (It's also important if you need some assurance that
> the stanzas are being dealt with in a timely fashion).
But on your model the client can get the same assurance simply by asking
the server for the sequence number of the last stanza it handled, right?
> If you use these,
> you're actually getting ACKs, but if you don't, you're getting no extra
> packets, but yet you still get better reliability than a dumb ACK.
The "no extra packets" part seems pretty important on the kinds of
unreliable links that people are complaining about (GPRS etc.).
Jabber Software Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards