[Standards] Stanza Multicast Repeaters

Carlo v. Loesch CvL at mail.symlynX.com
Mon Mar 24 12:09:30 UTC 2008


Michal 'vorner' Vaner typeth:
| ? How to make sure there are no cycles.

Here's a snippet from RFC 1324 on the virtues of cyclic graphs
for multicasting. It was written after lessons learned in the
design of IRC.

5.4.2  Trees and cycles

   Due to the structure of the network being cyclic or forming loops, it
   is quite natural to want to emulate this within the protocol that is
   available for users. This has several advantages over trees, mainly
   the average path between any 2 nodes being shorter. A cyclic
   structure also poses many problems in getting messages delivered and
   keeping the connected users and servers up to date.  The main problem
   with using the tree model is that a break in one part of the tree
   needs to be communicated to all other parts of the tree to keep some
   sort of realism about it.  The problem here is that such
   communications happen quite often and a lot of bandwidth is
   needlessly generated. By implementing a protocol which supports a
   cyclic graph of its connectivity, breakages are less damaging except
   when it is a leaf or branch that breaks off.

I must add that this was written in consideration of IRC's notorious
netsplits, which are caused by IRC being one huge multicast tree,
frequently operating at the limits of its scalabilty - at least the
biggest networks are.

If we deploy local multicast trees for each multicast context, we are
a lot less likely to run into netsplit issues. Also, a "netsplit" on one
chatroom or newscast would not automatically affect all other multicasts
on the federation network as it does on an IRCnet.




More information about the Standards mailing list