[Standards-JIG] Re: What happened to the ACK proposal?

Mircea Bardac dev.list at mircea.bardac.net
Wed Aug 17 20:44:57 UTC 2005

On Wednesday 17 August 2005 23:07, 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

On Wednesday 17 August 2005 16:22, Tomasz Sterna wrote:
> It just relies on client responses.
> Every message sent to the client is buffered until recieving confirmation.
> Any data recieved from the client counts as a confirmation and the
> buffer is deleted.
> Assuming that the client sends <presence type="unavailable" /> and/or
> </stream:stream> every message is confirmed, even on client (proper)
> disconnection.
> If the c2s detects broken TCP stream (most probably after sending
> keepalive) the buffer of unconfirmed messages is backed-up to the
> session manager for storing in offline storage.

0. Let's assumea laggy connection... which might fail, since we're talking 
about ack-ing packets.

client-server connection
09:20:00 Client sends: presence=away
09:20:20 Server sends: message A from user1
09:20:21 Server sends: message B from groupchat1
09:20:22 Server sends: message C from groupchat2
09:21:00 Server receives: presence=away (1 minute lag) 
09:21:00 Server removes msg A,B,C from queue.
09:21:10 Client looses connection (no </stream> presence=unavailable)
THEORETICALLY, if the 1 minute lag would apply for both directions, at:
09:21:20 Client receives: message A from user1
09:21:21 Client receives: message B from groupchat1
09:21:22 Client receives: message C from groupchat2
which IS NOT going to happen.

On Wednesday 17 August 2005 23:07, Peter Saint-Andre wrote:
> So is this a protocol issue or an implementation issue?

Unfortunately, I don't find the WPJabber *implementation* very reliable 
especially when:
a) sometime bandwidth is not much && I haven't heard of effors for throttling 
XMPP when heavy HTTP access occurs on the same connection (good QoS rules 
might apply, if they'd be implemented in many... hmm.. ALL routers between 
client and server)

b) there are situations* when client sends a lot less than it receives => 
large buffers per connection server-side => big memory usage

* user in several conference rooms/bots

Well, that's the worst case scenario I could think of - too bad it is quite 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20050817/4ff220b2/attachment.sig>

More information about the Standards mailing list