O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Atribuição de endereço

Resumo

Introdução:

Como há uma série de interdependências entre as interfaces e porque diferentes configurações de dispositivos podem exigir diferentes endereços TCP / IP e atribuição de rotas, foi considerado essencial que a lógica para controlar o endereço IP e a atribuição de rotas fosse consolidada em um único módulo. WARM tem o propósito de adicionar e remover endereços TCP / IP e interfaces de IP relacionadas a Rotas para tecer à medida que essas interfaces passam de <-> inativas.

WARM deve ser configurado em tempo de compilação por meio de WarmProjectConfig.h e WarmConfig.h . WarmProjectConfig.h deve refletir com precisão os recursos suportados do dispositivo no qual o WARM será executado.

WARM é um módulo portátil que limita sua dependência de como uma pilha TCP / IP e uma interface de thread são configuradas. Para este propósito, WARM conta com um Conjunto de APIs de Plataforma que deve ser implementado pelo Integrador de Plataforma. Além disso, o Integrador de Plataforma é responsável por fazer as várias chamadas de API nl :: Warm a partir de pontos de execução apropriados dentro da base de código da Plataforma.

Teoria de Operação:

A base de código da plataforma chamará nl :: Warm API's para anunciar uma mudança de estado para recursos relacionados, como a interface WiFi e a interface Thread. Uma chamada para qualquer uma dessas APIs nl :: Warm pode resultar em uma chamada por WARM para Platform :: RequestInvokeActions (). Platform :: RequestInvokeActions () deve ser implementado para realizar as operações necessárias que chamarão Warm :: InvokeActions () . Este processo à primeira vista pode parecer desnecessariamente indireto. Por que WARM não chamaria InvokeActions diretamente? A resposta a essa pergunta é permitir que qualquer tarefa em um sistema multitarefa chame a API nl :: Warm State Change e fornecer um mecanismo para que apenas uma tarefa específica chame a API Platform ::. Depois de levar os requisitos de plataforma em consideração, o integrador de plataforma pode escolher implementar Platform :: RequestInvokeActions () para que poste um evento para a tarefa apropriada que reagirá chamando Warm :: InvokeActions () . Se, para uma determinada plataforma, for decidido que não existe tal preocupação multitarefa, Platform :: RequestInvokeActions () pode ser implementado para chamar Warm :: InvokeActions () diretamente.

Quando Warm :: InvokeActions () é chamado, a lógica WARM examinará o estado do sistema atual e fará todas as chamadas Platform :: API necessárias para alinhar o endereço e o estado de roteamento com o estado do sistema e da configuração. Essas chamadas são feitas em uma ordem predefinida e se alguma dessas APIs retornar kPlatformResultInProgress, a execução da lista ordenada será suspensa e encerrada. Além disso, quando uma dessas APIs retorna kPlatformResultInProgress, é interpretado que a operação será concluída de forma assíncrona e que a lógica WARM deve aguardar a conclusão dessa operação. Após a conclusão da operação, o código da plataforma deve chamar Warm :: ReportActionComplete () , passando um resultado de kPlatformResultSuccess ou kPlatformResultFailure. Ao receber essa chamada, a lógica WARM chamará novamente Platform :: RequestInvokeActions () para reiniciar a execução da lista de ações ordenadas.

Dessa forma, o WARM não requer sua própria tarefa, mas pode, em vez disso, contar com outra tarefa para chamar Warm conforme apropriado. Além disso, qualquer tarefa pode chamar uma ou mais APIs de alteração do estado do sistema, simplificando a integração.