[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