[Standards] Stanza Multicast Repeaters

Peter Saint-Andre 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'
>     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

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.

Heh.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080324/a5756624/attachment.bin>


More information about the Standards mailing list