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.
|
