[Standards-JIG] proto-JEP: Smart Presence Distribution

[Dave Cridland]

On Wed May 31 23:00:35 2006, Richard Dobson wrote:
> You can if its important both sides remain in sync, which in this 
> case it is as this protocol does not provide any mechanism to 
> recover from problems without having to start entirely from 
> scratch. Also it need not use up much bandwidth at all, as using an 
> IQ based protocol, you can easily bunch up all of your additions 
> and deletions into a single stanza and will only require a single 
> tiny IQ result ack, which could actually end up using less 
> bandwidth overall (or at worse not any more) than your proposal, 
> e.g. here is an example:

The problem with this example is that it's likely to compress worse 
than just sending the data anyway. It'll regain the loss over time, I 
think, but it will take a number of presence stanzas. Moreover, 
you've spent an extra round-trip, and it's quite likely this is much 
more of a problem than bandwidth for most circumstances.

And in case anyone frets about CPU usage for compression, bear in 
mind that we should be using TLS, and compression+encryption is lower 
CPU cost than encryption alone. Not that the CPU cost for compression 
is very much anyway.

My guess is that it'll be tricky to find any approach for this 
problem that doesn't either have serious security implications or is 
effectively compressed away. The amount of additional state required 
to support it is likely to be significant, too, because you're going 
to have one list (whether explicitly or implicitly defined) per 
external user who has any "buddy" on the server, plus one list per 
local user per remote server - all of this needs storage and 
tracking, and seems relatively expensive.

I'm sorry to pour cold water on a lot of discussion that's gone on 
here, and I do appreciate that a lot of thought has gone into these 
proposals, I just don't think they'll work out.

> You will also need to require a jep-ack type protocol as well as 
> the fixes to the cleanly closing of sockets, but yes, although I am 
> not sure what you will think of jep-ack and the related proposals 
> as they all require acking the traffic you send over the TCP 
> socket, which you seem to hate the idea of for some reason.

I hate it too, which is why I've proposed a solution that reduces it 
to minimal overhead.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade