Right. We wouldn't want the data to be replicated ad-nauseum until all resources are exhausted

At start-up, there would be no data. When the daemon issues a connect to another daemon, only then would the whole shebang be received once, and there after, the daemons in question would send only changes to the data.

I have also figured out how I would get each daemon to determine who connected to who first: using a configuration file listing IP addresses, I would have the daemon with the highest IP address be the listener, and treat the lower-addressed ones as the client. So if the running daemon sees it has a higher IP address than the rest, it will listen only. If it's somewhere in between within a range of listed addresses, it will listen for the lower addressed clients, but connect to the others since they are daemons.

Given that, I should have the daemons initiate the data push to the clients upon they connecting.

Whew!

Of course, I still need to look at everyone's suggested options.

Depending on how much control you have over the configuration, and how much "failover" you are willing to sustain, looking into the "peer-to-peer" mechanisms employed by git or even bittorrent (as far as there actually is documentation) might be educative.

The alternative is to have either a designated master and a tree hierarchy (and a single point of failure), possibly together with an "election scheme" to elect a new master if the current master goes offline. This is unfortunately also not trivial (see "irc netsplit" and bugs in the NT Domain Controller), but maybe you can provide enough configuration information (like IP addresses) where the master is determined by configuration. For example if you can assume that there is no malicious participant, the current master can yield to any master with a lower IP address (or whatever criteria).