[Standards-JIG] Re: What happened to the ACK proposal?
dwaite at gmail.com
Thu Aug 18 04:07:54 UTC 2005
I suppose the WPJabber technique is better than nothing, but there is
loose correlation between data received and data sent. It assumes
sparse data transfers, responses from the client and fast delivery.
Add a client which does not respond immediately, or change the packet
transit time to 30 seconds and this doesn't look like as good a
solution. A better solution IMHO is to add keepalive requirements
directly to XMPP.
Just for people's information, my understanding is that the massive IM
services get around these tcp timeout issues by issuing TCP Keepalives
about once a minute, while simultaneously reducing the tcp retries
below spec and adding application support to handle disconnects
gracefully (such as retrying and waiting for a response before
updating the UI to indicate disconnection). They also have ack/nak
logic around message delivery, so that the client can represent
approximate delivery results.
On 8/17/05, Justin Karneges <justin-keyword-jabber.093179 at affinix.com> wrote:
> On Wednesday 17 August 2005 01:07 pm, Peter Saint-Andre wrote:
> > Jacek Konieczny wrote:
> > > Jabber could be much more reliable now if Jabber Council accepted the
> > > JEP instead of trying to be politically-correct and leaving that for
> > > IETF.
> > Based on the message from Tomasz Sterna, it sounds as if the Jabber
> > network would be much more reliable if everyone deployed WPJabber. :)
> > http://mail.jabber.org/pipermail/standards-jig/2005-August/008295.html
> > So is this a protocol issue or an implementation issue?
> This is a clever trick, however it makes some assumptions:
> 1) The recipient must send data to acknowledge a stanza. Since it does this
> unknowingly, this may not happen for a very long time. This means there is a
> potentially large window where a successfully received stanza is considered
> 2) There is no context between the stanza sent and the data from the
> recipient. This makes it possible for a race condition to occur, whereby
> both parties send data simultaneously, and the sender immediately considers
> his sent stanza to be acknowledged when it may not have been.
> In practice, this trick probably works alright, since most clients and servers
> send whitespace keep-alives and the chance of #2 happening is small. Even
> so, it is still a protocol issue. No matter how clever the implementation
> is, this issue won't be properly solved without some coordination from both
> sides of the stream.
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards