Przypisywanie adresu
Podsumowanie
Wstęp:
Ze względu na to, że między interfejsami istnieje wiele zależności oraz ponieważ różne konfiguracje urządzeń mogą wymagać różnych adresów TCP/IP i przypisanych tras, uznano, że logika kontrolowania adresów IP i przypisywania tras powinna być skonsolidowana w jednym module. WARM służy do prawidłowego dodawania i usuwania adresów TCP/IP oraz tras do interfejsów IP powiązanych z Weave, gdy te interfejsy przechodzą z aktywnego<->nieaktywnego.
Program WARM należy skonfigurować podczas kompilacji za pomocą witryny WarmProjectConfig.h i WarmConfig.h. Plik CheckProjectConfig.h musi dokładnie odzwierciedlać obsługiwane funkcje urządzenia, na którym będzie uruchamiane WARM.
WARM to przenośny moduł, który ogranicza zależność od konfiguracji stosu TCP/IP i interfejsu Thread. W tym celu WARM używa zestawu interfejsów API platformy, które muszą być wdrożone przez integratora platform. Ponadto integrator platformy odpowiada za wykonywanie różnych wywołań interfejsu API nl::Warm z odpowiednich punktów wykonania w bazie kodu platformy.
Teoria działania:
Baza kodu platformy wywoła metodę nl::Warm API, aby ogłosić zmianę stanu w przypadku powiązanych funkcji, takich jak interfejs Wi-Fi i interfejs Thread. Wywołanie dowolnego z tych interfejsów API nl::Warm może spowodować wywołanie funkcji WARM do platformy::RequestInvokeActions(). Platforma::RequestInvokeActions() musi być zaimplementowana, by wykonać niezbędne operacje, które wywołają Warm::InvokeActions(). Taki proces na pierwszy rzut oka może wydawać się niepotrzebnie pośredni. Dlaczego WARM nie zadzwoni bezpośrednio do InvokeActions? Odpowiedź na to pytanie polega na tym, aby każde zadanie w systemie wielozadaniowym mogło wywoływać interfejsy API nl::Warm State Change oraz udostępnić mechanizm, dzięki któremu tylko konkretne zadanie będzie wywoływać interfejsy API. Po zapoznaniu się z wymaganiami dotyczącymi platformy integrator platformy może zastosować platformę Platform::RequestInvokeActions(), aby opublikować zdarzenie do odpowiedniego zadania, które zareaguje, wywołując funkcję Warm::InvokeActions(). Jeśli w przypadku danej platformy nie ma problemów wielozadaniowych, Platform::RequestInvokeActions() można wykorzystać do bezpośredniego wywołania funkcji WarmActions():.
Po wywołaniu funkcji Warm::InvokeActions() funkcja WARM sprawdza bieżący stan systemu i wykona wszelkie niezbędne wywołania interfejsu API w celu zapewnienia zgodności adresu i stanu routingu ze stanem systemu i konfiguracji. Te wywołania są wykonywane we wstępnie zdefiniowanej kolejności, a jeśli którykolwiek z tych interfejsów API zwróci kPlatformResultInprogress, wykonanie uporządkowanej listy spowoduje zawieszenie i zakończenie. Dodatkowo, gdy jeden z tych interfejsów API zwraca wartość kPlatformResultInProgress, oznacza to, że operacja zakończy się asynchronicznie, a funkcja WARM powinna czekać na jej zakończenie. Po zakończeniu operacji kod platformy powinien wywołać metodę Warm::ReportActionComplete() z wynikiem kPlatformResultSuccess lub kPlatformResultFailure. Po otrzymaniu tego wywołania funkcja WARM ponownie wywoła Platform::RequestInvokeActions() w celu ponownego uruchomienia listy uporządkowanych działań.
W ten sposób WARM nie wymaga własnego zadania i może polegać na innym zadaniu, które w razie potrzeby wywoła odpowiednie zdarzenie. Dodatkowo każde zadanie może wywoływać co najmniej jeden interfejs API zmiany stanu systemu, co upraszcza integrację.