[Standards-JIG] Re: WHACK

Kevin Smith 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  
> situtations.
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  
> acking.
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
> desire.
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  
losing messages.


Kevin Smith
Psi Jabber client maintainer (http://psi-im.org/)
Postgraduate Research Student, Computer Science, University Of Exeter

More information about the Standards mailing list