[Standards] Council on Stanza Repeaters without Multicast

Pedro Melo melo at simplicidade.org
Wed Apr 9 12:26:22 UTC 2008


On Apr 9, 2008, at 12:35 AM, Peter Saint-Andre wrote:
> Pedro Melo wrote:
>> On Apr 4, 2008, at 9:04 PM, Dave Cridland wrote:
>>> On Fri Apr  4 15:55:26 2008, Philipp Hancke wrote:
>>>>> 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.
>> Sure, but if a node owner is ok delegating the subscriber policy  
>> to the
>> remote proxies, why should a future spec prevent that?
> How do I know that a subscription request comes from a proxy? Does my
> pubsub service need to send a disco#info request to each subscriber in
> order to determine its identity, then ask me to approve the  
> subscription
> request if it comes from a proxy?

No. the local-proxy to origin-pubsubs subscription request is tagged  
with a "hey, this is a proxy subscription, I will rebroadcast your  
notifications to local subscribers"-namespace.

The origin-pubsub service can opt not to allow proxy subscriptions,  
of course, and in that situation the user should send the request  
directly to the origin-pubsub service.

>> Better: when I send a message to a remote proxy I could ask for a
>> "delivery report" message back, stating how many JIDs the message was
>> resent to.
>> So I can get one report per message I send and keep my bean-counters
>> happy. I know the reach of each message.
>> This could be an option in the initial response to the subscribe  
>> request
>> by the proxy or a per-message flag somewhere.
> I'd prefer it as a subscription option, because it's not *really*
> something you care about for each message, I think.

Given that the local subscription list at the local-proxy can change  
between notifications, the origin-pubsub-service might want to know  
his reach per message. I personally would not use this in a very  
active topic, but for things like blog updates-over-pubsub, it should  
be ok.

Again, its optional, and under the control of the origin-pubsub  
service either at subscription time or per notification.

>>> 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.
>> Yes. I agree with this.
>> And although its always nice to solve a lot of problems with a single
>> XEP, I would like to see the pubsub problem solved first, at least  
>> for
>> the public node scenario. I think that the experience we can get by
>> solving that will be useful to attack the others.
> I tend to agree that the most interesting use cases here are MUC and
> pubsub. Now, you could argue that MUC is just a specialized form of
> pubsub, but in reality it's different enough that we may need to  
> handle
> it separately.

Agreed. I just don't feel confortable discussing MUC because I have  
very little experience with large-scale MUC settings.

> Presence is just a specialized form of pubsub, too, as has been  
> pointed
> out many times before. But I'm not yet convinced that we need to tweak
> presence much.

Until we understand all the privacy-list restrictions on presence, I  
wouldn't either.

> Generalized solutions are appealing, but there's always the danger of
> over-generalizing.
> As I see it, MUC and pubsub already can be multicasted if you don't  
> mind
> having bots in your MUC rooms and pubsub services subscribed to pubsub
> nodes. Send to the bot or proxy and it distributes messages on the
> remote end. You can even chain those together. Granted we might want
> more elegant solutions, but these might be enough to get the job done
> for a while.

As should be obvious by now, I like local pubsub services acting as  
proxys for remote pubsub  services public nodes.

> Another approach: when you try to join a room or subscribe to a node,
> you are redirect to the local slave/proxy. We'd need better support  
> for
> the redirect error but that seems doable.

That's what I've been writing these past two weeks: you, the client,  
subscribe to a remote pubsub node, using your local pubsub service as  
a proxy. The second subscriber doesn't even need to bother the remote  
pubsub service.

Unless you mean that the redirect is "invisible to the user"... Like  
a transparent HTTP proxy. If thats the case, you should at least  
cache negative subscription-by-proxy responses.

Best regards,
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo at simplicidade.org

More information about the Standards mailing list