住所の割り当て

概要

概要:

インターフェース間に多くの相互依存関係があり、またデバイス構成によって異なる TCP/IP アドレスとルート割り当てが必要になる場合があるため、IP アドレスとルート割り当てを制御するロジックを 1 つのモジュールに統合することが不可欠と判断されました。WARM は、TCP/IP アドレスと Weave 関連の IP インターフェースがアクティブから非アクティブに移行する際に、それらのインターフェースを適切に追加または削除する目的を果たします。

WARM は、コンパイル時に WaramProjectConfig.h と WarmConfig.h を使用して設定されるように意図されています。WarmProjectConfig.h は、WARM が実行されるデバイスでサポートされている機能を正確に反映している必要があります。

WARM はポータブルモジュールであり、TCP/IP スタックと Thread インターフェースの構成方法への依存が制限されます。この目的のために、WARM はプラットフォームインテグレータによって実装されるプラットフォーム API のセットに依存します。さらに、プラットフォームコードベース内の適切な実行ポイントからさまざまな nl::Warm API 呼び出しを行う責任は、プラットフォームインテグレータにあります。

運用理論:

プラットフォームのコードベースは、nl::Warm API を呼び出して、Wi-Fi インターフェースや Thread インターフェースなどの関連機能の状態の変更を通知します。これらの nl::Warm API を呼び出すと、WARM から Platform::RequestInvokeActions() が呼び出されることがあります。Warm::InvokeActions() の呼び出しに必要な操作を行うために、Platform::RequestInvokeActions() を実装する必要があります。このプロセスは、一見すると不必要に間接的に見えることがあります。WARM が InvokeActions を直接呼び出さないのはなぜですか？この問いへの答えは、マルチタスクシステムの任意のタスクが nl::Warm State Change API を呼び出すことができ、特定のタスクのみが Platform:: API を呼び出すメカニズムを提供することです。プラットフォームの要件を考慮した後、プラットフォームインテグレータは、Warm::InvokeActions() を呼び出して対応するタスクにイベントを送信するように Platform::RequestInvokeActions() を実装できます。特定のプラットフォームでそのようなマルチタスクの懸念がないと判断した場合、Platform::RequestInvokeActions() を実装して Warm::InvokeActions() を呼び出すことができます。

Warm::InvokeActions() が呼び出されると、WARM ロジックは現在のシステム状態を調べ、アドレスとルーティング状態をシステム状態と構成状態に合わせるために、必要な Platform:: API 呼び出しを行います。これらの呼び出しは事前定義された順序で行われ、これらの API のいずれかが kPlatformResultInProgress を返すと、順序付きリストの実行は中断して終了します。さらに、これらの API のいずれかが kPlatformResultInProgress を返すと、操作は非同期で完了すること、および WARM ロジックはその操作が完了するまで待機する必要があると解釈されます。操作が完了すると、プラットフォームコードは Warm::ReportActionComplete() を呼び出して、kPlatformResultSuccess または kPlatformResultFailure の結果を渡す必要があります。この呼び出しを受け取ると、WARM ロジックは再度 Platform::RequestInvokeActions() を呼び出して、順序付けされたアクションリストの実行を再開します。

このように、WARM は独自のタスクを必要とするのではなく、代わりに別のタスクを使用して、必要に応じてウォームを呼び出すことができます。さらに、どのタスクでも 1 つ以上の System State change API を呼び出すことができるため、統合が簡単になります。