[Standards] Council on Stanza Repeaters without Multicast

Dave Cridland dave at cridland.net
Fri Apr 4 20:04:49 UTC 2008


On Fri Apr  4 15:55:26 2008, Philipp Hancke wrote:
> Dave Cridland wrote:
> [...]
>> Sure, I think everyone here does. I sincerely hope so, anyway - we  
>> will have significant impact here in the future.
> 
> We agree that messages should be sent only once per link?

Ideally, yes. In fact, ideally, less than once, although that's often  
difficult. (This isn't sarcasm - it is possible)



> [...]
>> You do, however, raise a very interesting point - you've said that  
>> in the current MUC case, there's no gain in using repeaters.
> 
> There are situations where there is no gain:
> * user joins
> * muc service modifies repeater
> * users leaves
> * muc service modifies repeater
> two repeater modifications for nothing. Separating the repeater
> modification from the actual protocol steps is something I dislike
> about repeaters.
> 
> 
No, any time the repeater expands to <= 2 jids, there's also no gain,  
and a significant hit on complexity. It's the complexity bit I'm  
worried about.

http://hancke.name/jabber/repeater-usage.html is great, by the way,  
but really does read to my eyes like an argument against them -  
hideously complicated.


> [...]
>> The result of solving them would be that PubSub would almost  
>> spontaneously grow directed acyclic routing, and this would be  
>> virtually transparent to clients, and to a large degree,  
>> transparent to servers. Note that this is more powerful than  
>> repeaters, as well as simpler.
> 
> As long as the local server (slave) rewrites the address to that of  
> the
> "master". Otherwise you have a usability problem ("but I want to  
> join
> jdev at conference.jabber.org, not 12431AFA at myserver"). Make it  
> transparent
> to the client.
> 
> 
Absolutely. This isn't terribly easy, unfortunately, since the local  
server has to do some clever handling of directed presence.


>> Again, we gain a lot from this. It's a simple design, and one that  
>> can potentially get us some resilience to failure, which is nice.  
>> And again, not my design, and not a particularly new suggestion.
> 
> IRC is there, you can't really come up with something brilliant new
> that can't be interpreted as "irc does it almost the same" ;-)
> 
> 
Well, absolutely. Although this is actually much closer to PSYC, as I  
understand it.


>> If we solve scalability in MUC and PubSub - and I think we can  
>> *without* repeaters, and I think that repeaters are not well  
>> understood, and may cause greater harm than good - then I think  
>> this is way beyond good enough. I believe that for both MUC and  
>> PubSub, using a slave entity which passes on subscriptions to a  
>> master entity, and manages 
> 
> may pass on for "open" nodes ;-)
> 
> 
I think MUST at all times.

First off, open nodes should get the statistics. This is arguably a  
political choice rather than technical, but I suspect that if a feed  
publisher knows there are several million subscribers, they'll make  
more effort in their XMPP strategy.

There is the technical argument that is that the policy of the node  
should be handled by the node, and not by a proxy.


>> redistribution backwards, will yield equal or high efficiency,  
>> with much simpler implementation, fewer security issues (in  
>> implementation or design), and will give us all the benefits of a  
>> tree-based heirarchical distribution without breaking any trust  
>> models.
> 
> You can apply the same master-slave design to presence.
> The recipient list modification operations will be different for the
> three use-cases, but the plan stays the same.
> 
> 
It's possible that we could, indeed I'd hate to say we never will,  
but I'm not sure the outlay in complexity covers it.

The trouble is that a pubsub node is, for want of a better term,  
network-transparent - its behaviour is essentially the same no matter  
what jid is talking to it. It's the same for MUC. Yes, there are  
different roles for each, but for the vast majority of tasks,  
everyone gets either the same data at the same time, or else none at  
all, and a third party can reliably predict which. Essentially, if a  
jid sends directed presence to a MUC jid, and doesn't get an error  
back - and a third party can often predict that, too - then it'll  
work.

Personal presence isn't like that, because there are secret things  
which can directly prevent the presence distribution, and there are  
also magical way of sending presence to people who never asked to  
subscribe. So although close, and usually equivalent, a third party  
cannot reliably determine which jids will be getting presence.

Now, the original Smart Presence was a design which assumed that  
personal presence was also network transparent. It also played a  
little too fast and loose with security models for my liking. It was  
updated (and I've said before, rather badly) into its more recent  
incarnation, which still doesn't really work. But, for all that, it  
was a very neat, very clean, design - I really liked everything about  
it except that it was broken.

A full solution to its woes would be essentially indistinguishable  
for Stanza Repeaters, so there's little point in doing so, but  
anyway, the point is that these three cases are not actually as  
similar as one might hope, and the case that has the highest cost in  
terms of complexity is also the one which has the lowest gain.

So I think the sane strategy is to simply ignore it for now. :-)


>> I don't think we'll have a problem scalaing presence, because I  
>> don't think it really needs to be scaled - it's neither  
>> low-hanging fruit, nor 
> 
> Buy two, get one free.
> 
> 
Why is it that people prefer the idea of "buy two get one free" to  
"2/3 price"? The supermarkets love it, of course, because the  
consumer ends up buying things they do not actually want - often,  
people will buy two just for the additional one, even though they  
only wanted one to begin with.

But, that short digression aside, we can get - using the same  
methodology, although a different protocol - good scaling on MUC and  
PubSub. We might get something similar on Presence and PEP, too, but  
I'm not holding my breath.


> [...]
>> Not least of which is that, if this went ahead, we'd probably feel  
>> under some obligation to use it in a MUC and/or PubSub scalability  
>> effort, and I happen to think it's entirely the wrong design for  
>> that - there are much cleaner designs.
> 
> I am going to curse you at night (in binary xmpp!) if I have to
> reactivate our old master/slave rooms and map them to XMPP!

I'm happy being cursed for the right reasons. :-)

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



More information about the Standards mailing list