[Standards-JIG] Re: Council decision on "Stanza Acking" proposal

David Waite dwaite at gmail.com
Sat Mar 26 03:28:55 UTC 2005

On Sat, 26 Mar 2005 03:30:10 +0100, Tijl Houtbeckers
<thoutbeckers at splendo.com> wrote:
> 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.

You probably mean low-impact; receiving a message and responding with
an ack is not complicated.

I actually agree that there should be a protocol level, hop-to-hop
keepalive 'ping' created (the other option would be to do what I
believe MSNP does - once a minute TCP keepalive messages, with the
number of send retries turned way down.) There are problems responding
to acks of course - the most significant is that XMPP is a stream
protocol with unbounded message size. If I'm transferring a file
in-band, it may be a while until I can respond to an ack.

The server needs to journal all incoming messages between responses to
server ack requests, cleaning the journal once a client response is
received. Does this affect feasability for s2s/

> 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.

I believe checking the tcp send buffer is a red herring, unless you
are able to somehow scan the tcp stack's frame windowing as well.

> >> 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...

I'll go ahead and add a point here. Whether a client is responding to
a ping once a minute or polling for messages once a minute, they are
still performing a request/response once a minute.

A ping is nothing but a server poll :P

> >
> > 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
> should be.

Interesting, so on client reconnect you would just replay all messages
since the last server-initiated ack was responded to?

-David Waite

More information about the Standards mailing list