[Standards] Stanza Multicast Repeaters

Carlo v. Loesch CvL at mail.symlynX.com
Fri Mar 21 22:40:08 UTC 2008


Congratulations. http://www.xmpp.org/extensions/inbox/repeaters.html is
the first XEP that can be employed for Multicasting in the correct sense
of the term. This is not irony, this is good news.

Look at a modified "Example 14. Repeater creation request" as follows:

<iq from='poweruser at example.net/foo'
    id='create1'
    to='repeater.example.com'
    type='set'>
  <create xmlns='urn:xmpp:tmp:repeat'
          for='poweruser at example.net'
          name='foo at repeater.example.com'>
    <jid>user0 at example.com</jid>
    <jid>user1 at example.ORG</jid>
    <jid>user2 at example.INT</jid>
    [ ... ]
    <jid>user99 at example.INT</jid>
  </create>
</iq>

Notice how i replaced some of the recipient server names with example.ORG
and example.INT. By doing so I am delegating parts of the distribution of
the stanza to a routing service. If that service, repeater.example.com, itself
allocates a repeater list to feed our stanza stream to repeater.example.INT,
we have effectively created a node in a Multicast tree in the true sense of
what Multicasting is supposed to be, and with the true benefits of what it
can achieve.

Should example.INT also put user1 at example.ORG into the repeater list sent
to repeater.example.INT, then repeater.example.INT would also turn into a
Multicast node, because it is forwarding things on our behalf to example.ORG,
thus reducing our load in data distribution.

We have thus delegated stanza delivery as follows:

    .net -> .com -> .int -> .org

Of course this is not a brilliant distribution architecture, but it is
very joyous news that any architecture is possible now. The next step
is to focus on how to build intelligent tree architectures.

This is just a protocol framework. Several issues need to be addressed,
to actually deploy true Multicasting by use of repeater chains:

* When is real Multicast of actual use?
** Be aware of network topology: When the sender is in Australia, it may
   want to ask the server in Switzerland to also inform the one in Austria.
** Heavy load on transmitting server makes it a scalability must to delegate
   delivery to subservers.
** Large data transfers make it a scalability must to delegate delivery
   to subservers.

* How can a receiving node trust a Multicast router, that it is
  rightly serving up information on behalf of somebody else?

* How can a node trust the sender, that it is a good idea to Multicast?
** Do user subscriptions give a hint at interdomain trust?
** Admin config?

* How can a subserver tell a server it is willing to relay?
** S2S "slave" negotiation?

* How can a sending server figure out which slave it should pass work onto?

* What are the best Multicast routing strategies?

* Is there any hope for PSYC's future if XMPP learns to Multicast for real?

I actually intended to write something like this two years ago, maybe
a bit more complicated, but got demotivated by the general reactions.
Now you created a Multicast framework yourself, even if the proto-XEP
doesn't pose any restrictions whether the <jid/>s kept in the repeater
need to be local (within the same domain) of the repeater, or not.
I guess you should forbid remote jids in repeaters until you have a
strategy to ensure the legitimacy of such Multicast repeaters.

This XEP has a lot of potential. It's the scalability fix that presence,
MUC and pubsub have been waiting for, and if XML weren't so file transfer
unfriendly, it could even be used to do media streaming.

Meow.



More information about the Standards mailing list