指派地址

摘要

簡介：

由於介面之間存在許多相依性，而且不同的裝置設定可能需要不同的 TCP/IP 位址和路徑指派，因此我們認為控管 IP 位址和路徑指派作業的邏輯必須合併為單一模組。當這些介面從使用中<->無效時，WARM 可以正確新增和移除 TCP/IP 位址和 Weave 相關 IP 介面的路徑。

WARM 隨附於透過暖 ProjectConfig.h 和 WarmConfig.h 設定編譯時間。暖 ProjectConfig.h 必須準確反映執行 WARM 的裝置所支援的功能。

WARM 是一個可移植模組，會限制其依賴 TCP/IP 堆疊和執行緒介面的設定方式。為此，WARM 需要使用一組 Platform API，且必須由平台整合商實作。此外，平台整合商也會負責從「平台」程式碼集內的適當執行點發出各種 nl::Warm API 呼叫。

營運理論：

平台程式碼集會呼叫 nl::Warm API 來公告相關功能 (例如 Wi-Fi 介面和 Thread 介面) 的狀態變更。呼叫這些 nl::Warm API 時，可能會由 WARM 對 Platform::RequestInvokeActions(). 呼叫。Platform::RequestInvokeActions() 必須導入以執行必要的作業來呼叫 Warm::InvokeActions()。此程序一開始可能看起來一目瞭然。為什麼 WARM 不直接呼叫 InvokeActions？這個問題的答案，是讓多工系統中的任何工作都能呼叫 nl::Warm State Change API ，並提供機制，以便只有特定工作會呼叫 Platform: API。考量平台規定後，平台整合工具可能會選擇導入 Platform::RequestInvokeActions()，藉此將事件發布至適當的工作，並藉由呼叫 Warm::InvokeActions() 來回應 Warm:。

呼叫 WARM 邏輯後，Warm::InvokeActions() 將檢查目前的系統狀態，並進行任何必要的平台：API 呼叫，以配合系統和設定狀態，使地址和轉送狀態符合要求。這些呼叫會按照預先定義的順序進行，如果有任何 API 的傳回 kPlatformResultInProgress，將暫停並結束對排序清單的執行作業。此外，當這些 API 的其中一個 API 傳回 kPlatformResultInProgress 時，會將其解讀為作業會以非同步方式完成，而 WARM 邏輯應等待該作業完成。作業完成後，平台程式碼應呼叫 Warm::ReportActionComplete()，並傳遞 kPlatformResultSuccess 或 kPlatformResultFailure 的結果。收到此呼叫後，WARM 邏輯會再次呼叫 Platform::RequestInvokeActions()，以便重新啟動已排序動作清單的執行作業。

如此一來，WARM 不需要用到自己的工作，但可以視情況依賴另一個工作來呼叫暖機。此外，任何工作都可以呼叫一或多個 System State Change API ，進而簡化整合。