[Standards-JIG] Re: WHACK
kevin at kismith.co.uk
Sat Apr 29 11:44:18 UTC 2006
On 29 Apr 2006, at 11:53, Pavel Šimerda wrote:
> On 2006-04-29 08:08, Vinod Panicker wrote:
>> 1. 100% reliable message delivery
>> IMO, ACK's on a per hop basis solve problem 1.
> They don't do 100% but they prevent message loss in most of the
Yeah, they do guarantee delivery. They don't say anything about what
happens after they're received, but they do guarantee that (you know
if) they get there.
> There are only some cases like application failures.
Then they've arrived, no? :) Servers can use transaction logs or
whatever to recover after a crash, which is outside the scope of this
proposal (but inside the accountability ideas).
> Or network isolation of
> the sender's server just after recieving message from sender and
That's fine, because the server will not get an ack when it sends the
message on, so will store it until it does :)
> Let's say it's almost 100%.
Let's stick with 100% ;)
>> For problem 2, we need something lightweight but something that sits
>> between whing and per-hop ack's. Maybe whacks are the answer.
> Yes, we can use dirty w-hacks to solve a xml protocol issue but....
> why should
> we do that? For several bytes of bandwidth? I'm now pasting again long
> portions of text I wrote when the connection was half-broken.
I started the conversation about whacks I'm afraid and they're a bad
idea, jep-ack is the way to go ;)
>> For problem 3, which is an extremely common problem when a client is
>> using a GPRS like connection, just letting the other party know that
>> the message was NOT delivered is not really a great user experience.
> Letting the other party know that the message really couldn't be
> delivered to
> the other user is imho important. And, to know what's going on, is
> a user's
There's no reason the client can't cache the messages and resend them
for a smoother user experience.
> The only problem is that the server doesn't know the message was
> NOT passed to
> the client.
The time between sending a stanza and receiving an ack is, even on
slow connections, not overly long. For c2s connections, I suspect
that the time between stanzas is much larger, generally, than the
time between stanza and ack. This means that odds are good that if
you get no ack, the other end got no stanza. If we're worried about
duplicate messages, we can even do things about that using cacheing
and a stream timeout, but this is a much less severe problem than
Psi Jabber client maintainer (http://psi-im.org/)
Postgraduate Research Student, Computer Science, University Of Exeter
More information about the Standards