Adresszuweisung

Zusammenfassung

Introduction:

Da zwischen den Schnittstellen eine Reihe von Abhängigkeiten vorhanden sind und verschiedene Gerätekonfigurationen unterschiedliche TCP/IP-Adressen und Routenzuweisungen erfordern können, war es wichtig, die Logik zur Steuerung der IP-Adresse und Routenzuweisung in einem einzigen Modul zu konsolidieren. WARM dient dem ordnungsgemäßen Hinzufügen und Entfernen von TCP/IP-Adressen und Routen zu Weave-bezogenen IP-Schnittstellen, wenn diese Schnittstellen von „Aktiv<->Inaktiv“ übergehen.

WARM wird bei der Kompilierung über WarmProjectConfig.h und WarmConfig.h konfiguriert. WarmProjectConfig.h muss die unterstützten Funktionen des Geräts, auf dem WARM ausgeführt wird, korrekt widerspiegeln.

WARM ist ein portables Modul, das seine Abhängigkeit von der Konfiguration eines TCP/IP-Stacks und einer Thread-Schnittstelle begrenzt. Zu diesem Zweck stützt sich WARM auf eine Reihe von Plattform-APIs, die vom Plattformintegrator implementiert werden müssen. Darüber hinaus ist der Plattformintegrator für die Durchführung der verschiedenen nl::Warm API-Aufrufe von entsprechenden Ausführungspunkten innerhalb der Plattform-Codebasis verantwortlich.

Betriebstheorie:

Die Codebasis der Plattform ruft nl::Warm APIs auf, um eine Statusänderung für zugehörige Funktionen wie die WLAN- und Thread-Schnittstelle anzukündigen. Der Aufruf einer dieser nl::Warm APIs kann zu einem Aufruf von WARM an Platform::RequestInvokeActions() führen. Platform::RequestInvokeActions() muss implementiert sein, um die erforderlichen Vorgänge auszuführen, die Warm::InvokeActions() aufrufen. Dieser Prozess kann auf den ersten Blick unnötigerweise indirekt erscheinen. Warum würde WARM InvokeActions nicht direkt aufrufen? Die Antwort auf diese Frage besteht darin, jeder Aufgabe in einem Multi-Tasking-System das Aufrufen der nl::Warm State Change APIs zu ermöglichen und einen Mechanismus bereitzustellen, damit nur eine bestimmte Aufgabe die Platform:: APIs aufruft. Nachdem die Plattformanforderungen berücksichtigt wurden, kann der Plattformintegrator „Platform::RequestInvokeActions()“ implementieren, um ein Ereignis an die entsprechende Aufgabe zu senden, die durch Aufrufen von Warm::InvokeActions() reagiert. Wenn für eine bestimmte Plattform entschieden wird, dass keine derartigen Bedenken hinsichtlich des Multitasking vorliegen, kann „Platform::RequestInvokeActions()“ implementiert werden, um Warm::InvokeActions() direkt aufzurufen.

Wenn Warm::InvokeActions() aufgerufen wird, untersucht die WARM-Logik den aktuellen Systemstatus und führt alle erforderlichen Platform:: API-Aufrufe durch, um die Adresse und den Routingstatus in Einklang mit dem System- und Konfigurationsstatus zu bringen. Diese Aufrufe erfolgen in einer vordefinierten Reihenfolge. Wenn einer dieser APIs kPlatformResultInProgress zurückgibt, wird die Ausführung der sortierten Liste unterbrochen und beendet. Wenn eines dieser APIs kPlatformResultInProgress zurückgibt, wird außerdem davon ausgegangen, dass der Vorgang asynchron abgeschlossen wird und dass die WARM-Logik auf den Abschluss dieses Vorgangs warten soll. Nach Abschluss des Vorgangs sollte der Plattformcode Warm::ReportActionComplete() aufrufen und das Ergebnis kPlatformResultSuccess oder kPlatformResultFailure übergeben. Nach Erhalt dieses Aufrufs ruft die WARM-Logik erneut Platform::RequestInvokeActions() auf, um die Ausführung der Liste der sortierten Aktionen neu zu starten.

Auf diese Weise benötigt WARM keine eigene Aufgabe, sondern kann sich stattdessen darauf verlassen, dass eine andere Task bei Bedarf an Warm geht. Außerdem kann jede Aufgabe eines oder mehrere der System State Change APIs aufrufen, was die Integration vereinfacht.