[Standards] Council on Stanza Repeaters without Multicast
dave at cridland.net
Wed Apr 9 10:40:33 UTC 2008
On Wed Apr 9 00:35:30 2008, 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
> >>>> 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
> >> publisher knows there are several million subscribers, they'll
> >> more effort in their XMPP strategy.
> >> There is the technical argument that is that the policy of the
> >> 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
> pubsub service need to send a disco#info request to each subscriber
> order to determine its identity, then ask me to approve the
> request if it comes from a proxy?
I think the subscription request would be marked, to indicate that
the subscription request was from a proxy. This in turn suggests that
the proxy service needs to disco the master service. What I actually
see happening is:
a) Client sends initial request to an unknown service.
b) Local server intercepts this, and does disco to unknown service.
If it's a master-capable service, then the client's request is
modified to include a proxy.
c) Remote service responds - if this is a proxy request, and the
remote service doesn't wish to have it involved, it can say so at
d) Remote service sends out data, either to proxy service or to user
directly as required.
Note I've carefully avoided saying either of "MUC directed presence"
or "PubSub subscription" - the model itself applies to both equally,
although its implementation and syntax will differ.
What I'm particularly interested in is whether some of this disco can
be elided by the use of the feature-level XEP-0115.
> > 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
> > resent to.
> > So I can get one report per message I send and keep my
> > happy. I know the reach of each message.
> > This could be an option in the initial response to the subscribe
> > 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.
I'd have thought that, if the master is always aware of the numbers
of subscriptions, this is less important. It could be, though, that
errors are passed back.
> 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
> it separately.
I think they are the same in most respects, but the syntax differs.
MUC+PubSub can be handled by the same protocol model in different
> Presence is just a specialized form of pubsub, too, as has been
> out many times before. But I'm not yet convinced that we need to
> presence much.
The trouble is, I disagree - presence has a different model, because
privacy lists and directed presence lead to a distinction between
subscriber and receiver.
> Generalized solutions are appealing, but there's always the danger
In general, one should never over-generalize.
> As I see it, MUC and pubsub already can be multicasted if you don't
> having bots in your MUC rooms and pubsub services subscribed to
> 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
> for a while.
Indeed, and what we're talking about is just refining this a bit.
> Another approach: when you try to join a room or subscribe to a
> you are redirect to the local slave/proxy. We'd need better support
> the redirect error but that seems doable.
I think we intercept, mimic, and fool the client into thinking it's
talking to the master service at all times.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards