[Standards-JIG] Re: WHACK

Peter Saint-Andre stpeter at jabber.org
Wed Apr 26 19:28:15 UTC 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
an option.

> 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
Binding:

http://www.jabber.org/jeps/jep-0124.html#rids

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.).

Peter

- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFET8nPNF1RSzyt3NURAqc1AJ4rVZFtIPfDbqFlpz407InbZqb6YgCfSl5E
3rZzEd1s4NiL6G6qjE3udbw=
=LwIU
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060426/2a141933/attachment.bin>


More information about the Standards mailing list