Topology References - sahiltyagi4/FLORA_beta GitHub Wiki
Core Topologies
| Attribute | Centralized (Star) | Hierarchical (Tree) | Decentralized (Mesh) |
|---|---|---|---|
| Communication Flow | Server ā Clients | Clients ā Aggregator(s) ā Root server | Peer ā Peer |
| Coordination Model | Global coordinator | Multi-level aggregators | Distributed consensus |
| Synchronization | Default sync (async variants possible) | Typical sync (pipelined or hybrid async options) | Async |
| Trust Requirements | High trust in central server | Trust in intermediate and root nodes | Peer-level assurances (e.g., consensus / secure aggregation) |
| Fault Tolerance | Single point of failure | Partial failure (isolated subtrees) | High redundancy |
| Primary Use Cases | Healthcare federations, shared cloud services, cross-device mobile FL | Institutional federations, large-scale FL deployments | Blockchain FL, P2P collaboration, ad-hoc sensor networks |
Centralized Variants
| Attribute | Server-Driven | Client-Driven | Multi-Server |
|---|---|---|---|
| Communication Flow | Server ā Clients in fixed rounds | Clients ā Server on client triggers | Clients ā Coordinated server pool |
| Coordination Model | Server-initiated orchestration | Client-initiated orchestration | Coordinated aggregator pool (sharded / replicated) |
| Synchronization | Sync (round-based) | Async (event-driven) | Sync or Hybrid |
| Trust Requirements | High trust in central server | High trust in central server | Trust split across aggregator pool |
| Fault Tolerance | Single point of failure | Single point of failure, though brief outages can be masked by local buffering | Graceful degradation (fail-over ready) |
| Primary Use Cases | Cloud-hosted cross-silo FL, cross-device smartphone FL | Mobile/edge FL with irregular participation | Massive cross-device or federated IoT environments |
Hierarchical Variants
| Attribute | Balanced Tree | Unbalanced Tree | Dynamic Hierarchy |
|---|---|---|---|
| Communication Flow | Clients ā Fixed parent ā Server | Clients ā Adaptive parent ā Server | Clients dynamically re-assign to new parent(s) |
| Coordination Model | Uniform-level aggregation | Capacity-aware aggregation | Self-organizing hierarchy |
| Network Structure | Uniform branching factor | Variable branching by capability | Auto-reconfiguring topology |
| Synchronization | Sync | Sync | Hybrid |
| Fault Tolerance | Predictable scope (one subtree per failure) | Variable (branch-dependent) | Self-healing (automatic rerouting) |
| Primary Use Cases | Homogeneous datacenter clusters | Heterogeneous institutions (e.g., academic alliances) | Volatile edge networks, decentralized mesh overlays |
Decentralized Variants
| Attribute | Full Mesh | Partial Mesh | Gossip Protocol |
|---|---|---|---|
| Communication Flow | Each peer ā every other peer (all-to-all) | Each peer ā k neighbors (fixed subset) | Peers randomly ā other peers per round |
| Coordination Model | Fully decentralized consensus | Local consensus protocols | Probabilistic distributed control |
| Synchronization | Async | Async | Async |
| Fault Tolerance | Resilient but scalability-limited[^1] | Redundant; tolerates partial loss[^2] | High resilience via stochastic redundancy |
| Primary Use Cases | Academic research, secure blockchain FL | Institutional P2P learning (e.g., consortia FL) | Large-scale FL (mobile, sensor networks) |
[^1] Full Mesh: Requires O(nĀ²) links; practical scale tops out at a few hundred peers.
[^2] Partial Mesh: Resilience increases with chosen neighbor count k and overall network diameter.