Назначение адреса

Краткое содержание

Введение:

Поскольку между интерфейсами существует ряд взаимозависимостей, а также поскольку разные конфигурации устройств могут требовать разных адресов TCP/IP и назначения маршрутов, было сочтено важным, чтобы логика управления IP-адресом и назначением маршрутов была объединена в один модуль. WARM служит для правильного добавления и удаления адресов TCP/IP и маршрутов для IP-интерфейсов, связанных с Weave, когда эти интерфейсы переходят из активного <-> неактивного состояния.

WARM предназначен для настройки во время компиляции с помощью WarmProjectConfig.h и WarmConfig.h . WarmProjectConfig.h должен точно отражать поддерживаемые функции устройства, на котором будет выполняться WARM.

WARM — это портативный модуль, который ограничивает его зависимость от настройки стека TCP/IP и интерфейса потоков. Для этой цели WARM использует набор API-интерфейсов платформы, которые должен реализовать интегратор платформы. Кроме того, интегратор платформы отвечает за выполнение различных вызовов API nl::Warm из соответствующих точек выполнения в базе кода платформы.

Теория Операции:

База кода платформы будет вызывать API nl::Warm, чтобы объявить об изменении состояния связанных функций, таких как интерфейс WiFi и интерфейс Thread. Вызов любого из этих API-интерфейсов nl::Warm может привести к вызову WARM метода Platform::RequestInvokeActions(). Платформа::RequestInvokeActions() должна быть реализована для выполнения необходимых операций, которые будут вызывать Warm::InvokeActions() . Этот процесс на первый взгляд может показаться излишне косвенным. Почему бы WARM не вызвать InvokeActions напрямую? Ответ на этот вопрос заключается в том, чтобы позволить любой задаче в многозадачной системе вызывать API-интерфейсы nl::Warm State Change и предоставить механизм, позволяющий только конкретной задаче вызывать API-интерфейсы Platform::. Приняв во внимание требования платформы, интегратор платформы может решить реализовать Platform::RequestInvokeActions(), чтобы он отправлял событие соответствующей задаче, которая будет реагировать вызовом Warm::InvokeActions() . Если для данной платформы решено, что таких проблем с многозадачностью не существует, можно реализовать Platform::RequestInvokeActions() для прямого вызова Warm::InvokeActions() .

Когда вызывается Warm::InvokeActions(), логика WARM проверяет текущее состояние системы и выполняет все необходимые вызовы API Platform::, чтобы привести адрес и состояние маршрутизации в соответствие с состоянием системы и конфигурации. Эти вызовы выполняются в заранее определенном порядке, и если какой-либо из этих API возвращает kPlatformResultInProgress, выполнение упорядоченного списка приостанавливается и завершается. Более того, когда один из этих API возвращает kPlatformResultInProgress, это интерпретируется как операция завершится асинхронно и что логика WARM должна дождаться завершения этой операции. После завершения операции код платформы должен вызвать Warm::ReportActionComplete() , передав результат kPlatformResultSuccess или kPlatformResultFailure. При получении этого вызова логика WARM снова вызовет Platform::RequestInvokeActions(), чтобы возобновить выполнение упорядоченного списка действий.

Таким образом, WARM не требует собственной задачи, а вместо этого может полагаться на другую задачу для вызова Warm при необходимости. Кроме того, любая задача может вызывать один или несколько API изменения состояния системы, что упрощает интеграцию.