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

Trejkaz trejkaz at trypticon.org
Wed Apr 26 11:13:04 UTC 2006


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


On 26/04/2006, at 03:23 AM, Jean-Louis Seguineau wrote:

> I agree with Peter on this one. Networks are not that bad nowadays  
> that we
> must have a hop by hop acknowledgement.

Clearly there is a hop somewhere, even one hop, which isn't as  
reliable as you claim.  Otherwise we wouldn't be here talking about  
reliable message delivery.

On 26/04/2006, at 02:38 AM, Peter Saint-Andre wrote:

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

You seem to be forgetting that your "1 ack" actually turns into three  
stanzas anyway.  Look:

1. My client sends a message intended for you.

2. My server routes the message to your server.

3. Your server routes the message to your client.

4. ACK #1: your client acks back to my client, but then...

5. ACK #1: your server routes the ack back to my server, and then...

6. ACK #1: my server routes the ack back to my client.

However, the per-hop approach does have one major advantage -- if a  
client doesn't think they need acking (see above) they can actually  
choose to opt out of it.  Also, if a person is paying for their  
bandwidth, they may choose to opt out of it.

In other words, in your numbered points, ACK#1 or ACK#3 may not have  
to happen.  (I suppose ACK#2 could be left out as well, but I bet  
that is where the majority of our messages are being eaten.)

TX

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFET1XEuMe8iwN+6nMRAmyyAJ99atTXPHAFCc/hryKNkXZam/PXtACgltNq
kDnmUuwMF6WHJ3o7cG6hu34=
=8IL3
-----END PGP SIGNATURE-----



More information about the Standards mailing list