En Google, luchamos por la equidad racial de la comunidad negra. Más información

Asignación de dirección

Resumen

Introducción:

Debido a que hay una serie de interdependencias entre interfaces y debido a que diferentes configuraciones de dispositivos pueden requerir diferentes direcciones 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 eliminar correctamente las direcciones TCP / IP y las interfaces IP relacionadas con Rutas a tejido a medida que esas interfaces pasan de activo <-> inactivo.

CALENTAMIENTO está destinado a ser configurado en tiempo de compilación a través WarmProjectConfig.h y WarmConfig.h . WarmProjectConfig.h debe reflejar con precisión las características compatibles del dispositivo en el que se ejecutará WARM.

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

Teoría de operación:

La base del código de la plataforma llamará a las API nl :: Warm para anunciar un cambio de estado para las funciones relacionadas, como la interfaz WiFi y la interfaz Thread. Una llamada a cualquiera de estas API nl :: Warm puede resultar en una llamada de WARM a Platform :: RequestInvokeActions (). Plataforma :: RequestInvokeActions () deben ser implementadas para realizar las operaciones necesarias que llamar cálidos :: 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 API nl :: Warm State Change y proporcionar un mecanismo para que solo una tarea específica llame a las API Platform ::. Después de tomar las Plataformas necesarias en consideración, la Plataforma Integrador puede optar por aplicar la Plataforma :: RequestInvokeActions () para que se publica un evento para la tarea apropiada que reaccionará llamando calientes :: InvokeActions () . Si, para una determinada plataforma, se decide que no existen tales preocupaciones multitarea, () se pueden implementar la plataforma :: RequestInvokeActions llamar cálidos :: InvokeActions () directamente.

Cuando cálidos :: InvokeActions () se llama la lógica CALIENTE examinará el actual estado del sistema y realizar ninguna llamada Plataforma :: API necesarias con el fin de llevar la dirección y el enrutamiento de estado en línea con el sistema y el estado de configuración. Estas llamadas se realizan en un orden predefinido y si alguna de estas API devuelve kPlatformResultInProgress, la ejecución de la lista ordenada se suspenderá y finalizará. Además, cuando una de estas API devuelve kPlatformResultInProgress, se interpreta que la operación se completará de forma asincrónica y que la lógica WARM debe esperar a que se complete la operación. Al finalizar la operación, el código de plataforma debe llamar caliente :: ReportActionComplete () , pasando en consecuencia de kPlatformResultSuccess o kPlatformResultFailure. Al recibir esta llamada, la lógica 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 confiar en otra tarea para llamar a Warm 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.