Re: A server that has a fool as its client: itself

Could it be that you confused 'client' and 'server' a few times. At least if you are talking about them in the network sense. If I get you correctly, the combo-client-server would wait for a change to happen locally, then contact (which only can be done as client) to some sibling of itself somewhere else (who listens as a server) and delivers the update to it

The most important question then is how to stop every server/client from trying to inform every other server/client and so generate traffic that grows quadratic with the number of servers.

Comment on Re: A server that has a fool as its client: itself

Replies are listed 'Best First'.
Re^2: A server that has a fool as its client: itself by Anonymous Monk on Feb 11, 2011 at 14:07 UTC
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.	[reply]
Re^3: A server that has a fool as its client: itself by Corion (Patriarch) on Feb 11, 2011 at 14:14 UTC
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).	[reply]