Communication réseau de Flower

Cette référence complète l’explication du Flower Architecture en détaillant les connexions réseau utilisées dans un système Flower d’IA collaborative déployé.

Note

Optionnellement, un troisième lien vers un service tiers peut être établi pour fournir une authentification utilisateur via OIDC. Cela signifie que seuls les utilisateurs authentifiés via flwr login peuvent interagir avec le contrôFlower.

Subprocess Mode Process Mode

Astuce

Cliquez sur les boutons ci-dessus pour basculer entre les diagrammes de réseau pour les modes d’isolement subprocess et process.

Connexions réseau obligatoires

Les systèmes Flower déployés ont au moins deux types de connexions réseau :

• CLI vers SuperLink (Control API) : la commande CLI flwr, généralement exécutée sur le poste de travail de l’utilisateur, sert à interagir avec une fédération Flower déployée composée de SuperLink et de SuperNodes. Du point de vue réseau, la CLI flwr agit comme un client gRPC et SuperLink agit comme un serveur gRPC. La CLI flwr est le seul moyen pour un utilisateur (chercheur en IA ou data scientist) d’interagir avec une fédération Flower déployée. Il ne peut pas, par exemple, interagir directement avec les SuperNodes connectés au SuperLink. La connexion de la CLI flwr à SuperLink doit toujours utiliser TLS, mais le mode insecure est pris en charge pour les tests locaux.

• SuperNode vers SuperLink (Fleet API) : dans la terminologie Flower, une fédération Flower est un ensemble de SuperNodes connectés au même SuperLink. Du point de vue réseau, chaque SuperNode agit comme un client gRPC et SuperLink agit comme un serveur gRPC. Cela signifie que, lors du déploiement d’un SuperNode, seules des connexions sortantes sont nécessaires pour se connecter au SuperLink. Seuls les SuperNodes peuvent initier ces requêtes et ils ne répondent pas aux requêtes entrantes. La connexion de SuperNode à SuperLink doit toujours utiliser TLS (consultez Activer les connexions TLS pour en savoir plus), mais le mode insecure est pris en charge pour les tests locaux.

Connexions réseau facultatives

En fonction de la configuration SuperLink et SuperNode, les systèmes Flower peuvent avoir/employer un certain nombre supplémentaire de connexions réseau.

API des composants Flower

All Flower components — SuperLink, SuperNode, SuperExec, ServerApp process, and ClientApp process — expose APIs to interact with other Flower components. The SuperLink component includes three such APIs: the Runtime API, Fleet API, and the Control API. The SuperNode component independently hosts the same Runtime API contract. Each API serves a distinct purpose when running a Flower app using the deployment runtime, as summarized in the table below.

Composant	Port par défaut	API	Objectif
SuperLink	9091	Runtime API	Utilisé par les processus SuperExec et les processus ServerApp
	9092	Fleet API	Utilisé par les SuperNodes
	9093	Contrôle API	L’utilisateur interagit avec le SuperLink via cette API en utilisant le FlowerCLI
SuperNode	9094	Runtime API	Utilisé par les processus SuperExec et ClientApp,

Note

Runtime APIs enforce runtime version compatibility between the API server and their callers. By default, requests from callers using an incompatible major.minor runtime version are rejected before Runtime API communication proceeds. Older callers without runtime metadata are currently accepted by this compatibility check for backward compatibility. Keep the SuperLink, SuperNode, SuperExec, ServerApp, and ClientApp runtime components on compatible Flower versions.

Mode d’isolement

Les deux processus SuperLink et SuperNode peuvent fonctionner dans différents modes d’isolement. Le SuperExec est responsable de la planification, du lancement et de la gestion des processus d’applications, tels que le processus ServerApp et le processus ClientApp.

La configuration de mode d’isolement subprocess configure le SuperLink/SuperNode pour lancer automatiquement le SuperExec en tant que processus subprocessuel à l’exécution. Le mode d’isolement process, par contraste, s’attend à ce que le SuperExec fonctionne dans un processus externe géré séparément, de sorte que le SuperLink/SuperNode ne lancera pas automatiquement un tel processus. Cela permet, par exemple, d’exécuter les SuperLink/SuperNode et SuperExec dans des conteneurs Docker distincts avec des ensembles de dépendances différents, ou d’y exécuter sur différents serveurs au sein du même réseau. Consultez le guide Exécuter Flower à l’aide de Docker pour une compréhension plus approfondie de la façon dont utiliser les deux modes.

Lorsque vous utilisez le mode d’isolement process, des connexions réseau supplémentaires sont nécessaires pour permettre au processus externe exécutant le SuperExec, ServerApp ou ClientApp de communiquer avec le SuperLink ou SuperNode:

• SuperExec/ServerApp process to SuperLink (Runtime API): Both the SuperExec for ServerApps and the ServerApp processes act as gRPC clients and connect to the SuperLink’s Runtime API. This connection enables the SuperExec to discover runs to launch and the ServerApp process to pull the necessary inputs to execute the ServerApp. It also allows the ServerApp, once running, to do typical things like sending/receiving messages to/from available SuperNodes (via the SuperLink).

• SuperExec/ClientApp process to SuperNode (Runtime API): Both the SuperExec for ClientApps and the ClientApp processes act as gRPC clients and connect to the SuperNode’s Runtime API. This connection enables the SuperExec to discover runs to launch and the ClientApp process to pull the necessary details (e.g., FAB file) to execute the ClientApp, execute the ClientApp (e.g., local model training), and return the execution results (e.g., locally update model parameters) to the SuperNode.

Note

The Runtime API links above can run with plaintext communication or with server-authenticated TLS. Without the --appio-ssl-* options, these links remain unencrypted and should stay inside a trusted network:

• Processus SuperLink + SuperExec + ServerApp

• Processus SuperNode + SuperExec + ClientApp

To secure these links, configure the SuperLink and SuperNode Runtime API servers with --appio-ssl-certfile, --appio-ssl-keyfile, and --appio-ssl-ca-certfile. Runtime API clients verify server certificates with --root-certificates. In subprocess isolation mode, the SuperLink and SuperNode pass the CA path to the SuperExec processes they launch. This is not mTLS. See Activer les connexions TLS for concrete commands.

Avertissement

Lorsqu’il est lancé sans TLS, chaque groupe doit rester dans un réseau de confiance unique. Ils ne devraient jamais communiquer entre eux sur des réseaux non fiables (par exemple, Internet public).

Authentification de compte

Lorsque l’authentification de compte est activée, Flower utilise un serveur compatible OIDC pour authentifier les requêtes :

• SuperLink vers le serveur OIDC : Un SuperLink peut être configuré pour ne permettre que des utilisateurs authentifiés d’y interagir. Dans ce cas, le SuperLink Flower agit comme client REST vers le serveur OIDC compatible.

Connexions spécifiques à l’application

Les utilisateurs qui créent des applications Flower (ServerApp et ClientApp) peuvent également effectuer des requêtes réseau supplémentaires. Cela ne fait pas partie intégrante de la plateforme d’intelligence artificielle fédérée, Flower, en tant que décision (a) du utilisateur sur les types de systèmes tiers auxquels leur application Flower doit se connecter et (b) de l’administrateur système sur les types de connexions qu’ils souhaitent autoriser.

Exemples typiques incluent :

• ClientApp vers la base de données : Les instances ClientApp ont généralement besoin d’accéder aux données pour effectuer l’action pour laquelle elles ont été conçues (par exemple, entraîner localement un modèle, exécuter une requête DB). La manière dont cette connexion est établie dépend de la technologie de stockage utilisée côté client. Notez que dans le diagramme ci-dessus, nous montrons deux représentations de connexions à des bases de données sur les clients A et B. Votre(s) connexion(s) vers la base de données peut(ont) probablement différer de l’illustration ci-dessus.

• ServerApp vers la base de données : Les instances ServerApp peuvent souhaiter accéder aux données pour effectuer l’action pour laquelle elles ont été conçues (par exemple, évaluer un modèle sur des données après agrégation). La manière dont cette connexion est établie dépend de la technologie de stockage utilisée côté client. Notez que dans le diagramme ci-dessus, nous avons omis de montrer une base de données connectée aux composants ServerApp.

• ServerApp vers le service de journalisation de métrique : Les services de journalisation de métrique tels que TensorBoard, MLFlow et Weights & Biases sont souvent utilisés pour suivre les progrès des exécutions d’entraînement. Dans ce cas, le ServerApp agit généralement comme client vers le service de journalisation de métrique.

Modèle de communication

Lors du déploiement réel, le modèle de communication push/pull adopté par chaque composant peut influencer les décisions relatives à la provisionnement des ressources, l’échelle, le suivi et la fiabilité. Pour soutenir ces décisions, la liste ci-dessous détaille le modèle de communication utilisé entre les composants Flower :

• SuperLink ⇌ SuperNode (Fleet API) : Le SuperNode récupère/pousse des Messages vers/à partir du SuperLink via l’API Fleet. Le SuperNode récupère également le FAB si une nouvelle exécution est en cours.

• SuperLink ↔ ServerApp (Runtime API): The ServerApp process pulls/pushes Messages from/to the SuperLink via its Runtime API. The ServerApp also pulls the FAB as part of the first interaction with the SuperLink, and at the end of the execution it pushes the Context back to the SuperLink.

• SuperNode ↔ ClientApp (Runtime API): The ClientApp process pulls/pushes Messages from/to the SuperNode via its Runtime API. The ClientApp also pulls the FAB as part of the first interaction with the SuperNode, and at the end of the execution it pushes the Context back to the SuperNode.