[Standards-JIG] Re: Council decision on "Stanza Acking" proposal
thoutbeckers at splendo.com
Fri Mar 25 22:14:30 UTC 2005
On Fri, 25 Mar 2005 22:16:08 +0100, Peter Saint-Andre <stpeter at jabber.org>
> On Fri, Mar 25, 2005 at 04:54:31PM +0200, Stephen Marquard wrote:
>> It's hard to see how the problem can be called an "edge case" (with
>> increasing prevalence of wireless devices that go off the air without
>> notice, and notebooks that get hibernated).
> IMHO, devices that cannot maintain long-lived TCP connections should use
> a different stream binding (i.e., the HTTP binding defined in JEP-0124).
> And it seems to me that before a notebook computer switches to hibernate
> mode, it should be able to inform applications of that fact, so that a
> a Jabber client can end its session gracefully. Making modifications at
> the stream level in order to compensate for poorly written clients does
> not strike me as a good idea.
>> The council decision also seems to be a reversal of the practice of
>> establishing working protocols and then standardising them through IETF.
>> If everyone had waited for RFC3920 before writing any code, Jabber
>> wouldn't exist today.
> Actually, the true practice is working on some experimental code and
> then standardizing it through the appropriate means (either a JEP or an
> Internet-Draft). So feel free to experiment. :-)
> Finally, I really would be curious to know how serious a "problem" this
> is, as shown by hard numbers and actual statistics. So far, all we have
> is anecdotal evidence as far as I'm concerned.
What you're basically saying is that most clients can maintain "long
lived" TCP connections and close them gracefully. This indeed seems to the
assumption that RFC3920 is written. I'd say in practise however the
situation where this is actually true is probably closer to 0% than to
100%. Though most of the time you probably "can", there is no garantue. I
think most of us on this list who've used jabber for a while or run a
server know all about "ghost presence", users that appear to be online but
are really not.
To combat this behaviour there are some tricks, for example keeping track
of which bytes your TCP stack claims delivered. Apart from this not
working in the case of many proxies (both transparant and not
transparant), fairly common programming envoriment (eg Java) do not have
this functionality. Both harldy edge cases..
Another "trick" is sending those ping "whitespaces". This is of course not
official protocol either and it has it's own set of problems (eg. how do
you know wether a space is a "ping" or a "pong"?). Then there's
keep-alive. Again, bad behaviour with many types of proxies and not
available in all programming enviroments.
The final trick (works best if it's available) is not caring or pretending
it doesn't happen.
JEP-ACK standardizes these solutions. Not just for the TCP binding but for
any binding, since it's at the XMPP level. It's 100% optional, so if you
have a situation where you trust your IP enviroment, just don't care, or
you have a binding where it's not needed, no need to use it.
For those of us that do care, it allows more fine grained control over the
connection; you know which stanzas were delivered, unlike with hard time
outs, whitespace pings or keepalive. It'll also be available to every
programming enviroment that can do XMPP.
In the end, whether the number of clients (and servers) to benifit from
this is relativly small or big, if it greatly enhances the end user
experience even for that smaller group, I find that a good reason to have
a standardized protocol. Counting the number of times the requests for
something like this have come up though, and keeping an eye on how current
implementations deal (or rather, do not deal) with this problem, I think
it'd make more than a few developers and end users happy.
More information about the Standards