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='[EMAIL PROTECTED]/foo' > id='create1' > to='repeater.example.com' > type='set'> > <create xmlns='urn:xmpp:tmp:repeat' > for='[EMAIL PROTECTED]' > name='[EMAIL PROTECTED]'> > <jid>[EMAIL PROTECTED]</jid> > <jid>[EMAIL PROTECTED]</jid> > <jid>[EMAIL PROTECTED]</jid> > [ ... ] > <jid>[EMAIL PROTECTED]</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 [EMAIL PROTECTED] 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/
smime.p7s
Description: S/MIME Cryptographic Signature
