[Standards-JIG] Re: Council decision on "Stanza Acking" proposal
Bart van Bragt
jabber at vanbragt.com
Fri Mar 25 22:05:28 UTC 2005
Peter Saint-Andre wrote:
> 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.
IMHO we're talking about an issue that shouldn't be downplayed so easily
:\ Computers crash, Laptops get out of WiFi coverage, network cables get
unplugged, servers die. Not once but thousands (millions?) of times each
day. Or just take a look at the jabber.org server in the past month. It
had quite a few outages where people appeared online but where messages
never arrived for whatever reason.
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
Delivery notifications are a sort of stop gap solution that works fairly
well as long as the other side supports them and if you're only
interested in <message>-es. IMO it would be very, very nice if there
would be some kind of protection against link breakages on a somewhat
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...
> 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. :-)
IMO the experiment then standardize process works pretty well for
clients but it's horrible for servers. How can you test something like
this when all you control is your client or your server? This needs
cooperation of a conciderable amount of people/groups which in the end
amounts to standardization :) At least to some extent... Experimenting
with most client side code is easy because you control both ends of the
> 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.
Well, what do we think is acceptable? 1 out of 100 messages getting
dropped? 1 in 1000? 1 in a million? IMO 1 in a million is starting to
get close and I wouldn't be surprised if the current drop rate would be
on or two orders of magnitude higher than that. But, indeed, I don't
have hard numbers. But there is also no evidence of this being 'just an
edge case' either :)
I guess the only way to actually measure this is by using the delivery
confirmation JEP. Which clients support that to this extent? IMO most
clients only support this JEP for the typing notification part?
More information about the Standards