On Fri Nov 3 14:33:54 2006, Magnus Henoch wrote:
Jesus Cea <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
