[Standards] Stanza Multicast Repeaters

Carlo v. Loesch CvL at mail.symlynX.com
Sat Mar 22 13:00:58 UTC 2008


Michal 'vorner' Vaner typeth:
| I'm strictly against this kind of relying. I must trust my server and
| the recipient's server. But I do not have to trust any other server and
| let it know I'm sending something to some other server, even if I sent
| the same think to someone on this server too.

It's fine to be strictly against it, if you're running a standalone
server and do not trust anybody. If you trust a few people, than
developing a trust metric that allows a heterogeneous network to
build up multicast trees is still a tricky endeavour.

But there is also a totally trivial scenario. If all servers are
run by a single company, the trust issue is inexistent.

Considering that the current repeaters proposal already slashes down
presence traffic on a single route to its half (see fippo's stats),
employing true Multicast (with a big M to avoid confusion with 0033)
should bring about another 50% optimization on the network as a whole
(wild guess).

Considering that presence makes up >70% of stanzas on XMPP
(http://mailman.jabber.org/pipermail/standards-jig/2006-May/011158.html)
reducing that figure to a third or fourth means to reduce overall
XMPP to a half of what it is currently. And I haven't even started
considering MUC and PubSub multicasting.

| ? How to make sure there are no cycles.

"Multicast by repeaters" is a top-down approach where the original
sender decides whom to put in charge of what.
There are no cycles by design.

Making intentional use of cycles has potential, but I presume that
would be beyond what is good and useful for XMPP, not talking about
the huge effort adapting the protocol for that.




More information about the Standards mailing list