[Standards-JIG] Reliable message delivery

Michal vorner Vaner michal.vaner at kdemail.net
Wed Apr 26 15:20:16 UTC 2006


On Wed, Apr 26, 2006 at 04:53:02PM +0200, Jean-Louis Seguineau wrote:
> Did you read anywhere in the post there was no hop in the path? Not that I
> can see ;) Two clients connected to the same server create two hops, isn't
> it? Two clients connected on two different servers with s2s in between is
> tree hops, right? To me, Hop-by-hop acknowledgement means each and every
> segment in the path has a separate and independent ack process. Whereas ack
> forwarding is the same ack being transmitted end to end through all hops.
> Just a semantic problem. I'm just saying having a separate ack process on
> each path segment between hops is heavier than forwarding the ack. Nothing
> more, and IMHO diffcult to deny it, right?

Well, if you want to route it, you need to parse it as well. Maybe you
do not add the sterilization of it again, but use the already accepted
one. Many servers must however add the 'from' and things like this, so
it is needed to rebuild it. So where is the 'heavier'? Another point
about hop acking is that you can ack group of stanzas, addressed to
different entities, at once, therefore saving.

The idea with hop acking is that reliable parts would not have to be
acked. If I have reliable connection burried underground with backup
connection by a satelite, then the possibility that the connection dies
is so low I do not need to care about it. On the other side, if I have a
connection that is broken every hour twice, I will take a good look for
a client that supports this to secure this problematic part. It is much
easier than persuading all 300 contacts I have to use a client that
supports end-to-end acking.

> On the actual number of stanzas, what are you trying to explain? Whenever an
> XML stanza is sent on a TCP segment, you have a process to mashall/unmarshal
> it at both ends of the path segment. So obviously, it is not the 'same'
> stanza. But this is a property of every stanza, isn't it? 
> 
> On the possibility to activate or deactivate the acking, I was under the
> impression we have this as a given. But if you have two hops, what would be
> the benefit of acking on a single path segment? Doesn't it defeat the entire
> purpose of acking?
> 
> -----Original Message-----
> Message: 6
> Date: Wed, 26 Apr 2006 21:13:04 +1000
> From: Trejkaz <trejkaz at trypticon.org>
> Subject: Re: [Standards-JIG] Reliable message delivery (the tcp
> 	problem)
> To: Jabber protocol discussion list <standards-jig at jabber.org>
> Message-ID: <29233422-76E9-4651-92F6-74E06CAAB72E at trypticon.org>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
> 
> -----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
> 
> 
> 

-- 

NAT should extinkt like dinosaurs did.

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060426/69fc4881/attachment.sig>


More information about the Standards mailing list