[Standards] Stanza Multicast Repeaters
stpeter at stpeter.im
Mon Mar 24 16:07:50 UTC 2008
Carlo v. Loesch wrote:
> 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'
> <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>
> 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
Yes this is possible as the spec is written right now, but it's not
called out because I think it's important to tread carefully here. :)
> 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.
Yes, something like that seems appropriate.
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards