Fwd: [Standards-JIG] Re: WHACK
mwild1+jig at gmail.com
Thu Apr 27 22:51:28 UTC 2006
---------- Forwarded message ----------
From: Matthew Wild <mwild1 at gmail.com>
Date: Apr 27, 2006 11:49 PM
Subject: Re: [Standards-JIG] Re: WHACK
To: Jabber protocol discussion list <standards-jig at jabber.org>
Wouldn't Richard's suggestion solve the same problem, with easier
Richard Dobson wrote:
The best thing to do if you detect a socket has timed out and you have
some message that may not have been delivered that are buffered up is to
simply deal with them as if they are messages received while off-line,
there is no need to add all the complexity in to deal with quick
reconnection's and the like, so if there are other resources available
messages will be forwarded to them otherwise they will be stored
off-line, and any directed IQs will be bounced back to sender.
On 4/27/06, Mridul Muralidharan <mridul at sun.com> wrote:
> Tijl Houtbeckers wrote:
> > On Wed, 26 Apr 2006 19:26:35 +0200, Mridul Muralidharan
> > < mridul at sun.com> wrote:
> >> Hi,
> >> Just to get my thoughts in order about this discussion :
> >> Sending of whack's is just to get around tcp implementation issues
> >> right ?
> >> What I mean is , there is no way to correlate which stanza's were
> >> received at the server (or the client) end given that sender received
> >> a whack.
> > "Whack" or something else based on JEP-ACK, uses acks, or "whacks" if
> > you like, for individual stanzas. That allows you to know exactly
> > what stanzas were at least received by the other end (wether it's a
> > server or the client), which solves the bulk the problems that people
> > keep bringing up here.
> If you have some form of id'ing each stanza which requires ack and use
> that in the ack , then yes we can find out which have been delivered and
> which have not.
> I dont see how whitespace ack will tell us upto which stanza the server
> recieved/processed - there would be stanza pipelining at both server and
> client side , and you could have unreliable intermediaries.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards