[Standards] Council on Stanza Repeaters without Multicast

Carlo v. Loesch CvL at mail.symlynX.com
Wed Apr 9 08:08:05 UTC 2008

Peter Saint-Andre typeth:
| > 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.


| 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.

Since presence is causing those 47% overhead stanzas on the XMPP
network, why are you postponing the #1 scalability problem of XMPP
again, and put things first, which aren't even used *because* they
don't scale?

| 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.

Oh I see you follow our discussion a lot.

| 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

Hey, clients are multicast points, too.. Yippie.. why don't you
redirect onto some public ports of your clients? Then you can ask
people to run clients just for the sake of setting up a multicast
tree and everything is fine and you got away without a new properly
designed interserver routing protocol, just a bunch of shaky band-aids.

This scenario isn't even so out of this world.. it's what other people
call P2P, but it shouldn't involve 3 different distribution mechanisms
(muc + pubsub + resource "routing"). It should have a clean single
multicast routing strategy that reaches all the way from the chatroom
master down to hundreds of thousands of clients, if necessary. And if
the routing protocol is clean enough, it doesn't matter if an
intermediate node is a federation server or a P2P-acting client.
It becomes a question of trust, which is up to the subscribing user
to decide. If I trust the client of my friend sitting next to me, why
not? Why transfer the same stuff over my network uplink twice, then?

Concerning <redirect/> - I've had several situations where I wanted
to automatically send clients elsewhere, but had to see that none of
the clients implement <redirect/> that way, because nobody told them to.
So you could do us a favor and write up a best practices for redirect
while we think about fixing the scalability issue properly.

More information about the Standards mailing list