Asignación de dirección

Resumen

Introducción:

Debido a que hay varias interdependencias entre las interfaces y a que las diferentes configuraciones de los dispositivos pueden requerir diferentes direcciones de TCP/IP y asignaciones de ruta, se consideró esencial que la lógica para controlar la dirección IP y la asignación de ruta se consolide en un solo módulo. WARM tiene el propósito de agregar y quitar correctamente direcciones IP/TCP/IP y las interfaces IP relacionadas con las rutas a Weave cuando esas interfaces pasan de ser activas<->inactivas.

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

WARM es un módulo portátil que limita su dependencia de la configuración de una pila TCP/IP y la interfaz de Thread. Para ello, WARM se basa en un conjunto de APIs de la plataforma que el integrador de la plataforma debe implementar. Además, el integrador de plataforma es responsable de realizar varias llamadas a la API de nl::Warm desde los puntos de ejecución adecuados 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 las API de nl::Warm para anunciar un cambio de estado para funciones relacionadas, como la interfaz Wi-Fi y la interfaz Thread. Una llamada a cualquiera de estas API de nl::Warm puede generar una llamada del WARM a Platform::RequestinvokeActions(). Se debe implementar Platform::RequestInvokeActions() para realizar las operaciones necesarias que llamarán a Warm::invokeActions(). Este proceso a primera vista puede parecer innecesariamente indirecto. ¿Por qué WARM no llamaría directamente a invokeActions? La respuesta a esa pregunta es permitir que cualquier tarea en un sistema multitarea llame a las APIs nl::Warm State Change y proporcionar un mecanismo de modo que solo una tarea específica llame a las APIs de Platform::. Después de considerar los requisitos de la plataforma, el integrador de la plataforma puede decidir implementar Platform::RequestinvokeActions() para publicar un evento en la tarea correspondiente que reaccionará llamando a Warm::invokeActions(). Si, para una plataforma determinada, se decide que no existen inquietudes relacionadas con la multitarea, Platform::RequestinvokeActions() puede implementarse para llamar directamente a Warm::invokeActions().

Cuando se llama a Warm::invokeActions(), la lógica de WARM examina el estado actual del sistema y realiza las llamadas a la API de Platform:: necesarias para alinear la dirección y el estado de enrutamiento con el estado del sistema y la configuración. Estas llamadas se realizan en un orden predefinido y, si alguna de estas API muestra kPlatformResultInProgress, se suspenderá la ejecución de la lista ordenada y se cerrará. 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 de WARM debe esperar a que se complete esa operación. Una vez completada la operación, el código de la plataforma debe llamar a Warm::ReportActionComplete() y pasar el resultado de kPlatformResultSuccess o kPlatformResultFailure. Tras recibir esta llamada, la lógica de WARM volverá a llamar a Platform::RequestinvokeActions() para reiniciar la ejecución de la lista de acciones ordenadas.

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