Hmmm. Good point.
However, it is important that an aggregator quickly get its cache
coherent. If someone walks up to a newly rebooted aggreator, the
someone should either be told that this aggregator is not yet useful, or
the someone should get accurate data.
So, existing aggregators could unicast just their information to new
aggregators. Or each aggregator could delay a small amount of time
waiting for an older, more knowledgeable aggregator to multicast a copy
of the cache. Or a minimal amount of information is multicast by an
"old" aggregator, and the new aggregator then retrieves a copy of the
cache from the old aggregator.
There must be some sort of standard gossip protocol implementation of
this issue.
Cs
Alex Balk wrote:
As for resending data on whenever a new node appears on the multicast
channel, I haven't looked at the code (it's far too late at night to
do that now), but I hope that wasn't implemented the way you
describe... Think of a cluster with a few thousand nodes on one
channel (not the best idea probably probably) - a new node shows up
and everyone starts coughing their data on the wire. Add a really low
dmax value and a node rebooting every few minutes (or a bad
wire/switch/NIC) and you have a lovely little mess.
Alex
