資料流

本章節介紹 Sylvia-IoT 如何處理資料流，包含以下幾種：

• 上行資料（uplink），裝置→應用。
• 下行資料（downlink），應用→裝置。
• 控制通道，Broker→網路。
• Coremgr 操作資料（operation），紀錄系統操作歷程。

上行資料 (Uplink)

當裝置的資料透過網路服務送到對應的佇列後，資料會以如下的方式被送至應用端：

1. 如格式正確，繼續下一步；否則直接丟棄。
2. Broker 先直接將資料送往 Data 元件（透過佇列），以儲存完整的上行資料內容。
3. 掃描所有的裝置路由，並進行以下的動作：
   • 送往對應應用的佇列。
   • 將送往應用的資料儲存到 Data 元件。
4. 掃描所有的網路路由，並進行以下的動作：
   • 比對是否已經在裝置路由階段就已發送。有就進行下一個網路路由動作，沒有就繼續以下動作。
   • 送往對應應用的佇列。
   • 將送往應用的資料儲存到 Data 元件。

步驟 4 的比對的動作，目的在於避免裝置路由與網路路由出現重疊的時候，造成重複發送的行為。

下行資料 (Downlink)

當應用服務將要送給裝置的資料發送到佇列後，資料會以如下的方式被送至裝置對應的網路服務：

1. 如格式正確，繼續下一步；否則透過 resp 佇列回應錯誤訊息。
2. 檢查目的裝置是否屬於該單位，如果是，繼續下一步；否則透過 resp 佇列回應錯誤訊息。
3. 將此資料新增 ID（唯一識別碼）作為獨立資料，然後送到 Data 元件儲存。
4. 在資料庫保留這筆資料的 ID 和來源的應用，便於日後回報這筆資料的傳送結果給應用服務。
5. 將資料（含資料 ID）發送到網路服務的佇列。
6. 如果發送到網路服務的佇列，將此資料的 ID 回報給應用服務，來追蹤傳送的結果。

相較於上行資料，下行資料稍微複雜。主要的難題在於 要回報傳送的結果。

Broker 沒有保留 resp 佇列讓網路服務回報資料的正確性，原因在 Broker 作為基礎設施，內容一定是正確的！ 網路服務只要專注於將資料送往裝置，並回報最後的結果即可。即使 Broker 送過去的資料已經無效，網路服務直接透過 result 佇列回報即可。

當資料處理完成（無論成功與否），網路服務 必須 使用資料 ID 來回報給 Broker。順序如下：

1. 如格式正確，繼續下一步；否則直接丟棄。
2. 透過 ID，向 Data 元件提交結果的更新要求。
3. 抓取該 ID 所屬的應用服務資訊，並將結果回報給發送此下行資料的應用程式（確保其他應用不會收到）。
4. 如果步驟 3 成功，清除資料庫中的 ID 資訊。

使用額外的 ID 資料庫的目的在於保留下行資料的來源應用，畢竟由應用 A 發送的資料，為什麼應用 B 要收到結果呢 😊？

控制通道 (Control Channel)

Broker 或是 coremgr 提供 API 可以讓網路服務隨時更新裝置的資料。不過靠著定期請求 API 來同步的效率不佳，且可能因為頻繁請求，影響路由的效能。 Broker 提供了一個機制，當裝置資料有變更的時候，在 broker.network.[單位代碼].[網路代碼].ctrl 提供資訊給對應的網路服務。

Sylvia-IoT 允許裝置變更依附的網路或是位址。當這個操作發生的時候，依據不同情境，網路服務會收到如下的訊息：

• 從網路 A 變更為網路 B
  • 通知網路 A，有一個特定位址被移除。
  • 通知網路 B，有一個特定位址被新增。
• 在網路 A 中變更位址
  • 通知網路 A，有一個特定位址被移除。
  • 通知網路 A，有一個特定位址被新增。

操作紀錄 (Operation Data)

Coremgr 有一個可選的設定，用來儲存所有的系統操作紀錄（當然限定 coremgr HTTP API）。目前的範圍是 POST/PUT/PATCH/DELETE 等。

如上圖，coremgr 會在 API 操作完畢後，記錄下列的資料：

• 請求時間
• 回應時間
• 處理時間
• HTTP 狀態
• 來源 IP 位址
• HTTP method
• （可選）HTTP 請求 body
  • 會過濾 data.password 的內容。當請求中有 password 欄位時，會將其內容清空。保留 key 是為了提示此請求有修改密碼的動作。
• 使用者 ID
• 客戶端 ID