[Standards-JIG] proto-JEP: Smart Presence Distribution
dave at cridland.net
Thu Jun 1 08:12:38 UTC 2006
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 Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards