Assegnazione indirizzo

Riepilogo

Introduzione:

Poiché esistono una serie di interdipendenze tra le interfacce e poiché diverse configurazioni dei dispositivi possono richiedere indirizzi TCP/IP e assegnazioni di route diversi, si è ritenuto essenziale che la logica per il controllo dell'indirizzo IP e dell'assegnazione delle route venisse consolidata in un unico modulo. WARM consente di aggiungere e rimuovere correttamente gli indirizzi TCP/IP e le route alle interfacce IP relative a Weave quando queste interfacce passano dallo stato attivo<->inattivo.

WARM è progettato per essere configurato in fase di compilazione tramite WarmProjectConfig.h e WarmConfig.h. WarmProjectConfig.h deve rispecchiare con precisione le funzionalità supportate del dispositivo su cui verrà eseguito WARM.

WARM è un modulo portatile che limita la dipendenza dalla configurazione di uno stack TCP/IP e di un'interfaccia Thread. A questo scopo, WARM si basa su un set di API della piattaforma che deve essere implementato dall'integratore di piattaforme. Inoltre, l'integratore di piattaforme è responsabile dell'esecuzione delle varie chiamate API nl::Warm dai punti di esecuzione appropriati all'interno del codebase della piattaforma.

Teoria del funzionamento:

Il codebase della piattaforma chiamerà le API nl::Warm per annunciare un cambio di stato per funzionalità correlate come l'interfaccia Wi-Fi e l'interfaccia Thread. Una chiamata a una di queste API nl::Warm può comportare una chiamata da parte di WARM a Platform::RequestInvokeActions(). Platform::RequestInvokeActions() deve essere implementata per eseguire le operazioni necessarie che chiameranno Warm::InvokeActions(). Questo processo a prima vista potrebbe apparire inutilmente indiretto. Perché WARM non dovrebbe chiamare direttamente InvokeActions? La risposta a questa domanda è consentire a qualsiasi attività in un sistema multitasking di chiamare le API nl::Warm State Change e fornire un meccanismo in modo che solo un'attività specifica chiamerà le API Platform::. Dopo aver preso in considerazione i requisiti della piattaforma, l'integratore di piattaforme può scegliere di implementare Platform::RequestInvokeActions() in modo da pubblicare un evento per l'attività appropriata che reagirà chiamando Warm::InvokeActions(). Se, per una determinata piattaforma, si decide che non esistono problemi di questo tipo, è possibile implementare Platform::RequestInvokeActions() per chiamare direttamente Warm::InvokeActions()

Quando viene chiamato Warm::InvokeActions(), la logica WARM esaminerà lo stato attuale del sistema ed eseguirà le eventuali chiamate API Platform:: necessarie al fine di allineare l'indirizzo e lo stato del routing allo stato del sistema e della configurazione. Queste chiamate vengono effettuate in un ordine predefinito e, se una delle seguenti API restituisce kPlatformResultInProgress, l'esecuzione dell'elenco ordinato verrà sospesa e chiusa. Inoltre, quando una di queste API restituisce kPlatformResultInProgress, si interpreta che l'operazione verrà completata in modo asincrono e che la logica WARM dovrebbe attendere il completamento dell'operazione. Al termine dell'operazione, il codice della piattaforma deve chiamare Warm::ReportActionComplete(), trasmettendo il risultato di kPlatformResultSuccess o kPlatformResultFailure. Dopo aver ricevuto questa chiamata, la logica WARM chiama nuovamente Platform::RequestInvokeActions() per riavviare l'esecuzione dell'elenco di azioni ordinate.

In questo modo WARM non richiede un'attività specifica, ma può invece fare affidamento su un'altra attività per chiamare la modalità Warm come appropriato. Inoltre, qualsiasi attività può chiamare una o più API di modifica dello stato del sistema, semplificando l'integrazione.