[Standards-JIG] Re: WHACK

Pavel Šimerda pavel.simerda.lists at centrum.cz
Sun Apr 30 07:24:04 UTC 2006

On 2006-04-29 13:44, Kevin Smith wrote:
> 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% ;)

Alright, you hit all the issues, it's really out of the scope... and if the 
servers and clients are 100% reliable... this also means 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 ;)

"whitespace (h)acks" is a workaround. I didn't like it from the beginning.

But the more ideas we have, the more we choose from. Jep-ack looks the only 
reasonable way, currently.

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

And there's no reason to make proxies for all people who want better 
delivery... it's not only GPRS, as I said before, it can be even on DSL 
depending on your ISP.

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

But if you were really afraid of higher bandwidth.... you can secure the cases 
when a client gets many stanzas in short time. E.g. joining a large groupchat 
(e.g. through IRC transport). Or connecting.

The cases when you're recieving many <presence/> and <message/> stanzas... you 
just ack them at once (with one ack element).

Single messages (when you're writing time by time) will be confirmed 

Keep it simple... http://www.pavlix.net/

More information about the Standards mailing list