Liveness Checking Topologies
Many different liveness checking topologies can be used to implement FUSE. In this Section, we describe in detail the topology we chose: per-group spanning trees on an overlay network. We then discuss other topologies and their security/scalability tradeoffs.
Our overlay design requires a content-addressable overlay (e.g., DHTs such as CAN, Chord, Pastry, Skip- Net, or Tapestry [25, 34, 36, 39, 46]).The spanning tree for FUSE group y contains the group members A, D, and E, and two additional nodes, B and C, that we refer to as delegates. Delegates arise because the FUSE liveness checks are routed along overlay paths between members, and these paths may contain nodes that are not members. If overlay routes change or delegates fail, delegates may be added to or deleted from the live- ness checking tree; this repair process.
Building liveness checking trees on top of an overlay lets us reuse the liveness checks that the overlay uses to maintain its routing tables. The liveness checking tree for a given FUSE group is the union of the overlay routes be- tween the group creator (the root) and the group members. When multiple FUSE groups have overlapping trees, each overlay ping message monitors all FUSE groups whose liveness checking trees include that overlay link.
