reliabilty of sending data revisited (was: [jdev] tcp acknowledged sequence number)

[Tijl Houtbeckers]

(Crossposted to SJIG, since this involves protocol dev, orginal thread at:
https://www.jabber.org/jdev/2004-October/019398.html )

On Tue, 12 Oct 2004 20:17:40 +0200, Jacek Konieczny <jajcus at bnet.pl> wrote:
>
> On Tue, Oct 12, 2004 at 09:31:46PM +0400, Alexey Nezhdanov wrote:
>> When time out will be hit - connection will broke so I need to know
>> wich packet was delivered last and wich were just dropped by tcp/ip  
>> stack to
>> re-send them later when client come back online.
>
> You may always use one of the JEPs providing delivery notifications
> (JEP-12 or JEP-79) provided the recipient client supports the extension.

I assume you mean JEP-22 instead of 12. I've read JEP-79 a few more times  
when it was in last call, and it doesn't seem to me like it's meant to  
provide delivery notifications. It's only meant to provide notifications  
when your delivery condition is NOT matched. AMP is also meant just for  
servers, not clients and AMP SHOULD give an error (and drop your packet)  
or notification (and route your packets) -depending on what you specified  
with AMP- when a server tries to route your packet to another server that  
does not support AMP.

So AMP will just make sure your message is treated correctly (doesn't go  
to the wrong resource or storage etc.) and you'll get a notification or  
error when it's not. But even when one AMP server sends a message to  
another AMP server the message can still get lost, or indeed the  
notification/error itself can get lost. You'll still need hop to hop  
reliability or use and end-to-end solution like JEP-22. But such an  
end-to-end solution is a lot more work for a client to implement, and only  
works for messages. The advantage being it will work anywhere anytime no  
matter what your server version is. Also JEP-22 is not standards-track  
(yet?). And I wonder how many clients that use JEP-22 for "composing" also  
support also support delivery notifications (that might make disco a  
little hard)

What I think would be usefull start is a hop-to-hop mechanism like JEP-ACK  
(securing every stanza) and a new AMP delivery condition that will notify  
you / give an error when your message is routed onto a path with no  
JEP-ACK availiable and one for when delivery fails.

This would covers messages (obviously), IQ queries already have their  
mechinism (though this could speed it up a bit), and presence really just  
needs to reach your own server so that's just one "hop" (from there on  
it's the servers' problems). This way you can still communicate with  
everyone and benefit from reliability where it's available, and you'll be  
warned when there is a potential "black hole" in the path.

It's no substition for true end-to-end reliability, just once delivery  
etc. but it would make the network a lot more robust.

> Any other solution (when the client doesn't notify delivery success)
> will not be 100% reliable. TCP ack doesn't mean the client read the data
> from the socket buffer or its internall IO buffer.

Very true. Plus there is no way to know if the other side on a  
bi-directional socket has acces to / uses simuliar techniques.