<snip> >> As a matter of fact, this proto uses multicast (UDP) only for its >>heartbeat mechanism and unicast (TCP) for all the other activities. </snip>
I think i was a bit vague. No doubt, TCP is required for all p2p communications. However, when a server has a (sorted) list of live servers (LeaderNode-Node1-Node2 as in your example), it automatically knows its neighbours (Node1's nbrs are LeaderNode and Node2) and can communicate with them over TCP. Your idea of being able to create a bespoke topology is also good, but: a) Users should have the choice of not having to specify one (default topology). Otherwise the complexity of setting up the cluster could be too onerous. b) Un-trained users may end up creating a topology that is not resilient to failures eg consider a star with LeaderNode as the center and nodes N1, N2, N3 as spokes. If LeaderNode fails, which node becomes the center ? Who decides ? Is this configurable .... etc etc etc). Ideally the system should be able to identify topologies that have single points of failure. > This is a great idea. Actually, I had this thought a while back: for > each server, one configures an ordered list of servers. When a server > is started, the first N available servers are considered as their > "neighbours". A list of "prefered neighbours" - that may be a simpler configuration option v/s the definition of a topology
