[Standards-JIG] Reliable message delivery (the tcp problem)

Peter Saint-Andre stpeter at jabber.org
Tue Apr 25 16:38:51 UTC 2006

Hash: SHA1

Trejkaz wrote:
> On Tuesday 25 April 2006 03:49, Tony Finch wrote:
>> On Mon, 24 Apr 2006, Peter Saint-Andre wrote:
>>> It seems to me that JEP-0184 solves your three bad scenarios. My sense
>>> is that you don't like it because it is not "general" -- that is, it
>>> needs to be supported on each client and is not enforced by the servers.
>>> Is that accurate?
>> Of course the end-to-end argument says that is the only way to do it...
> Problem is that doing it end-to-end adds unnecessary traffic.  Why should a 
> client have to resend a message to the server if the message already made it 
> to the server?  To phrase it another way, if the server drops the message 
> before it can deliver it, the server is the one responsible for making up for 
> its error, not the client who already properly delivered it.

What is the definition of "unnecessary"? Personally I think that acking
every XML stanza at each step in the routing process is unnecessary. In
a typical architecture that would be:

1. My client sends a message intended for you.

2. ACK #1: my server acks back to my client.

3. My server routes the message to your server.

4. ACK #2: your server acks back to my server.

5. Your server routes the message to your client.

6. ACK #3: your client acks back to your server.

That's 3 acks compared to 1 ack in the end-to-end case. And presumably
people think we need to ack presence and IQs, too, whereas message
receipts apply to messages only (which IMHO is appropriate since the
other party must reply to an IQ with an error or a result, and presence
is a broadcast). Adding 3 acks for every IQ in a verbose protocol like
disco or Jingle is just insane, and IMHO quite unnecessary.

Furthermore, if you and I are chatting and I have requested message
receipts, then my client is best situated to know that you have not
acknowledged receipt of the 23rd message in our chat session. I realize
that the fault may lie with the connection between my server and your
server (or whatever), but the end-to-end argument would say that our two
clients are the parties that know and care about this, and that are in a
position to enforce it. Furthermore, if it is handled between the
clients then we also have a way to work around bad software in the
middle (e.g., the connection manager at your server catastrophically
fails before delivering the message to your client).

Finally, I again assert that very few people really care about reliable
message delivery and that very people will configure their IM clients to
require message receipts. This will further reduce the number of acks.

Conclusion: selectively acking some message stanzas end-to-end results
in a *lot* less unnecessary traffic than comprehensively acking all
message, presence, and IQ stanzas at each hop in the routing process.


- --
Peter Saint-Andre
Jabber Software Foundation

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

-------------- 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/20060425/ed5725fe/attachment.bin>

More information about the Standards mailing list