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.
