以下共有六組開源程式在 https://github.com/prplfoundation 共有六個目錄
- prplMesh-manifest：
- 起始點，一些文件，還有未來將要開發的一些東西。
- prplMesh framework：
- Local message bus (IPC機制), 包含一堆服務的介面: platform, transport, management, topology, logging, CAPI：
- prplMesh-common libraries (工具的基礎程式庫)
- TLV factory, controller management, platform, WLAN, plugins
- prplMesh-agent：
- Agent程式碼，內部與廠商程式供通用的API與介面(TLV/CMDUs)。
- prplMesh-controller：
- 資料庫、控制器上執行的微工具(Micro-service task pool)：例如band-steering, mobility, channel-selection, network map, 統計資訊(stats),...等等。
- prplMesh-tools：
- Build Code的工具、安裝程式、klocwork static code analysis, 等等。
基本上，我想分為幾個部分來寫，這一篇是簡單先看一下系統的架構，之後就依照功能的分類，做細部的介紹。
先看一下下面的圖好了，這張圖其實把prplMESH的程式架構寫得很清楚：
Easy Mesh的架構稱之為Multi-AP，就是家裡面會有好幾個Wi-Fi Access Point，這些系統概分為三個角色：
- Multi-AP Framework
- Controller
- Agent
Framework與Controller都常是合在一起的執行的。或是合稱為Controller也沒有關係，但是因為Framework的架構很大，為了討論方便所以單獨拿出來成為一個大的模組。
基本上只會有一個Controller，但是每一台的Access Point上面都會有Agent來執行。Controller與Agent可以在同一台設備上，也可以在不同的設備上。習慣上，會在最靠近Router的那台裝置上執行Controller，但也有人建議是在效能最好的那台來執行Controller。
prplMesh 具有極佳的移植性，所以她建立了一些API，廠商只要把API搞定，基本上，移植工作就完成了。上圖之中有用黃色標出來的就是這些移植用的API。
哈!哈!這裡用了一些SDN的術語：
- 南向系統介面 (Southbound API)：Mesh 與 Infrastructure Layer 溝通的介面，簡單說就是Mesh與作業系統連接的API。
- 北向系統介面 (Northbound API)：這是 Framework 與 Controller連接的介面。
- 西向系統介面(Westbound API)：Framework與作業系統連接的API。
當然大部分的Wi-Fi AP都是建立在Linux系統之上，所以最底層與Linux連接的部份是Wi-Fi Driver(nl80211)與Ethernet Driver，連接的API幾乎都是用標準的Socket。
此外，Agent 在 Wi-Fi 上的操作，依然是使用 Linux 平台上標準的 hostapd 與 wpa_supplicant。
如果畫成傳統的Layer的架構，可以變成以下的圖形：
上圖就大架構而言，也許清楚了一些。上圖當中，Distribution Management主要是系統更新用的。Platform就是與作業系統有關係的API。其他兩個粉紅色的是Daemon。這都是廠商需要提供的。
在Multi-AP的方塊當中，有兩塊叫做1905.1的模組，可能各位看倌比較陌生，下面簡單介紹一下。
1905.1是IEEE訂立的標準，主要在家庭網路當中，不同的網路實體層可以透過一個標準的Protocol 來交換訊息。
1905.1沒有改變任何底層網路協定的行為或是實作方式，所以可以與現有的TCP/IP網路相容。
1905.1主要的標準，是裝置與裝置之間使用CMDU(Control Message Data Unit)交換資訊。CMDU定義了一些標準的訊息類型，例如Topology Discovery Message、Topology Notification Message、Topology Query Message、Topology Response Message、Link Metric Query Message、Link Metric Response Message等等。
訊息只是包裝成簡單的TLV(Type Length Value)格式來傳送，因此程式處理起來也非常簡單。
1905.1在MESH上面，提供兩個主要的應用：
- 讓裝置利用群播(Multicast)的方式，建立家庭網路中，個裝置的網路拓撲邏輯(Network Topology)，以及通知網路拓撲的改變(如有新的網路裝置增加，或是既有的網路裝置離線)。
- 利用單一傳播(Unicast)方式，詢問鄰近裝置的狀態，例如鄰近裝置底下有幾個網路介面、網路介面的類型等資訊，也包含了底層彼此相連的網路介面連結狀態(Link State)，如遺失封包的數量、傳輸封包的數量等。
看完上面的簡單的說明，簡單來說，如果具備以下幾樣東西，Easy Mesh的功能就已經差不多了：
- IEEE 1905.1：用來在手機上面畫出拓樸圖，如果改變，也要改變，還有一些統計資料。
- IEEE 802.11k, 802.11r、802.11v
另外一個好消息是Intel把他開發多年，原先想在物聯網上的大撈一票的，但希望始終是失望的雞肋產品：1905.1 原始碼給捐了出來。所以Framework當中最重要的拼圖就補齊了。
看到這裡，會不會有信心大增的感覺，其實這得不複雜，也不神祕，對吧!!! 接下來，就把需要界接的API，都在Layer的架構圖上，給他標示出來。
這張圖，如果上面的說明都有仔細看，紫色的縮寫就是這個連接用的API，也大致上可以看出這些API的功能。其中BML=BeeRocks Management Library當中，有一個奇怪的字"BeeRocks"；前面不是有說，這程式是Intel捐出來的嗎! "BeeRocks" 就是 Intel 捐出平台的Code Name (中文可以叫做外號或暱稱)。沒有甚麼特別的意思。"BeeRocks" 這字在程式的相關文件當中，出現的頻率可是蠻高的。
"BeeRocks" 原始來源是德國的餡餅，有包肉，也有包蘋果派。據說是先傳到阿根廷，再傳到美國。有人說俄羅斯傳到東歐，再傳美國的；在往前推，餡餅是漢朝就有的食物，蒙古人傳俄羅斯的。
接下來，用另外一個畫法說明一下三個大模組當中程式元件的關係。
這張圖是解釋Agent的大致運作，每台機器都會有一個Agent程式主控全場。此外每個Wi-Fi卡片都會有一個Radio Agent來對Wi-Fi AP做控制。
接下來是Controller的架構圖：
Controller由於需要紀錄的東西多，所以架構也複雜一些，同時有兩個小資料庫，記錄家庭網路中的一切資訊。基本上，手機的管控介面也是與這裡來連線做溝通。
接下來，就繼續依照以下的四個部份，做深入的探討：
- Framework
- Agent
- Controller
- User Interface
沒有留言:
張貼留言