[Standards-JIG] reliabilty of sending data revisited (was: [jdev] tcp acknowledged sequence number)
thoutbeckers at splendo.com
Tue Oct 12 18:58:53 UTC 2004
(Crossposted to SJIG, since this involves protocol dev, orginal thread at:
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
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.
More information about the Standards