2016年4月27日星期三

CoAP基礎

From:http://blog.csdn.net/xukai871105/article/details/17734163

什麼是CoAP

CoAP是受限制的應用協議(Constrained Application Protocol)的代名詞。最近幾年專家們預測會有更多的設備相互連接，而這些設備的數量將遠超人類的數量。在這種大背景下，物聯網和M2M技術應運而生。雖然對人們而言，連接入互聯網顯得方便容易，但是對於那些微型設備而言接入互聯網非常困難。在當前由PC機組成的世界，信息交換是通過TCP和應用層協議HTTP實現的。但是對於小型設備而言，實現TCP和HTTP協議顯然是一個過分的要求。為了讓小設備可以接入互聯網，CoAP協議被設計出來。CoAP是一種應用層協議，它運行於UDP協議之上而不是像HTTP那樣運行於TCP之上。CoAP協議非常小巧，最小的數據包僅為4字節。

CoAP協議是否可以替換HTTP協議？

CoAP並不能替代HTTP協議，但是對於那些小設備（256KB Flash 32KB RAM 20MHz主頻）而言CoAP的確是一個好的解決方案。

CoAP消息類型

CoAP採用與HTTP協議相同的請求響應工作模式。CoAP協議共有4中不同的消息類型。

CON——需要被確認的請求，如果CON請求被發送，那麼對方必須做出響應。

NON——不需要被確認的請求，如果NON請求被發送，那麼對方不必做出回應。

ACK——應答消息，接受到CON消息的響應。

RST——復位消息，當接收者接受到的消息包含一個錯誤，接受者解析消息或者不再關心發送者發送的內容，那麼復位消息將會被發送。

CoAP消息結構

一個CoAP消息最小為4個字節，以下是CoAP協議不同部分的描述。

【版本Version】：類似於IPv6和IPv6，僅僅是一個版本號。

【消息類型Message Type】：CON，NON，ACK，RST。

【消息ID Message ID】：每個CoAP消息都有一個ID，在一次會話中ID總是保持不變。但在這個會話之後該ID會被回收利用。

【標記Token】：標記是ID的另一種表現。

【選項Options】：CoAP選項類似於HTTP請求頭，它包括CoAP消息本身，例如CoAP端口號，CoAP主機和CoAP查詢字符串等。

【負載Payload】：真正有用的被交互的數據。

圖CoAP消息結構

CoAP的URL

在HTTP的世界中，RESTFul協議由於其簡單性和適用性，在WEB應用中越來越受歡迎，這樣的道理同樣適用於CoAP。一個CoAP資源可以被一個URI所描述，例如一個設備可以測量溫度，那麼這個溫度傳感器的URI被描述為：CoAP://machine.address:5683/sensors/temperature。請注意，CoAP的默認UDP端口號為5683。

CoAP觀察模式

在物聯網的世界中，你需要去監控某個傳感器例如溫度或濕度等。在這種情況下，CoAP客戶端並不需要不停的查詢CoAP服務器端的數據變化情況。CoAP客戶端可以發送一個觀察請求到服務器端。從該時間點開始計算，服務器便會記住客戶端的連接信息，一旦溫度發生變化，服務器將會把新結果發送給客戶端。如果客戶端不在希望獲得溫度檢測結果，那麼客戶端將會發送一個RST復位請求，此時服務器便會清除與客戶端的連接信息。

CoAP塊傳輸

CoAP協議的特點是傳輸的內容小巧精簡，但是在某些情況下不得不傳輸較大的數據。在這種情況下可以使用CoAP協議中的某個選項設定分塊傳輸的大小，那麼無論是服務器或客戶端可完成分片和組裝這兩個動作。

REF:

CoAP学习笔记

http://blog.csdn.net/xukai871105/article/details/44980041

A Great basic git learning website

http://pcottle.github.io/learnGitBranching/

2016年2月17日星期三

MPTCP 源碼分析(一) MPTCP的三次握手

From http://www.cnblogs.com/lxgeek/p/4329922.html

簡述：

MPTCP依然按照正常的TCP進行三次握手，只是在握手過程中增加了MPTCP特有的信息。

建立過程

三次握手過程如下圖所示：

　　左邊客戶端發送的第一個SYN包攜帶有客戶端自身的KEY，右邊發送SYN/ACK的時候攜帶了自身的KEY，

而最後左邊的客戶端發送最後一個ACK的時候攜帶著雙方的KEY。MPTCP中關於MP_CAPABLE的定義如下:

Subtype的定義如下：

MPTCP的內核實現

MPTCP在客戶端上發送SYN包的調用情況如下：

關鍵函數為mptcp_syn_options對MPTCP選項的填充，源碼如下：

"net/mptcp/mptcp_output.c" line 843 of 1667

843 void mptcp_syn_options(struct sock *sk, struct tcp_out_options *opts,
844 unsigned *remaining)
845 {
846 struct tcp_sock *tp = tcp_sk(sk);
847
848 opts->options |= OPTION_MPTCP;
849 if (is_master_tp(tp)) {
850 opts->mptcp_options |= OPTION_MP_CAPABLE | OPTION_TYPE_SYN;
851 *remaining -= MPTCP_SUB_LEN_CAPABLE_SYN_ALIGN;
852 opts->mp_capable.sender_key = tp->mptcp_loc_key;
853 opts->dss_csum = !!sysctl_mptcp_checksum;
854 } else {
855 struct mptcp_cb * mpcb = tp->mpcb;
856
857 opts->mptcp_options |= OPTION_MP_JOIN | OPTION_TYPE_SYN;
858 *remaining -= MPTCP_SUB_LEN_JOIN_SYN_ALIGN;
859 opts->mp_join_syns.token = mpcb->mptcp_rem_token;
860 opts->mp_join_syns.low_prio = tp-> mptcp->low_prio;
861 opts->addr_id = tp->mptcp->loc_id;
862 opts->mp_join_syns.sender_nonce = tp->mptcp->mptcp_loc_nonce;
863 }
864 }

由於三次握手的肯定是master sock，在850行到853行對MPTCP選項進行了賦值。相應的

服務端發送SYN/ACK包時使用mptcp_synack_options函數對選項進行了賦值。而最後一個ACK包

則是調用函數mptcp_established_options操作。

結論：

1. MPTCP利用TCP的三次握手進行了KEY信息的交換。

參考文獻：

1.RFC6824 https://tools.ietf.org/html/rfc6824#page-4

2016年1月12日星期二

BLE 簡介：Bluetooth low energy

From:http://shyuanliang.blogspot.tw/2014_10_01_archive.html

Basic Rate (BR; 通常意指 "BR/EDR" 即 "Basic Rate / Enhanced Data Rate")

Bluetooth low energy (BLE)。BLE 系統的設計目標就是每次傳送很小封包的資料，對比 BR/EDR裝置就可以相當明顯地節省能源。

同時能支援 BR 與 BLE 的裝置被稱為雙模 (dual-mode) 而歸類於 Bluetooth Smart Ready 名下。在手機或是筆記型電腦上，必定是配置雙模裝置。但是週邊裝置則多半會根據需求選邊站，僅支援BLE 的裝置即單模 (single mode) ，則被歸類於 Bluetooth Smart。

Bluetooth Smart Ready

代表支持雙模的裝置。

Bluetooth Smart 則是僅支援 BLE 的裝置。

傳統BT與BLE架構有什麼不一樣呢？

以上面這張Bluetooth的架構圖，可以看到Bluetooth的基礎架構仍然是維持上下兩大塊，Host及controller，中間是兩方面溝通的 HCI (Host Controller Interface)。以controller而言，原本到3.0是分為兩個controller； BR/EDR controller及AMP controller，現在將BR/EDR擴充，變為BR/EDR/LE controller，可以看到與原本的controller有一些的不同，就是在於Link Layer。而PHY(RF)及HCI也都有為了low energy(以下簡稱LE)做了補充加強。而Host，則是除了L2CAP及GAP是擴充原本加入支援LE的功能，其他的ATT protocol及GATT profile都是為了LE而新增的階層。
以上圖說明，傳統的藍牙有9種的protocol，而BLE則簡化為一個，稱作Attribute protocol(ATT)，就很像傳統藍牙用來傳資料的protocol，RFCOMM；基於ATT上面稱作Generic Attribute profile，BLE各種制定的Profile就是基於GATT的，這很重要唷。如果再將架構圖畫細一點，如下圖。

BLE與傳統BT架構有類似的階層，那就是PHY、HCI、L2CAP以及GAP，除了延用傳統BT時的舊有功能，針對BLE也做了整體性的加強。BLE一開始就是為了省電及傳資料為最主要目的，與傳統BT包山包海大不同，傳統BT不僅支援資料傳輸、語音通話、立體聲、HID，以及各式各樣的控制。但BLE所制定的profile只是要改善BT其中一部份而已，但這部份卻足以應用更加多元，讓這些新的profile更加省電。比如HDP及HID，明顯看得出來這些profile都是偏向小資料傳輸的，所以BLE並不支援聲音的傳送唷。
傳統的BT為了要支援許許多多的profile，制定了好幾種的protocol，所以所傳送的packet也有好幾種；BLE的設計就簡單多了，只有一種，ATT，只有一種packet structure，一個packet formats，當中參數不同來決定是Advertising還是Data packets，一切的一切都是為了簡單再簡單，省電再省電啦，封包小了，步驟簡化了，當然就省電啦。

協議層特性(protocol)
低功耗藍牙在與Classic BT共用的底層架構之上(L2CAP/HCI)，架構了以attribute為基礎的通訊架構(Attribute Protocol；ATT)，將設備間的通訊切割成以request/response為基礎的資料交換。在ATT之上的是GATT(Generic Attribute Profile)，定義了基於ATT進行通訊的設備之間的主從關係(Central/Peripheral/Broadcaster /Observer)、服務探索方式以及各種數據讀寫模式等等。這也是開發者所能接觸到的最底層功能。
在GATT上，應用可以依據功能 (Feature)將不同的數據群組以服務(Service)的方式發布出去，另外，針對不同需求、應用可以和一個或多個服務進行溝通，形成一個 Profile。這部分在Classic BT和低功耗藍牙之間的定義是不同的。BluetoothSIG針對常用的功能已經定義了相當數量的Service/Profile，如心跳計、體溫計等，但開發者依然可以依照自己的需求在GATT之上發揮。

Physical Layer：物理層
Link Layer：鏈路控制層
HCI：提供標準藍芽事件及通知層
Logical Link Control and Adaption Protocol：負責連接和事件
Security Manager：配對、數據加密這類
Attribute Protocol：所有數據傳輸經過這層實現(ATT)，定義了Client和Server，Client就傳Request，Server傳response。
Generic Attribute Profile：具體實現數據的傳輸(GATT)。 Server上所有的ATT都被實作了，成為一個個的。Services，通過這樣的形式把數據包給Client。把ATT定義的屬性根據不同的服務進行歸類、組合，同時把一系列的讀寫整合起來，成為一系列的數據通信操作流程，提供給上層的Profile去用。
Generic Access Prifile：設備查找、連接建立(GAP)，定義了四個角色
。Peripheral和Central：兩個設備連接後，進行通訊的角色。Peripheral通常是連接外面的設備(從設備)，例如說血壓計等等。而Central則是連接主設備，例如手機、電腦等等。Peripheral通常是ATT及GATT的Client，Central通常是ATT及GATT的Server。
。Broadcaster和Observer：兩個設備在不見連接的時後，進行通訊的角色。Broadcaster會通過一個簡單的設備，不斷的把數據丟出去，例如一個單純的溫度計。Observer則接收這些封包把相應的溫度值儲存起來。
App層：一些PROFILE和一些應用組成。在APP層經過Profile的實做，來做讀寫操作的動作。

由於Link layer在4.0是一全新的架構，其實就是簡化LM及LC，並包成LL啦。先說LC(Link Controller)，他也可以稱為Baseband基頻，這個很基本也是最先要認識的階層，比如要了解BT設備如何運作、如何連接其他的BT設備、 BT設備有哪些工作模式等。有一句話說明了LL的工作：Packets and radio control。這一階層要做的事情很基本又很多，一個一個慢慢來吧。

下面的physical layer只是很單純的傳送與接收，channel分成40個然後呢？以前每個channel的功能都一樣，現在BLE 40個channle中，3個固定的channels是專門拿來Advertising用，用來廣播(broadcast)資料，discoverability及connectability的；其他37個才是傳data用，且也會利用AFH來降傳同頻段(wifi)的干擾，提升與wifi的並存性，這樣分adv與data不同的channel來做不同的事比較有效率吧。

綠色的channel就是用來advertise的

那Advertising跟data的封包長什麼樣子？既然有分advertising及傳data，總要有流程步驟吧，所以當兩端傳送資料時每一個流程應該在每一步會定義不一樣的state狀態。

所以LL基本的工作就是要控制裝置的RF狀態，每一個狀態的工作皆不同，共有5種狀態：standby、advertising、scanning、 initiating及connected。假設有一個host及一個device，host要與device做連線，也就是都會進入connected 狀態，流程是這樣的；device會先advertising廣播告訴大家，我在這邊，我可以被連，我有哪些service，我的tx power是多少，只有扮演scanner的host才會知道有人在advertise，這就是host接下來要進入的狀態，host當找到確定的 device時，就會停止scanning轉換到initiating來對device提出連線要求，當device接受連線邀請時，就會進入 connected，同時host也會進入connected，這時候原本是initiating的是Master，而原本是advertising的則是slave。同時間Master可以建立多條LL連線，但Slave僅能有一個LL連線，既然Mater可以連好多的slave，所以已經連線後變 Master，再次要連接另一device時，又同時可身兼Scanner及Initiator，甚至可以去advertise，但是只能送non- connected advertising event，而slave的角色是connected，但還是可以advertise，也是只能送non-connected advertising event。

BLE工作的方式
BLE設備分為中心(Central)和週邊(Peripheral)兩種。其實不只兩種, 但是主要就是中心和周邊兩種。其餘的本文先不討論。
一般而言,周邊設備會產生(或擁有)資料，在平時它會不斷地發出廣播封包(broadcast)，向周遭環境通告自已的存在。
而中心設備則是不斷地掃瞄(scan)周遭環境，看看是否有可供連結的BLE週邊設備。
一旦中心設備取得某一個周邊設備的廣播資訊(主要是其藍牙位址, BD Address)之後，它就可以要求和周邊設備進行連結。連結之後，就可以互相傳送資料，進行正常的工作了。
請參閱下圖。

Advertisement間隔時間是一項重要的參數。當BLE設備很密集地廣播時，它在廣播期間的耗電量就會增加。但是若BLE設備很久才廣播一次，那麼它的反應性就會變差。因為要中心設備要花較久才能發現它的存在。
中心設備的掃瞄間隔和掃瞄窗口也是可調的。這兩個參數的調整也會影響耗電量與反應時間。反應時間快慢當然也就影響了使用者體驗的好壞。

Link layer state machine

針對Advertisr及Scanner，還有不同的定義：

Non-connectable advertising events用在裝置只想要固定時間的廣播資料，並不會構成連線的結果。
Connectable undirected advertising events用在裝置要邀請其他的裝置來連接。
Connectable directed advertising events用在裝置只允許特定裝置來連接。
Passive Scanning只有在等待advertising packets，不會要求advertiser提供額外的資訊。
Active Scanning
不僅是在等待advertising packets，也會要求advertiser提供額外的資訊。

Advertising取代了傳統BT的Discovery(Inquiry Scan)及Connection(Page Scan)，這樣一來一往最多可省掉20x power。
LL層所管理的封包也比以簡化很多，只有一個封包格式，當中Access Address參數的不同來決定是Advertising還是Data packets，以下圖是封包格式(Packet Format)。