[Standards-JIG] Reliable message delivery (the tcp problem)
jean-louis.seguineau at laposte.net
Tue Apr 25 17:23:14 UTC 2006
I agree with Peter on this one. Networks are not that bad nowadays that we
must have a hop by hop acknowledgement. Using end to end ack forwarding is
much more efficient. It also does not mandate having the same return path as
the initial message.
And it is located at the application layer, which de-correlates as much as
possible the different responsibilities between application and transport.
Finally, why not imagine a server side support for this JEP? A server could
buffer the original message when received from the client, and discard it
when the ack is received from the target. Then the resending of the messages
could be entirely delegated to the servers nearest to each client. Kind of a
mixed approach with a nice degradation handling...
I also believe this JEP is well adapted to message delivery control in an
application to application context.
Date: Tue, 25 Apr 2006 10:38:51 -0600
From: Peter Saint-Andre <stpeter at jabber.org>
Subject: Re: [Standards-JIG] Reliable message delivery (the tcp
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <444E509B.4050907 at jabber.org>
Content-Type: text/plain; charset="iso-8859-1"
-----BEGIN PGP SIGNED MESSAGE-----
> 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
> client have to resend a message to the server if the message already made
> 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
> 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.
More information about the Standards