MCS Lite 導入了我開發的 Devify 框架，所以也有 Servient 玩法喔。

認識 Servient

Servient 概念非常簡單：IoT Device 能同時扮演 Client 與 Server 的角色。這個 Client + Server = Servient 的觀念，是 Decentralized 與 P2P 非常重要的底層技術。

從 IoT Architecture 的觀念來說，並不是去辨別（identify）每一個物聯網裝置要扮演 Client 或 Server 哪一個角色，而是來開發一個能讓裝置扮演 Client + Server 角色的軟體。

為什麼需要 Servient 這樣的架構呢？這個問題，可以很容易用圖 1 來解答。

圖 1：IoT Servient

當 Device A 想要以 WebSocket 來傳送資料到 Device B 時：

• Device A 要扮演 WebSocket Client 的角色；
• Device B 則是必須成為 WebSocket Server

當 Device B 想要以 CoAP 來傳送資料到 Device C 時：

• Device B 要轉變為 CoAP Client 的角色，同時；
• Device C 則要扮演 CoAP Server 的角色

以上述的 Use Case 來說：

• Device A 是 WebSocket Client
• Device B 是 WebSocket Server + CoAP Client
• Device C 是 CoAP Server

Servient 並不是一個很普遍的架構觀念，過去在一些技術文件上也能偶然看到 Servient 的觀念；但是，Servient 在 IoT 領域被正式提及，則是在 ISWC 2016 國際研討會上。在 ISWC 2016 上，Soumya Kanti Datta 在 Semantic Web meets Internet of Things and Web of Things 的 Tutorial 上，正式提到 WoT Servient 的觀念。

近期，在 Web of Things (WoT) Architecture: Unofficial Draft 文件中，已經將 WoT Servient 編入 Terminology。隨著 WoT 在今年（2017）已經正式由 IG（Interest Group）轉為 WG（Working Group），未來 WoT 也會正式列入這個架構。

小結

當 IoT Device 能以 Servient 的形式運作，IoT Device 間的「互聯網」：互相聯結的 IoT 網路，就可以是 Client-Server 架構、Peer-to-Peer 架構或是 Distributed 架構。

關於 MCS Lite

關於 IoT Servient 的技術，在 Devify 專案裡有完整的實作。Devify 是我過去在研究物聯網區塊鏈時做開發的底層 WoT 系統。

由聯發科所開發的 LinkIt 7697 物聯網平台，提供一個稱為 MCS Lite 的私有雲方案；MCS Lite 裡就使用到我所開發的 Devify 框架。也就是說，LinkIt 7697 + MCS Lite 還有更多 IoT 的完法喔。

Flowchain 使用一個稱為 Chord 的 P2P 通訊協定，flowchain-chord 是一份 Node.js 的實作。

近來受到相當程度討論的去中心化（Decentralized）概念，則是基於 Peer-to-Peer 通訊網路的分散式系統。Peer-to-Peer 的研究在 2000 年左右，就已經有相關的研究論文發表。Decentralized 與 Block Store 的觀念，在這裡論文裡已經被提出討論。可見這二個目前廣為討論的觀念（Decentralized 與 Block Store）都不是新鮮技術了。

關於 DHT 與 Chord Protocol

Chord[1] 是一個 DHT（distributed hash table）通訊協定，在 peer-to-peer 通訊網路中，DHT 指的是節點（nodes）的 store，用來儲存「資料的負責節點」。因此，Chord 協定能讓 P2P 網路尋找 Data 的負責節點，Chord 協定同時也維護所謂的指向表（Finger Table）來提升尋找節點的效能。Chord 於 2001 年誕生於 MIT[2][3]。

除了 Chord 外，連同其它 3 個 P2P 演算法：CAN、Tapestry 與 Pastry，被稱為 P2P 的 4 大原始演算法。P2P 演算法會維護一份稱為 DHT 的表格，這個表格便是用來紀錄「資料的負責節點」；以 Chord 為例，如果有一筆資料 D1 被送進 P2P 網路裡，負責處理這筆資料的節點稱為 successor，以 sucessor(D1) 來表示，successor() 函數將傳遞進來的資料做 Hash 運算，以 successor(D1)=key1 來表示。

簡而言之，P2P 透過 DHT 來找到負責處理資料的人。Flowchain 區塊鏈就是使用 Chord 來維護 DHT；關於 Chord Protocol 的研究，會參考 MIT Chord/DHash 的原始實作。這是一份 C++ 的實作，Flowchain 則是使用 JavaScript 重新實作了一份輕量化的 Chord 協定。

Chord Protocols

Chord protocols 分為 5 個部份：

• Basic query
• Finger table
• Node join
• Stabilization
• Failures and replication

Stabilization 算法

這是 Chord protocol 最重要的一個環節，根據 Chord protocol 的規範：

• Stabilization protocol 是週期性地（periodically）在背景執行
• 更新 finger table 與 successor pointers

以 JavaScript 來實現 stabilization protocol 的方式：

• 使用 setInterval 實現週期性執行（理論上這可以有更好的 scheduling 實現）

Stabilization protocol 的算法分二個部份：

• Stabilize()
• Nofity()

先定義 Stabilized() 與 Notify() 的訊息：

// 定義訊息類型
var FIND_PREDECESSOR = 0;
var NOTIFY_PREDECESSOR = 1;

其中，Stabilized() 負責向 successor 請求它的 predecessor，並決定 predecessor 是否要成為新的 sucessor：

setInterval(function Stabilize() {
// 請求 predecessor，並將 predecessor 做為新的 successor
    send(successor, {type: FIND_SUCCESSOR, next: next_finger});
}, 1000);

此外，Notify() 負責告知 sucessor 我是它的 node，讓 successor 能更新 finger table：

setInterval(function check_predecessor_and_stabilize() {
// 向 successor 請求 predecessor
    send(successor, {type: NOTIFY_PREDECESSOR});
}, 1000);

Node join

新的 node 建立時，要執行以下任務：

• 初始化 node 的 predecessor 與 finger table
• 通知其它 nodes 更新 predecessors 與 finger table
• 從 sucessor 取得 responsible keys

Finger Table

Finger table 是 Chord 的搜尋演算法。Node 可以經由 finger table 來找到任意節點。Finger table 的演算法設計，搜尋節點的關鍵，它可以避免線性（linear）搜尋的做法。每一個 node 都會有 finger table，finger table 的第 i 個 entry 紀錄的是 sucessor( (n + 2^(i-1)) mod 2^m )。

• m 是 ring 長度，也就是finger table 的長度。這是 Chord network 的最大（最多）節點數量。
• successor 與 predecessor 是重要的觀念。

Finger table 是一個 hash ring 的結構。Chord 經由 predecessor 的觀念，來簡化 join 與 leave 的機制[2]。

小結

要以 P2P Topology 方式建構 IoT Blockchain，對於 P2P 演算法的深入研究，絕對是一項基本功。

References

[1]: Chord, https://en.wikipedia.org/wiki/Chord_(peer-to-peer)

[2]: I. Stoica, et al, Chord: A scalable peer-to-peer lookup service for internet applications

[3]: LibraRing: An Architecture for Distributed Digital Libraries Based on DHTs, http://scholar.harvard.edu/files/ecdl05.pdf

[4]: CS138, http://cs.brown.edu/courses/cs138/s15/content/projects/chord.pdf

[5]: Distributed Hash Tables, http://merlot.usc.edu/cs551-m05/lectures/tentative/20a_chord.pdf

Chord 能運用在 Peer-to-Peer 的 IoT 網路，但是有些技術細節必須從軟體架構的層面解決。第一個會面的技術問題，就是「Churn」現象。

進進出出

所謂的 Churn 現象就是：在 Peer-to-Peer 網路中，隨時都有節點（node）加入或離開（進進出出）。對於 Churn 的處理，要根據不同的 P2P 演算法來進行研究。Chord 如何處理 Churn 問題，以及 Handling Churn 的效能分析，過去已經有許多研究論文提出解決方法。

至於 Flowchain 區塊鏈 當然也有針對 Churn 進行研究。在 Flowchain 裡面，處理 Churn 現象的方式，是以擴充 Chord Protocols 的方式來進行處理；這方面的研究，已經撰寫成學術論文，並且被 AIoTAS 2017 接受並發表。

Churn Rates

當 P2P 網路的節點，很頻繁地加入或離開時，這個網路稱為 High Churn Rates。如果 IoT Blockchain 無法有效處理 High Churn Rates 的問題，Data Transactions 的能力就會降低。例如，有資料需要交易處理時，就要經由 DHT 裡找到負責節點，但這個節點可能已經離開了。

IoT 裝置會離開 P2P 網路的原因，可能是 Wi-Fi 訊號不良，也可能是電量問題等其它問題；這和以 PC 為主的典型 P2P 網路非常不同。例如：PC 並非電池式裝置，因此電池式裝置的 Churn Rates，理論上會比 PC 為主的 P2P 網路高。又如，Wi-Fi 訊號問題，造成 P2P 網路中，經常有裝置會離線，這又是另一個造成 High Churn Rates 的因素。

小結

原生 P2P 演算法要應用在 IoT Blockchain，需要處理演算法上的一些細節。

Heterogenous Hardware 的觀念非常簡單：各式各樣的硬體裝置。

各式各樣的硬體裝置

Heterogenous Hardware 的目標更為單純：「Write once, run everywhere」。對 IoT Blockchain 來說，是否能打造一套能在各式各樣硬體裝置上執行的軟體框架，會是一個關鍵議題。

使用 JavaScript 來實作 IoT 系統是一個流行，但更實質的原因，則是為了 Heterogenous Hardware。如圖一，Flowchain 以及它的底層通訊系統（Devify）都是 100% 的 JavaScript 實作，這可以解決基本的移植性問題。以現今的 IoT Device 硬體技術來說，Flowchain 能安裝在 Microcontroller、Microprocessor 與 Cloud Server 上。

Flowchain 基礎架構

Flowchain 是一個從底層到上層，都使用 JavaScript 實作的軟體框架（Fullstack JavaScript）。不過，區塊鏈要能支援 Heterogenous Hardware，共識算法的研究與設計，才是真正的關鍵。

小結

原生 P2P 演算法要應用在 IoT Blockchain，需要處理演算法上的一些細節。