Asignación de dirección

Resumen

Introducción:

Debido a que hay varias interdependencias entre las interfaces, y debido a que las diferentes configuraciones de dispositivos pueden requerir diferentes direcciones TCP/IP y asignación de rutas, se consideró fundamental que la lógica para controlar la asignación de direcciones IP y rutas se consolide en un solo módulo. El WARM tiene el propósito de agregar y quitar las direcciones TCP/IP y las rutas a las interfaces de IP relacionadas con Weave de manera adecuada a medida que esas interfaces pasan de activas-inactivas.

WARM está diseñado para configurarse en el tiempo de compilación a través de WarmProjectConfig.h y WarmConfig.h. WarmProjectConfig.h debe reflejar con precisión las funciones compatibles del dispositivo en los que se ejecutará WARM.

WARM es un módulo portátil que limita su dependencia de la configuración de una pila TCP/IP y una interfaz Thread. Para este propósito, WARM se basa en un conjunto de API de la plataforma que debe implementar el integrador de la plataforma. Además, el integrador de plataformas es responsable de realizar las distintas llamadas a la API nl::Warm desde los puntos de ejecución apropiados dentro de la base de código de la plataforma.

Teoría de la operación:

La base de código de la plataforma llamará a nl::Warm API #39; para anunciar un cambio de estado en funciones relacionadas, como la interfaz Wi-Fi y la interfaz de Thread. Es posible que una llamada a cualquiera de estas API nl::Warm genere una llamada de WARM a Platform::RequestSuggestActions(). Platform::RequestSuggestActions() para realizar las operaciones necesarias que llamarán a Warm::][=Actions(). Este proceso a primera vista puede parecer indirectamente innecesario. ¿Por qué el WARM no llamaría a SuggestActions directamente? La respuesta a esa pregunta es permitir que cualquier tarea en un sistema de multitarea llame a la API de cambio de estado nl::Warm y proporcionar un mecanismo para que solo una tarea específica llame a la plataforma:: API. Después de considerar los requisitos de la plataforma, el integrador de plataformas puede optar por implementar Platform::RequestPromptActions() a fin de publicar un evento en la tarea apropiada que reaccionará llamando a Warm::][=Actions(). Si, en una plataforma determinada, se decide que no existen tales problemas, se puede implementar Platform::RequestSuggestActions() para llamar directamente a Warm::][=Actions().

Cuando se llama a Warm::][=Actions(), la lógica de WARM examinará el estado actual del sistema y realizará las llamadas de Platform:: API necesarias para que la dirección y el estado de enrutamiento coincidan con el estado del sistema y de la configuración. Estas llamadas se realizan en un orden predefinido y, si alguna de estas API muestra kPlatformResultInProgress, se suspenderá y finalizará la ejecución de la lista ordenada. Además, cuando una de estas API muestra kPlatformResultInProgress, se interpreta que la operación se completará de forma asíncrona y que la lógica del WARM deberá esperar que la operación se complete. Cuando se completa la operación, el código de la plataforma debe llamar a Warm::ReportActionComplete() y pasar un resultado de kPlatformResultSuccess o kPlatformResultFailure. Después de recibir esta llamada, la lógica de WARM llamará nuevamente a Platform::RequestSuggestActions() para reiniciar la ejecución de la lista de acciones ordenadas.

De esta manera, WARM no requiere su propia tarea, sino que puede basarse en otra tarea para invocar el método semicaliente según corresponda. Además, cualquier tarea puede llamar a una o más API de cambio de estado del sistema, lo que simplifica la integración.