Round Coordinator

In Flower, the Round Coordinator logic is encapsulated within a Strategy object. The framework's Server calls the strategy's methods at each stage of a round:

• configure_fit(): Selects clients and configures their local training task.
• aggregate_fit(): Aggregates the collected model updates.
• configure_evaluate() & aggregate_evaluate(): Optionally manage evaluation rounds. This design cleanly separates the orchestration engine from the round policy, allowing engineers to implement custom coordination logic by subclassing the FedAvg strategy.

TensorFlow Federated (TFF) models the entire federated learning process as a stateful IterativeProcess. The Round Coordinator is implicitly defined within the next() function of this process. TFF uses a functional programming model where the round logic is a tff.Computation.

• The computation defines the server state transition: (server_state, client_data) -> (updated_server_state, metrics).
• This includes client sampling, broadcast, client work (simulated or remote), and aggregation. The framework's tff.learning module provides builders (e.g., build_federated_averaging_process) that construct these computations, abstracting the coordinator's implementation.

In the PySyft ecosystem, coordination is distributed across node types in a Web3-inspired architecture.

• A Network node acts as the central orchestrator, hosting the global model and running the aggregation protocol.
• Domain nodes manage groups of Worker devices (clients). The Round Coordinator's role is split: The Network initiates rounds and performs final aggregation, while Domain nodes handle sub-coordination—selecting workers, distributing tasks, and performing intermediate aggregation. This enables hierarchical and cross-silo federation models.

IBM FL employs a clear two-component architecture for round coordination.

• The Aggregator is the server-side coordinator. It runs the main training loop, calling start_round(), which involves tasking Party nodes and later aggregating their updates via a defined Fusion algorithm.
• The Party is the client-side component that receives tasks, trains locally, and returns updates. The framework provides a pluggable ProtoHandler for communication (gRPC, HTTP) and Fusion classes (e.g., IterativeAvgFusion) for aggregation, making the coordinator's communication and logic components modular.

NVIDIA FLARE (NVFlare) implements the Round Coordinator as part of a Controller that executes a workflow defined in XML. A <WORKFLOW> contains a sequence of <TASK> directives.

• A round is typically a <Repeat> block containing tasks like SubmitUpdateTask (client training) and AggregateTask.
• The Controller interprets this workflow, dispatches tasks to the FL Client agents via a message bus, and collects results. This declarative, workflow-driven approach allows complex multi-step rounds (e.g., train, then validate, then adjust hyperparameters) to be specified in configuration, separating the coordination engine from the round's business logic.

FATE's coordinator is deeply integrated with its data pipeline and heterogeneous transfer learning support. A federated job is described in a DSL (JSON or Python).

• A Pipeline object defines the data transformation and model training components across parties (Guest, Host, Arbiter).
• The FATE Flow service is the job scheduler and coordinator. It interprets the pipeline, submits tasks to the FATE Board for scheduling, and manages the execution of components across the federated cluster. Coordination here is less about simple round loops and more about managing directed acyclic graphs (DAGs) of interdependent tasks across multiple organizational parties, supporting complex vertical federated learning scenarios.