[Standards-JIG] Re: WHACK

Pavel Šimerda pavel.simerda.lists at centrum.cz
Sat Apr 29 10:53:52 UTC 2006

On 2006-04-29 08:08, Vinod Panicker wrote:
> Lots of mails exchanged on this subject.  Just taking a step backwards
> to analyse the problem statements once again -
> 1. 100% reliable message delivery
> 2. Usually reliable message delivery
> 3. Problems associated with clients that keep getting disconnected (GPRS)
> IMO, ACK's on a per hop basis solve problem 1.  Agreed that it is
> overkill for standard usage, but in some situations it may be
> necessary.

They don't do 100% but they prevent message loss in most of the situtations. 
There are only some cases like application failures. Or network isolation of 
the sender's server just after recieving message from sender and acking. 
Let's say it's almost 100%.

And it's not a big overhead. For a busy connection, you can confirm 20 or 30 
messages with one <ack:a n="20"/>. It's 15 characters to ack 20-30 (sometimes 
more) messages.

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

> 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 

> What the person would want is automatic delivery of messages that were
> "lost in transit", when the client moved from one cell site to
> another, in the process getting a new public ip and port.

This would work automatically. Server doesn't deliver the message, it falls 
back to offline storage (and reports the user's presence as offline). Client 
negotiates a new connection, sends presence online and gets the message.

The only problem is that the server doesn't know the message was NOT passed to 
the client.

Offline storage is great but it (unfortunately) depends on per-hop 

(Only when offline storage is forbidden or not supported, the user gets an 
error and the message is not delivered unless he retries himself.)

> Reconnection is a time consuming activity, and there is usually
> heartburn due to lost messages and manual synchronization.

> For this purpose, we could introduce a buffering proxy that such
> clients can use.  The gprs client would use such a proxy to connect to
> the xmpp server.  The proxy would hang on to the server connection
> even in case of a client disconnection for a matter of a few seconds.
> The client would usually come back with a different public ip/port and
> re-negotiate with the proxy.  Once that is successful, it would resume
> sending data to the server.  The proxy would buffer any data received
> from the server to the client after the re-connection.  If the client
> never comes back, the proxy replies to the server with errors and
> closes the stream.

With offline storage and stanza (or multi-stanza) acks, we'd have no need for 
a special proxy.

Btw, this does happen with gprs, but also with wifi, and some people also with 
dsl. I don't believe this is a minority problem. And it's quite grave. We're 
no better that any IM network it this respect.

> WDYAT?  We could start a new thread for problem 3.

> Regards,
> Vinod.


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

More information about the Standards mailing list