[jdev] Re: XMPP Ping method?

[Dave Cridland]

On Fri Nov  3 14:33:54 2006, Magnus Henoch wrote:
> Jesus Cea <jcea at argo.es> writes:
> 
> > Matthias Wimmer wrote:
> >> Well, I don't think that _this_ is a valid argument. It's not 
> the task
> >> of protocols to work around design restrictions in a language.
> >> If this would be the task of a protocol, we would need some 
> changes in
> >> the protocol to support flash as well.
> >
> > If you require a feature, and that feature is not available in the
> > implementation language, your are dead in the water.
> >
> > Same about OS support. How do you access the TCP window counters 
> in your
> > symbian smart-phone, for example?.
> >
> > This suggestion is not doable.
> 
> I think it is.  The systems that do not support such a feature would
> go along just like today; the others would have better ability to 
> send
> bounces for stanzas sent but not acknowledge.  That's a net win, as 
> I
> see it.

I don't think it works like that.

As I understand things, the OS might ACK TCP segments before they're 
delivered to the app, and certainly they'd be ACKed before the client 
might have delivered them to the user. Moreover, if they haven't been 
ACKed, you don't know they haven't been handled to completion by the 
client already - TCP segments don't get ACKed instantly, and the ACK 
itself can be lost.

Arguably, a mobile phone client might not want to app-level ACK a 
stanza until it's displayed it to the user, or written it to 
persistent storage, in case the battery runs out.

TCP's ACKs are designed to handle the ordering of packets, congestion 
control, and detecting a severed connection, and not to detect what 
data has formally made its way through to completion in the protocol 
layer. Adding ACKs, sequence counting, and pings to XMPP streams 
isn't duplicating the work at all, it's adding more functionality.

This is not to say that using any facility provided by the 
programming environment to allow you to detect TCP level ACKs is a 
bad thing, just that it you need to be very careful about what that 
means. (Which is basically that the data reached the other host, and 
very little more than that). If we can get something that provided 
app to app reliability, rather than hop to hop, that would provide a 
better quality of information. (As well as minimizing or eliminating 
duplicated stanzas on reconnection).

Oh, and also, the protocol purists will get upset at you for 
committing a layer violation - XMPP isn't supposed to know anything 
at all about the transport protocol it happens to be using.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade