On Tue, Mar 31, 2009 at 05:36:59PM +0100, Dave Cridland wrote: > On Tue Mar 31 16:00:20 2009, Pedro Melo wrote: >> 1) as much as you have right now: remote servers can do whatever they >> want with your presence, you have no control after they leave your own >> server (a pessimist would even say that you don't have any control >> after they leave your client); >> >> > Well, there's trust, and responsibility. If a contact has an outright > evil server, there's little you can do - similarly if your own server, or > even client, is subverted. For things like this, it's really game over. > We generally choose to model a trusted client and a trusted server, > although we assume an untrusted server for content in the case of e2e > encryption. > > But then there's responsibility - right now, it's inarguably your local > server which enforces who gets your presence, and a reverse-roster lookup > causes immediate problems there - if people don't get to see your > presence (or worse, do when they shouldn't), you've then got two places > to debug instead of one. > > >> 2) if subscription state gets out of sync, the protocol will behave >> better or worse than the current version :), it really depends which >> roster is correct. There was a thread 2 or 3 weeks back with a >> tentative solution to keep subscription state in sync using the >> initial <presence type="probe" />. >> >> > I'm not sure your initial analysis is correct, and it's related to the > above comments I make - if rosters are out of sync now, while it's tricky > to discover, you know where the blame lies instantly in each case. > > And a rough analysis suggests that in the current situation, you'll > either get presence when you *no longer* wanted it, or else you won't > get presence when you want it. With a reverse roster lookup, it's > possible to end up in a situation where you'll get presence when the
If the server does route the wrong information to the wrong people it's buggy. With a reverse roster lookup on a corrupted database anything might happen. I don't get why this would justify the horrible amount of redundant information that is sent. I want to tell my 10 contacts on jabber.org that I am online. So sending 1 stanza will be 10 times less parsing, less bandwith, less CPU cost for compression, than sending 10. That factor scales with the number of contacts on a roster, which is linear, which is incredibly bad for something that can be accomplished with O(1) complexity. If the problem is synchronization of subscription states, well, then fix the problem with synchronization of subscription states. > sender doesn't want you to, which is substantially worse, and without > any bad actor involved. (I could be wrong here, please check this.) So we argue to "optimize" the protocol for this case? "Hmm, the other side might get information I didn't want to tell him, well, lets send it 10 times instead of once. I guess that will 'fix' the problem." I understand what you mean: Going from 10 to 1 message will indeed be a privacy problem in case of lost 'unsubscribed' stanzas. But the solution is to ask why the unsubscribed stanza was lost. XEP-0198 will address at least parts of this problem. >> But let me clarify something: although the bandwidth and processing >> savings of a multi-cast approach to presence distribution should be >> relevant, I don't believe this is compatible with a lot of other >> protocols that we have, so although I think multi-cast presence is a >> worthy long-term goal, I don't think we are ready to address it at >> this moment. > > We have this famous thing about ~87% (the figure varies) of traffic > being presence, and I'm afraid I think these figures skew vastly the > moment compression takes effect, since, by the very nature of the data > we're sending, it compresses really well. In fact, I'm not sure that it's > even worth worrying about as a problem, given how well this should > compress. Oh yay, let's burn some more CPU cycles, energy is sooo cheap. Everytime you send out 10 instead of 1 presence stanzas an additional amount of warmth is added to the global warming. Compression is a good optimization if you don't have anything else to save anymore and really want to pay for the CPU time. But in this case, wouldn't be preventing the redundancy in the first place be more beneficial in the overall performance? > I basically refuse to consider any solution seriously unless you're > measuring the effects of it post-compression - and I agree that's hard. Everytime you compress a redundant presence stanza a tree dies. Please think of the trees. Robin -- Robin Redeker | Deliantra, the free code+content MORPG [email protected] / [email protected] | http://www.deliantra.net http://www.ta-sa.org/ |
