Attribution d'adresse

Résumé

Introduction :

Étant donné qu'il existe un certain nombre d'interdépendances entre les interfaces et que différentes configurations d'appareils peuvent nécessiter des adresses TCP/IP et des attributions de routes différentes, il a été jugé essentiel que la logique de contrôle de l'adresse IP et de l'attribution des routes soit consolidée dans un seul module. WARM permet d'ajouter et de supprimer correctement les adresses TCP/IP et les routes vers les interfaces IP liées à Weave lorsque ces interfaces passent d'une interface active<->inactive.

WARM est destiné à être configuré au moment de la compilation via HotProjectConfig.h et WarmConfig.h. Le fichier WARM doit refléter avec précision les fonctionnalités compatibles de l'appareil sur lequel WARM s'exécutera.

WARM est un module portable qui limite sa dépendance à la configuration d'une pile TCP/IP et d'une interface Thread. À cette fin, WARM s'appuie sur un ensemble d'API de plate-forme qui doit être implémentée par l'intégrateur de plate-forme. En outre, l'intégrateur de plate-forme est chargé d'effectuer les différents appels d'API nl::Warm à partir de points d'exécution appropriés au sein du code base de la plate-forme.

Théorie du fonctionnement:

Le code base de la plate-forme appelle les API nl::Warm pour annoncer le changement d'état des fonctionnalités associées, telles que l'interface Wi-Fi et l'interface Thread. Un appel à l'une de ces API nl::Warm peut entraîner un appel de WARM à Platform::RequestRequestActions(). Platform::RequestUnlockActions() doit être implémenté pour effectuer les opérations nécessaires qui appelleront Warm::CallbackActions(). À première vue, ce processus peut sembler inutilement indirect. Pourquoi WARM n'appelle-t-il pas directement PrimaryActions ? La réponse à cette question est d'autoriser toute tâche dans un système multitâche à appeler l'API nl::Warm State Change et de fournir un mécanisme pour que seule une tâche spécifique appelle l'API Platform::. Après avoir pris en compte les exigences de la plate-forme, l'intégrateur de plate-forme peut choisir d'implémenter Platform::RequestRequestActions() afin de publier un événement sur la tâche appropriée qui réagira en appelant Warm::CallbackActions(). Si, pour une plate-forme donnée, il est décidé qu'aucun problème multitâche de ce type n'existe, Platform::RequestDemandeActions() peut être implémenté pour appeler directement Warm::CallbackActions().

Lorsque Warm::CallbackActions() est appelé, la logique WARM examine l'état actuel du système et effectue les appels d'API Platform:: nécessaires afin d'aligner l'adresse et l'état de routage sur l'état du système et de la configuration. Ces appels sont effectués dans un ordre prédéfini. Si l'une de ces API renvoie kPlatformResultInProgress, l'exécution de la liste numérotée est suspendue et se ferme. De plus, lorsque l'une de ces API renvoie kPlatformResultInProgress, il est interprété que l'opération se termine de manière asynchrone et que la logique WARM doit attendre la fin de l'opération. Une fois l'opération terminée, le code de plate-forme doit appeler Warm::ReportActionComplete(), en transmettant le résultat de kPlatformResultSuccess ou de kPlatformResultFailure. À la réception de cet appel, la logique WARM appelle à nouveau Platform::RequestRequestActions() afin de redémarrer l'exécution de la liste d'actions ordonnée.

WARM ne nécessite donc pas sa propre tâche, mais peut s'appuyer sur une autre tâche pour l'appeler, le cas échéant. De plus, n'importe quelle tâche peut appeler une ou plusieurs API de changement de l'état du système, ce qui simplifie l'intégration.