[Standards-JIG] Re: Council decision on "Stanza Acking" proposal
thoutbeckers at splendo.com
Sat Mar 26 02:30:10 UTC 2005
On Sat, 26 Mar 2005 02:02:45 +0100, David Waite <dwaite at gmail.com> wrote:
> On Fri, 25 Mar 2005 23:05:28 +0100, Bart van Bragt <jabber at vanbragt.com>
>> If I send a message I either want this message to arrive or receive an
>> error message that states that this message didn't arrive at the
>> recipient. I had quite a few problems with this while I was still using
>> a (fairly overloaded) public MSN/ICQ transport (yeah, yeah, transports
>> are evil :D). I can tell you from experience that it's _extremely_
>> annoying to not know if your messages arrive intact. Didn't the person
>> on the other side respond because he's away? Is he ignoring your remark?
>> Is he just not interested into going into a specific topic that you
>> mention? Was he offended? Is he too busy? Or did the message get lost in
>> space somewhere?
> If the problem is not knowing whether a message arrived or not, the
> solution is not a hop-to-hop keepalive/ping/acknowledgement, but
> end-to-end acknowledgement of message receipt. Knowing that my message
> got to my local server tells me nothing about whether the message got
> to the final recipient.
However if every hop-to-hop path had half decent transmission control
(which acking would provide), you would get delivery OR an error in *most*
cases. It's true this does not give you any garantuees, but I dare to say
that 99% of current problems I have with Jabber for IM would disappear if
every unsafe connection would use this. If I want more than 99% I'd have
to go e2e, just as I'd have to for once-and-only-once. But really, I could
care less about that. The purpose of this proposal is to keep is simple.
And yes, I admit a percentage of those problems could be solved by better
using existing techniques. But as pointed out, they do not always work,
are not always available, and none would work as well as JEP-ACK would.
> Having me tell my local server that my
> connection is still alive does nothing to let the remote user know
> that my message arrived successfully.
Let's say I'm on a mobile GPRS client. You send me a message. My network
signal is gone before it arrives.
Old situation: Your message gets dumped into the APN proxies buffer. That
tells your Jabber server's TCP stack the TCP packet is reveiced. Now, if
you're lucky my server implements the hacky "whitespace ping" protocol and
will after some while detect I'm offline. If not you'll have to wait for
the APN timeout wich can be quite higher. So x number of minutes later
AFTER you send me a message you'll see me go offline.. *if* I'm on your
roster. So am I just rude or did your message dissappear somewhere? You'll
New situation: Your message gets dumped into the APN proxies buffer and
will be lost. But since my client will not ack it, after the ack-timeout
you will receive an error from my server that your message is not
This is a mobile example cause that's my field. The same could be true for
any type of proxy (like SOCKS, HTTPS CONNECT, JEP25, even the new HTTP
binding if it's stand alone and "dumb"). But it gets worse if I have a
server that does not check the TCP send buffer to see what got send (are
there any that DO?). It could be ANY client or ANY server then that spews
their messages into the black TCP hole.
You can see how JEP-ACK could greatly enhance the reliability, thus the
"trust" a user can place in Jabber. I think most of us here are not out to
solve the problem of e2e messaging. I'll have to with Bart's model here. 1
in 1000000 lost is better than 1 in 10000 lost is better than 1 in 1000
>> Reverting to HTTP on a mobile device makes everything horribly
>> inefficient because of the overhead and the fact that the mobile client
>> has to poll for updates (and polling is extremely evil in my book :D).
>> The nice thing about Jabber on a mobile device is that it costs close to
>> nothing as long as you're not doing anything (and as long as you don't
>> have a 500 user roster :D). IMO Jabber should just be able to handle a
>> dropped connection gracefully, simple clients...
> But XMPP oer TCP doesn't handle dropped connectiosn gracefully. The
> lifetime of your XMPP session is directly tied to the lifetime of your
> TCP session. There is no mechanism for 'resuming' a session on TCP,
> and I daresay TCP is poorly designed for when networking capabilities
> and stability changes often (such as a mobile phone.)
For mobiles I've been thinking for a while of implementing a new binding,
which is simply based TCP connections as they are now, that can be resumed
when dropped. without JEP-ACK or something like it I don't see much point
of doing that right now. Sure it's possible, but more complicated than it
More information about the Standards