[Standards-JIG] Re: The Ack Hack.
Michal vorner Vaner
michal.vaner at kdemail.net
Sat May 13 12:17:34 UTC 2006
On Sat, May 13, 2006 at 10:01:11AM +0200, Pavel Šimerda wrote:
> On 2006-05-13 09:44, Trejkaz wrote:
> > On 13/05/2006, at 17:25 PM, Pavel Šimerda wrote:
> > > On 2006-05-13 03:26, Trejkaz wrote:
> > >> On Friday 12 May 2006 01:28, Pavel Šimerda wrote:
> > >>> I don't know what whitespace pings really do aside from sending
> > >>> whitespace, which is not enough.
> > >>
> > >> All it does is gives faster disconnection, that's right. And even
> > >> then,
> > >> you really need both sides to be doing it, to get any kind of
> > >> reliability.
> > >
> > > How does it do faster disconnection... is it in some way a ping-
> > > response
> > > mechanism? I can't find any docs for this...
> > Suppose my client sends a whitespace ping once every minute.
> > The server could then assume that no data received in two minutes
> > means my connection is having problems, and disconnect me earlier
> > than it would take the actual connection to terminate by itself.
> > TX
> So the server expects the whitespace pings regularly. Once it gets several
> whitespace pings, it expects more of them regularly. Sort of watchdog I
> understood well. Still it doesn't work for me (psi, ejabberd).
No, it does not expect them, it can not since it is not part of any
standard or JEP. It is perfectly OK to send some whitespace between xml
elements. It only:
* keeps NAT open
* Forces the dead connection to be detected as dead, since the
* whitespace can not be delivered.
> Still whitespace pings are not well documented, and xml pings look better to
> me (in the way they are defined in jep-ack). It perfectly supplements the
> message acking mechanism. And... I'd be happy to get rid of all whitespace
> stuff in the protocol.
Work with computer has 2 phases. First, computer waits for the user to tell it what
to do, then the user waits for the computer to do it. Therefore, computer work
consists mostly of waiting.
Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards