本發(fā)明實施例涉及網(wǎng)絡(luò)通信領(lǐng)域，并且更具體地涉及數(shù)據(jù)資源傳輸?shù)姆椒ê驮O(shè)備。

背景技術(shù)：

輕量級應(yīng)用層協(xié)議(constrainedapplicationprotocol，簡稱“coap”)主要是用于物聯(lián)網(wǎng)(machinetomachine，簡稱“m2m”)的場景中，比如：家庭控制器、樓宇自動化、智能能源、傳感器網(wǎng)絡(luò)等。在這樣的環(huán)境中，這些機器的功能比較簡單，一般處理器只有8位，存儲空間小，不支持復(fù)雜的傳輸協(xié)議，數(shù)據(jù)傳輸速率也較低。coap提供一種請求/響應(yīng)的交互模式，支持內(nèi)嵌的資源發(fā)現(xiàn)，包括關(guān)鍵的網(wǎng)頁概念，比如統(tǒng)一資源標識(uri)和內(nèi)容類型。coap可以很容易地翻譯到超文本鏈接協(xié)議(http)，用于集成到網(wǎng)絡(luò)中?；赾oap傳輸數(shù)據(jù)的傳統(tǒng)方案中不計算數(shù)據(jù)資源的準確容量，無法評估分包的精確數(shù)目，因此無法并發(fā)獲取數(shù)據(jù)資源，造成傳輸效率低下。

另外由于很多使用coap的設(shè)備處理能力較低，最大傳輸速率也低，所以在激活多個連接或者同時處理多個請求時，coap設(shè)備就很容易面臨擁塞問題，導(dǎo)致無法及時處理后續(xù)新發(fā)生的任務(wù)。為了解決擁塞，現(xiàn)有coap協(xié)議中規(guī)定了一種消息重發(fā)控制機制，當(dāng)coap客戶端設(shè)備向服務(wù)器設(shè)備發(fā)送的需要確認的(confirmable)消息并且長時間沒有得到響應(yīng)時(擁塞等問題導(dǎo)致)，客戶端設(shè)備會在tn秒后重發(fā)該消息并重復(fù)若干次，直到收到服務(wù)器設(shè)備發(fā)回的響應(yīng)消息或者達到最大重發(fā)次數(shù)限制而放棄嘗試；設(shè)默認重發(fā)間隔為x秒且當(dāng)前為第n次重發(fā)，則tn＝x+random(0～2ⁿ)，其中random(0～2ⁿ)為0到2ⁿ之間的任一隨機整數(shù)，因此該方法也被稱為指數(shù)后退算法，每次重發(fā)的時間間隔以指數(shù)級增加，給予服務(wù)器設(shè)備更寬松的響應(yīng)時間。但現(xiàn)有技術(shù)使用的算法是基于時隙的，消息級別的擁塞控制，并不能有效解決節(jié)點級別的擁塞問題，當(dāng)server因為資源處理能力達到瓶頸，或者發(fā)生異常的時候，指數(shù)后退就顯得杯水車薪了，而且因為是client端的隨機算法，也完全沒有考慮到server的具體狀態(tài)，嚴重時候可能會進一步加重擁塞。

技術(shù)實現(xiàn)要素：

本發(fā)明實施例提供了一種數(shù)據(jù)資源傳輸?shù)姆椒ê驮O(shè)備，能夠支持在coap中提高傳輸效率。

在本發(fā)明實施例中，提供了一種在物聯(lián)網(wǎng)系統(tǒng)中基于輕量級應(yīng)用層協(xié)議的節(jié)點的數(shù)據(jù)資源傳輸方法，包括：向服務(wù)器發(fā)送攜帶響應(yīng)方式選項的請求消息，其中所述響應(yīng)方式選項表示以下響應(yīng)方式其中一項：一次性的立即響應(yīng)、推遲的一次性的響應(yīng)、推遲的多個響應(yīng)和取消推遲的多個響應(yīng)；接收所述服務(wù)器發(fā)送的根據(jù)所述響應(yīng)方式選項生成的響應(yīng)消息

在本發(fā)明實施例中，提供了一種在物聯(lián)網(wǎng)系統(tǒng)中基于輕量級應(yīng)用層協(xié)議的節(jié)點的數(shù)據(jù)資源傳輸方法，包括：接收客戶端發(fā)送的攜帶響應(yīng)方式選項的請求消息，其中所述響應(yīng)方式選項表示以下響應(yīng)方式其中一項：一次性的立即響應(yīng)、推遲的一次性的響應(yīng)、推遲的多個響應(yīng)和取消推遲的多個響應(yīng)；向客戶端發(fā)送根據(jù)所述響應(yīng)方式選項生成的響應(yīng)消息。

在本發(fā)明實施例中，提供了一種在物聯(lián)網(wǎng)系統(tǒng)中基于輕量級應(yīng)用層協(xié)議傳輸節(jié)點的數(shù)據(jù)資源的客戶端，包括：發(fā)送模塊，用于向服務(wù)器發(fā)送攜帶響應(yīng)方式選項的請求消息，其中所述響應(yīng)方式選項表示以下響應(yīng)方式其中一項：一次性的立即響應(yīng)、推遲的一次性的響應(yīng)、推遲的多個響應(yīng)和取消推遲的多個響應(yīng)；接收模塊，用于接收根據(jù)響應(yīng)方式選項生成的響應(yīng)消息。

在本發(fā)明實施例中，提供了一種在物聯(lián)網(wǎng)系統(tǒng)中基于輕量級應(yīng)用層協(xié)議傳輸節(jié)點的數(shù)據(jù)資源的服務(wù)器設(shè)備，包括：接收模塊，用于接收客戶端發(fā)送的攜帶響應(yīng)方式選項的請求消息，其中所述響應(yīng)方式選項表示以下響應(yīng)方式其中一項：一次性的立即響應(yīng)、推遲的一次性的響應(yīng)、推遲的多個響應(yīng)和取消推遲的多個響應(yīng)；發(fā)送模塊，向所述客戶端發(fā)送根據(jù)所述響應(yīng)方式選項生成的響應(yīng)消息。

根據(jù)本發(fā)明實施例，通過在消息交互過程中指定響應(yīng)方式選項，客戶端可以指定所需的響應(yīng)，提高了coap的消息交互效率。

根據(jù)本發(fā)明實施例，可以對響應(yīng)方式進行指示，并根據(jù)所指示的響應(yīng)方式接收響應(yīng)消息，這樣便于請求方進行會話處理，以提高傳輸效率，比如：在指示延遲響應(yīng)時間的情況下，避免請求方一直等待響應(yīng)消息，可以在指示的延遲時間過期后，提前結(jié)束會話；在請求方指示立即響應(yīng)時，如果在請求方自定義的超時時間內(nèi)，不能接收到響應(yīng)消息，也可以提前結(jié)束會話；在指示延遲的多次響應(yīng)時，請求方可以保存資源訂閱的信息，以便于接收多個推遲的響應(yīng)。

附圖說明

為了更清楚地說明本發(fā)明實施例的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動性的前提下，還可以根據(jù)這些附圖獲得其他的附圖。在附圖中：

圖1是本發(fā)明一種實施例的傳輸數(shù)據(jù)的方法的流程圖；

圖2是本發(fā)明一種實施例的網(wǎng)關(guān)從傳感器獲取數(shù)據(jù)資源的具體實現(xiàn)過程的流程圖；

圖3是本發(fā)明一種實施例中改進的分片選項的結(jié)構(gòu)圖；

圖4是本發(fā)明一種替代實施例的網(wǎng)關(guān)從傳感器獲取數(shù)據(jù)資源具體實現(xiàn)過程的流程圖；

圖5是本發(fā)明一種替代實施例中改進的分片選項的結(jié)構(gòu)圖；

圖6是本發(fā)明一種替代實施例的網(wǎng)關(guān)從傳感器獲取數(shù)據(jù)資源的具體實現(xiàn)過程的流程圖；

圖7是本發(fā)明一種替代實施例中改進的分片選項的結(jié)構(gòu)圖；

圖8是本發(fā)明一種實施例的網(wǎng)關(guān)向傳感器發(fā)送數(shù)據(jù)資源的具體實現(xiàn)過程的流程圖；

圖9是本發(fā)明一種實施例的客戶端設(shè)備的框圖；

圖10是本發(fā)明一種實施例的服務(wù)器設(shè)備的框圖；

圖11是本發(fā)明一種實施例的傳輸數(shù)據(jù)的方法的流程圖；

圖12是本發(fā)明一種實施例的傳輸數(shù)據(jù)的方法的流程圖；

圖13是本發(fā)明一種實施例的消息交互圖；

圖14是本發(fā)明一種實施例的消息交互圖；

圖15是本發(fā)明一種實施例的消息交互圖；

圖16是本發(fā)明一種實施例的傳輸數(shù)據(jù)的客戶端的結(jié)構(gòu)圖；

圖17是本發(fā)明一種實施例的傳輸數(shù)據(jù)的服務(wù)器的結(jié)構(gòu)圖。

具體實施方式

下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

coap是基于用戶數(shù)據(jù)報協(xié)議(userdatagramprotocol，簡稱“udp”)進行傳輸，是基于無連接的消息處理模式。其交互模式可以是同步的響應(yīng)，也可以是異步的響應(yīng)。消息類型可以是：需要確認的消息(confirmable)、不需要確認的消息(non-confirmable)、確認消息(acknowledgement)、重置消息(reset)?？梢酝ㄟ^消息標識(messageid)來關(guān)聯(lián)一對請求和響應(yīng)。

coap支持的方法有四個：獲取資源(get)、更新資源(put)、創(chuàng)建資源(post)和刪除資源(delete)。資源通過表述性狀態(tài)轉(zhuǎn)移(representationalstatetransfer，簡稱“rest”)uri來識別。我們通常稱資源的擁有方為節(jié)點或服務(wù)器，包括但不限于傳感器、控制器、端點(end-point)等，請求資源方為客戶端，包括但不限于網(wǎng)關(guān)(proxy)、網(wǎng)絡(luò)側(cè)設(shè)備。

coap協(xié)議支持不同的選項(option)，用以解釋coap消息體中數(shù)據(jù)的語義，比如block(分片)、location(位置)、token(令牌)選項等，不同的選項支持不同的功能，并且可以通過定義新的option來擴展新的功能。

coap支持分片選項(blockoption)，主要用于將較大的資源進行分片傳輸，以適應(yīng)于低帶寬傳輸?shù)膽?yīng)用場景。block選項可以為1個字節(jié)、2個字節(jié)或3個字節(jié)，依據(jù)分片數(shù)目的容量所需要的長度進行選取。

傳統(tǒng)方案中不計算數(shù)據(jù)資源的準確容量，無法評估分包的精確數(shù)目，因此無法并發(fā)獲取。另外也不知道資源是靜態(tài)的還是動態(tài)的。

在以下描述中，通常稱資源的擁有方為服務(wù)器，以傳感器作為示例，請求資源方為客戶端，以網(wǎng)關(guān)作為示例。但是，傳感器或者網(wǎng)關(guān)并不用作對服務(wù)器或者客戶端的限制。

由于不知道目標資源的精確容量，網(wǎng)關(guān)在<get>命令中使用blockoption時，只能按順序來獲取，即選獲取block0，等block0返回時，再獲取block1，一直到最后一個block。不能并發(fā)地發(fā)送<get>請求。

block選項的字段結(jié)構(gòu)一般包括num字段，m字段和szx字段，其中

num表示分片的順序序號，可以是4～20位的無符號整型數(shù)字。0表示第一個分片。

m：用一個比特位來表示當(dāng)前分片后面是否還有其他分片，其值為1表示后面還有分片，為0表示后面沒有分片，即為最后一個分片。

szx：用于表征分片容量，其計算公式為：分片容量＝2^(szx+4)，即2的(szx+4)次方。由于szx由3個比特位來表示，其值可以為0～7，所以分片容量的取值范圍：2^4～2^11，即16～2048。

對于block選項的使用說明如下：

在<get>請求中，block選項的num字段給出當(dāng)前請求的分片的序號，并且當(dāng)分片序號為0時，szx給出網(wǎng)關(guān)建議的每個分片的容量。在<get>響應(yīng)中或是<put>/<post>請求中，block選項的num字段描述當(dāng)前傳輸?shù)姆制男蛱枺琺字段表明后面是否還有后續(xù)分片。

在<put>/<post>響應(yīng)中，block選項的num字段表明當(dāng)前響應(yīng)的分片序號。

當(dāng)網(wǎng)關(guān)使用<get>方法獲取第一個分片(block)時，num被設(shè)置為0，并攜帶建議的分片容量(即szx)，傳感器節(jié)點可以選擇同意建議的分片容量，或是選擇一個比建議分片小的分片，并在響應(yīng)中返回，同時，在響應(yīng)中返回第一個分片的數(shù)據(jù)。

本發(fā)明考慮網(wǎng)關(guān)事先獲知目標資源的精確容量，則網(wǎng)關(guān)可以選擇是否用blockoption來發(fā)送資源獲取的請求，也可以實現(xiàn)并發(fā)請求，即在請求block0的同時，也可以請求block1，而不必等待。在請求block的順序上也可以靈活處理。

簡單設(shè)計方案中，blockoption有三個選擇，可以是一個字節(jié)，可以是2個字節(jié)，也可以是三個字節(jié)，依據(jù)資源的容量不同，分片(block)的數(shù)量容量不同，所需要的長度也不一樣。協(xié)議規(guī)定，除了最后一個分片外，分片的容量必須相同，但每次傳輸中，還是每次都需要攜帶m位(表明后面是否還有分片)和szx(分片的容量)。

每次在請求和響應(yīng)中，m位和szx位都需要傳送，而實際上，除了最后一個分片外，m位和szx的值每次都是相同的，重復(fù)的傳輸浪費傳輸資源。重復(fù)發(fā)送szx的目的假定雙方都不保存協(xié)商后的szx，第一次響應(yīng)中攜帶的是協(xié)商后的szx，網(wǎng)關(guān)從響應(yīng)中獲取并再次在請求中發(fā)送，從而網(wǎng)關(guān)和傳感器都不需要保存狀態(tài)。在一次的請求響應(yīng)回合中，共浪費一個字節(jié)，如果分片數(shù)目很多時，浪費的字節(jié)就很多了，對于m2m設(shè)備，傳輸資源是受限的，這個傳輸資源的浪費是很可觀的。假設(shè)要傳送的數(shù)據(jù)為64m的話，每個block的負載(payload)容量為1024byte則發(fā)送的block條目數(shù)為：65536。則發(fā)送的block選項按照字節(jié)來分的個數(shù)為：

(1)一個字節(jié)：16個

(2)兩個字節(jié)：4080個

(3)三個字節(jié)：61440個

如果m和szx可以不發(fā)送，則請求加上響應(yīng)能夠節(jié)省的數(shù)據(jù)為65536字節(jié)(byte)，即64k數(shù)據(jù)。另外，如果這兩個字段不要，則num字段可以用滿所有位(bit)，則需要發(fā)送的數(shù)據(jù)包的數(shù)目變更為：

(1)一個字節(jié)：256個

(2)兩個字節(jié)：65280個

此時不需要發(fā)送3個字節(jié)的結(jié)構(gòu)，因此還可以節(jié)省數(shù)據(jù)為61440*2bytes，即60k數(shù)據(jù)。則總共節(jié)省數(shù)據(jù)位124k，節(jié)省數(shù)據(jù)率0.189％。頭域節(jié)省百分比為(16+4080*2+61440*3-256-65280*2)/(16+4080*2+61440*3)＝61680/192496＝32％。

節(jié)省數(shù)據(jù)量的公式：

t為總的block數(shù)量，s為分片容量(blocksize)，節(jié)省的流量的百分比(只比較頭域)：

t<16時：無節(jié)省；兩者都是一個字節(jié)；

16<t<256時：1-t*1/(16*1+(t-16)*2)，簡單設(shè)計方案需要2個字節(jié)，優(yōu)選方案只需要一個字節(jié)；

256<t<4096時：1-(256*1+(t-256)*2))/(16*1+(t-16)*2)，簡單設(shè)計方案需要2個字節(jié)，優(yōu)選方案需要2個字節(jié)；

4096<t<65256時：1-(256*1+(4096-256)*2+(t-4096)*3))/(256*1+(t-256)*2)，簡單設(shè)計方案需要3個字節(jié)，優(yōu)選方案需要2個字節(jié)。

t>65256時，無節(jié)省，本發(fā)明優(yōu)選方案實施例和簡單設(shè)計方案都需要3個字節(jié)。

簡單設(shè)計方案中，使用put/post命令時，分片容量協(xié)商缺乏效率。在put/post請求中，對于第一個分片，需要發(fā)送第一個分片的數(shù)據(jù)和推薦的分片容量，如果傳感器節(jié)點選擇不一樣的分片容量，網(wǎng)關(guān)需要按照傳感器的分片容量進行重新發(fā)送，則上次發(fā)送的分片數(shù)據(jù)被浪費掉了。而且，網(wǎng)關(guān)在使用put/post請求基于分片選項發(fā)送容量大的資源時，事先無法告知傳感器資源容量信息，在傳輸過程中，傳感器邊接收，邊緩存所接收的資源，如果傳感器發(fā)現(xiàn)存儲空間不夠，而資源又未傳輸完成時，只能發(fā)送回一個413的錯誤狀態(tài)碼，表示請求的資源太大，結(jié)束此次傳輸。此前傳輸?shù)牟糠仲Y源則沒用了，傳輸資源被浪費了。如果網(wǎng)關(guān)能夠在第一個分片消息中告知傳感器所要傳輸?shù)馁Y源的容量信息，傳感器則可以比較資源容量信息與存儲容量，如果容量不足，提前返回413“請求的資源太大”的狀態(tài)碼，來結(jié)束資源傳輸，以此來達到節(jié)省傳輸資源的目的。

互聯(lián)網(wǎng)上的斷點續(xù)傳，也就是要從文件已經(jīng)下載的地方開始繼續(xù)下載。網(wǎng)關(guān)在向傳感器請求數(shù)據(jù)的時候，要多加一條信息來表示請求下載數(shù)據(jù)的范圍(range)，表明從哪里開始。

比如，網(wǎng)關(guān)用瀏覽器來傳遞請求信息給web傳感器，要求從2000070字節(jié)開始：

get/down.ziphttp/1.0

user-agent:netfox

range:bytes＝2000070-

accept:text/html,image/gif,image/jpeg,*；q＝.2,*/*；q＝.2

其中，range:bytes＝2000070-，這一行的意思就是告訴傳感器down.zip這個文件從2000070字節(jié)開始傳，前面的字節(jié)不用傳了。

這種方案的缺點是，沒有分片機制，不支持分片容量的協(xié)商，也不支持分片總數(shù)的協(xié)商。本發(fā)明實施例考慮了在分片傳輸過程中，進行分片容量和/或分片總數(shù)的協(xié)商。為此本發(fā)明提供了一種數(shù)據(jù)分片傳輸?shù)姆椒?，可以獲取目標數(shù)據(jù)資源的精確容量，進行分片容量的協(xié)商，獲取分片總數(shù)，并根據(jù)分片總數(shù)進行數(shù)據(jù)資源傳輸。

以下參照圖1具體說明本發(fā)明一種實施例的流程。圖1是本發(fā)明一種實施例的流程圖。

在s110過程中，獲取節(jié)點的數(shù)據(jù)資源的容量信息。如果是網(wǎng)關(guān)從傳感器獲取數(shù)據(jù)，則節(jié)點的數(shù)據(jù)資源容量信息保存在傳感器上。網(wǎng)關(guān)可以通過請求消息，向傳感器獲取節(jié)點的數(shù)據(jù)資源的容量信息。如果是網(wǎng)關(guān)向傳感器發(fā)送數(shù)據(jù)，則網(wǎng)關(guān)本地已經(jīng)知道了節(jié)點的數(shù)據(jù)資源的容量信息。獲取節(jié)點的數(shù)據(jù)資源容量信息，是為下一步進行分片容量的協(xié)商并確定分片總數(shù)做準備。

接著，在s120的過程中，網(wǎng)關(guān)向傳感器發(fā)送攜帶第一分片選項的請求消息，其中所述第一分片選項包括推薦的分片容量。傳感器在收到s120中發(fā)送的請求消息之后，根據(jù)自身能力，確定本次數(shù)據(jù)資源傳輸過程中所使用的分片容量，并且傳感器確定的分片容量小于等于網(wǎng)關(guān)推薦的分片容量。

在s130，網(wǎng)關(guān)接收攜帶第二分片選項的響應(yīng)消息，其中所述第二分片選項包括確定的分片容量，所述確定的分片容量小于等于所述推薦的分片容量。網(wǎng)關(guān)在接到確定的分片容量之后，根據(jù)掌握的節(jié)點的數(shù)據(jù)資源容量信息，確定將要傳輸?shù)墓?jié)點的數(shù)據(jù)資源的分片總數(shù)。

然后，在s140，根據(jù)所述確定的分片容量以及所述節(jié)點的數(shù)據(jù)資源容量信息，分片傳輸所述數(shù)據(jù)資源。

根據(jù)本發(fā)明實施例，可以獲知需要傳輸?shù)臄?shù)據(jù)資源的容量信息，并通過分片容量協(xié)商確定傳輸數(shù)據(jù)時使用的分片容量，由此可以實現(xiàn)傳輸過程中錯誤率降低，并且可以并發(fā)地傳輸數(shù)據(jù)。

以下結(jié)合圖2說明如圖1所示實施例的具體實現(xiàn)過程。圖2表示的是網(wǎng)關(guān)從傳感器獲取數(shù)據(jù)的說明性示例，僅為說明本發(fā)明的構(gòu)思，而不作為對本發(fā)明的限制。

圖2所示數(shù)據(jù)資源獲取過程具體描述如下：

es210：網(wǎng)關(guān)向傳感器發(fā)送資源發(fā)現(xiàn)請求，即通過get./wellknown/core來獲取傳感器上的資源列表。

es220：傳感器向網(wǎng)關(guān)返回資源列表，以及資源指示信息；資源指示信息主要包括資源的尋址信息(即uri)、資源名稱、資源描述信息、內(nèi)容類型等。本發(fā)明對資源指示信息進行擴展，擴展的資源指示信息包括：資源是動態(tài)資源還是靜態(tài)資源的指示信息。

es230：網(wǎng)關(guān)根據(jù)傳感器返回的資源列表，根據(jù)資源的指示信息，從中選擇目標資源，并根據(jù)識別標識(能唯一識別資源的信息，比如資源名稱、uri等)，獲取目標資源。

es240：傳感器對目標資源容量進行判斷，如果資源容量小于一個傳輸層消息包的容量，則直接返回資源內(nèi)容給網(wǎng)關(guān)；如果資源容量超過一個傳輸層消息包的容量，則返回資源容量信息。可選地，傳感器可使用分片選項，根據(jù)自身確定的分片容量，直接返回第一個分片。后續(xù)客戶端和傳感器根據(jù)此確定的分片容量，使用分片選項傳輸如下的分片。

在本發(fā)明一種替代實施例中，如果目標數(shù)據(jù)資源為動態(tài)數(shù)據(jù)資源，同時返回動態(tài)數(shù)據(jù)資源指示給網(wǎng)關(guān)，并用413“請求資源太大”的狀態(tài)碼指示網(wǎng)關(guān)使用block選項來獲取資源。

如果數(shù)據(jù)資源為動態(tài)資源，則指示信息中的資源容量表示的是當(dāng)前的資源快照(snapshot)的容量信息，傳感器需要緩存此快照數(shù)據(jù)；如果是靜態(tài)資源，則指示信息中的資源容量信息是精確的容量信息。本領(lǐng)域技術(shù)人員應(yīng)該理解，如果數(shù)據(jù)資源為動態(tài)資源，則傳感器可以發(fā)送資源快照的校驗碼，網(wǎng)關(guān)如果需要更新鮮的數(shù)據(jù)，可以后續(xù)再發(fā)送新的資源獲取請求。

es250：網(wǎng)關(guān)根據(jù)數(shù)據(jù)資源容量信息，判斷需要使用分片選項，并發(fā)送攜帶分片選項的請求消息，與傳感器器進行分片容量協(xié)商，指示推薦的分片容量。

es260：傳感器根據(jù)自身能力，確定分片容量，并將其返回給網(wǎng)關(guān)?？蛇x地，傳感器同時返回分片總數(shù)。當(dāng)然，由于網(wǎng)關(guān)已經(jīng)獲取了數(shù)據(jù)資源容量信息，分片總數(shù)也可以由網(wǎng)關(guān)確定。需要說明的是，傳感器確定的分片容量只能小于或等于網(wǎng)關(guān)推薦的分片容量。

es270：網(wǎng)關(guān)從1一直到分片總數(shù)，依次向傳感器發(fā)送請求，請求獲取與分片序號對應(yīng)的數(shù)據(jù)資源的分片數(shù)據(jù)。

es280：傳感器根據(jù)確定的分片容量，返回該分片序號及與該分片序號對應(yīng)的數(shù)據(jù)資源的分片數(shù)據(jù)，直到完全傳輸完畢。

根據(jù)本發(fā)明的一種優(yōu)選實施例，es270中可以實現(xiàn)并行處理，即網(wǎng)關(guān)可以同時請求獲取多個分片消息，而不需要等待傳感器返回對前一個分片請求消息的響應(yīng)消息。

es210至es240的代碼例如為：

req:get/.well-known/core---發(fā)送請求到默認的uri，即根目錄獲取資源列表；

res:200ok--響應(yīng)標識獲取成功，并攜帶了2組資源指示信息；

</sensors/temp>；ct＝41；n＝"temperaturec",--溫度資源，內(nèi)容類型41，名稱為temperaturec；

</sensors/light>；ct＝41；n＝"lightlux"--燈光資源，內(nèi)容類型41，名稱為lightlux；

</sensors/firmware>；ct＝52；n＝"firmware"；snapshot＝0--固件資源，內(nèi)容類型52，名稱為firmware，非動態(tài)資源；

</sensors/log>；ct＝52；n＝"log"；snapshot＝1--固件資源，內(nèi)容類型52，名稱為log，動態(tài)資源，當(dāng)前數(shù)據(jù)為快照snapshot；

req:get/sensors/firmware–請求固件資源

res:413“requestentitytoolarge”size:88000.413狀態(tài)碼表明請求的資源太大，其精確容量為88000字節(jié)。

如果數(shù)據(jù)資源為動態(tài)資源，即數(shù)據(jù)資源在傳輸?shù)倪^程會動態(tài)變化，例如可以采用以下兩種方案實施處理：

(1)在開始傳送數(shù)據(jù)資源時，對該資源建立快照(snapshot)，即緩存此刻該數(shù)據(jù)資源的容量信息，并傳輸這個容量信息，不管后續(xù)的變化；對應(yīng)上述方案。

(2)如果數(shù)據(jù)資源在傳輸過程中被修改，傳感器可以在任意一個獲取數(shù)據(jù)資源的請求消息的響應(yīng)消息中，返回錯誤碼，指示數(shù)據(jù)資源已更改，網(wǎng)關(guān)需要重新獲取。

可選地，網(wǎng)關(guān)和傳感器在消息交互中，增加認證信息。認證信息中可包含身份標識(id)、基于身份標識和密碼(password)算出來的密鑰信息(digest)。身份標識和密碼可以是預(yù)先配置給網(wǎng)關(guān)和傳感器雙方。配置過程：

例如，密鑰的算法可以為：digest＝md5(id:password)，即對id和password組成的字符串使用md5算法進行哈希(hash)，hash的值為digest。發(fā)送方發(fā)送id和digest，接收方根據(jù)接收到id和預(yù)先存儲的password，根據(jù)同樣的算法得出digest，與發(fā)送方發(fā)送的digest進行比較，如果一致，則認證通過。

網(wǎng)關(guān)從傳感器獲取數(shù)據(jù)資源時，如圖2所示，需要知道數(shù)據(jù)資源容量信息。根據(jù)本發(fā)明一種實施例，網(wǎng)關(guān)可以采用如下方案來獲取存儲于傳感器的數(shù)據(jù)資源容量信息。

(1)擴展鏈接格式(link-format)關(guān)鍵字

在link-format中，擴展一個關(guān)鍵字，-sn，或-snapshot，用于在獲取數(shù)據(jù)資源請求的響應(yīng)中，表明資源數(shù)據(jù)是否是快照數(shù)據(jù)。如果此參數(shù)不存在，或其值為0，表明是靜態(tài)資源，如果此參數(shù)的值為1，則表明是當(dāng)前數(shù)據(jù)是動態(tài)資源，獲取的數(shù)據(jù)是當(dāng)前的快照。靜態(tài)資源是指一段時間內(nèi)相對穩(wěn)定的資源，即資源內(nèi)容不會頻繁更改。具體含義可以在標準中進行定義。在本發(fā)明中，主要指資源的值不改變的情況。

還擴展關(guān)鍵字：-asz,表明資源的準確容量的信息。

消息實例：

網(wǎng)關(guān)向傳感器發(fā)送資源發(fā)現(xiàn)的請求：

req:get/.well-known/core---發(fā)送請求到默認的uri，即根目錄獲取資源列表

傳感器向網(wǎng)關(guān)發(fā)送資源的響應(yīng)：

res:200ok--響應(yīng)標識獲取成功，并攜帶了2組資源指示信息

</sensors/temp>；ct＝41；n＝"temperaturec",--溫度資源，內(nèi)容類型41，名稱為temperaturec

</sensors/light>；ct＝41；n＝"lightlux"--燈光資源，內(nèi)容類型41，名稱為lightlux

</sensors/firmware>；ct＝52；n＝"firmware"；asz＝65000；snapshot＝0--固件資源，內(nèi)容類型52，名稱為firmware，非動態(tài)資源，精確容量為65000字節(jié)；

</sensors/log>；ct＝52；n＝"log"；asz＝88000；snapshot＝1--固件資源，內(nèi)容類型52，名稱為log，動態(tài)資源，當(dāng)前數(shù)據(jù)為快照snapshot，其精確容量為88000字節(jié)；

此響應(yīng)消息是封裝在coap消息的消息體中的，接收方(即網(wǎng)關(guān))根據(jù)link-format標準中的規(guī)定進行解析。

(2)增加狀態(tài)碼

在收到網(wǎng)關(guān)的數(shù)據(jù)資源獲取請求時，如果資源太大，一個包傳送不下，傳感器用狀態(tài)碼來通知網(wǎng)關(guān)，用于表明，資源太大，需要用blockoption來請求。

比如，可以規(guī)定狀態(tài)碼413，用于表明當(dāng)前數(shù)據(jù)資源容量過大，指示網(wǎng)關(guān)在請求中用block選項。可以根據(jù)需要規(guī)定其他的狀態(tài)碼，以用于表示其他含義，用于其它目的。

消息實例：

網(wǎng)關(guān)向傳感器發(fā)送資源獲取的請求：

get/sensordata

傳感器向網(wǎng)關(guān)發(fā)送帶狀態(tài)碼的響應(yīng)：

ack413(狀態(tài)碼，表明數(shù)據(jù)資源容量太大)

(3)在coap的頭字段(header)中增加一個表明容量(size)的選項(option)

網(wǎng)關(guān)在請求中，可以用容量選項(sizeoption)來指示傳感器，讓傳感器返回數(shù)據(jù)資源的容量；傳感器在響應(yīng)中，用sizeoption來指明數(shù)據(jù)資源的容量。

或者是，即使網(wǎng)關(guān)沒有sizeoption的指示，傳感器也在響應(yīng)中用sizeoption指明資源容量，尤其是資源比較大的情況下，傳感器應(yīng)該指示。

如果資源較小，傳感器直接在消息體(body)中返回資源數(shù)據(jù)，則網(wǎng)關(guān)應(yīng)該以資源數(shù)據(jù)的實際容量為準，sizeoption中表明的資源容量可以用于核對。

如果資源較大，傳感器不返回資源數(shù)據(jù)，只用sizeoption返回數(shù)據(jù)的容量，同時用狀態(tài)碼指示給網(wǎng)關(guān)，讓網(wǎng)關(guān)發(fā)起新的請求，用blockoption來請求。

sizeoption的代碼可以為16，數(shù)據(jù)類型為整型，數(shù)據(jù)長度為1～4個字節(jié)，數(shù)據(jù)單位為字節(jié)。sizeoption主要用于<get>方法的響應(yīng)中，<put>/<post>方法的請求中，用于表示資源的容量；如果是在<get>方法的請求中，其值沒有實際的意義，推薦置為0。

消息實例：

網(wǎng)關(guān)向傳感器發(fā)送資源獲取的請求：

get/sensordata

傳感器向網(wǎng)關(guān)發(fā)送帶狀態(tài)碼的響應(yīng)：

ack+413+size51200(50k字節(jié))

以下結(jié)合圖3說明如圖1所示實施例的具體實現(xiàn)過程。圖3表示的是網(wǎng)關(guān)向傳感器發(fā)送數(shù)據(jù)的說明性示例，僅為說明本發(fā)明的構(gòu)思，而不作為對本發(fā)明的限制。

當(dāng)網(wǎng)關(guān)使用<get>方法獲取第一個分片(block)數(shù)據(jù)時，num字段被設(shè)置為0，并攜帶推薦的分片容量(即szx)，傳感器可以選擇同意推薦的分片容量，或是選擇一個小于等于推薦的分片容量的分片容量，并在響應(yīng)中返回，同時，在響應(yīng)中返回第一個分片的分片數(shù)據(jù)。因此，在num字段為0時，<get>請求有雙重語義，一是獲取第一個分片數(shù)據(jù)，二是進行分片容量的協(xié)商。這樣帶來協(xié)議在處理上的二義性，而且無法攜帶數(shù)據(jù)容量等信息。

本發(fā)明實施例對此進行了改進，在本發(fā)明的一種實施例中，網(wǎng)關(guān)在<get>方法的請求中使用blockoption時，如果num字段被設(shè)置為0，表示雙方只進行分片容量的協(xié)商，以及分片總數(shù)的協(xié)商。即傳感器在響應(yīng)中，使用num字段返回分片總數(shù)，使用szx字段返回傳感器確定的分片容量。m字段可以去掉，節(jié)省一個bit，用于num字段。因為請求方，例如網(wǎng)關(guān)知道分片總數(shù)，所以從分片的num字段就可以知道該分片是否是最后一個分片，因此就不需要再使用m字段。在這種情況下，如果請求獲取第一個分片的分片數(shù)據(jù)，則將num設(shè)置為1，依次類推。

需要說明的是，如果網(wǎng)關(guān)發(fā)送第一個請求時，不知道數(shù)據(jù)資源的容量，所以blockoption可以使用一個字節(jié)，如果傳感器的數(shù)據(jù)資源較大，分片數(shù)目較大，則傳感器可以在響應(yīng)中使用二個字節(jié)或者三個字節(jié)來返回分片總數(shù)。

當(dāng)blockoption為2個字節(jié)時，其設(shè)計成szx字段占用第二個字節(jié)的最后三位，表示分片容量；num字段占用第一個字節(jié)加上第二個字節(jié)的前5位，表示當(dāng)前分片序號；如果是在num為0的請求對應(yīng)的響應(yīng)消息中，則表示分片總數(shù)。本領(lǐng)域技術(shù)人員理解，可以用消息標識(messageid)來關(guān)聯(lián)請求與響應(yīng)，即請求和響應(yīng)中都攜帶唯一的事務(wù)標識，這樣傳感器就能理解此響應(yīng)消息是用于返回分片總數(shù)。

以下舉例說明分片容量協(xié)商過程，消息實例為：

網(wǎng)關(guān)向傳感器發(fā)送資源獲取的請求：

get00000101(num為0，szx為101，即5，表示分片容量為2的9次方，即512)

傳感器向網(wǎng)關(guān)發(fā)送的響應(yīng)：

ack10000100(num為:10000，即總分片數(shù)為32，szx為100，即4，表示分片容量為2的8次方，即256)

此設(shè)計省掉了一個比特位(bit)，即把m位給省掉了，技術(shù)優(yōu)勢是節(jié)省了數(shù)據(jù)流量并且對現(xiàn)有設(shè)計的改動不大。在這種實施方式中，分片容量(szx)字段每次仍然要發(fā)送。

在現(xiàn)有技術(shù)中，分片容量(即szx字段)每次都要發(fā)送，不管是在請求消息中還是響應(yīng)消息中，除了第一個分片和最后一個分片中使用的分片容量可能不一樣之外，其他的分片容量全部都是一樣的。重復(fù)互相傳輸相同的num字段浪費了傳輸資源。

在本發(fā)明實施例中，網(wǎng)關(guān)在<get>方法的請求中使用blockoption時，如果num被設(shè)置為0，表示雙方只進行分片容量的協(xié)商，以及分片總數(shù)的協(xié)商。即傳感器在響應(yīng)中，使用num字段返回總的分片數(shù)，使用szx字段返回傳感器確定的分片容量。并且網(wǎng)關(guān)和傳感器雙方存儲所確定的分片容量，用于之后的分片數(shù)據(jù)傳輸消息。除了最后一個分片數(shù)據(jù)之外。網(wǎng)關(guān)在后續(xù)<get>方法的請求中，只發(fā)送所請求的當(dāng)前分片序號，而不發(fā)送已經(jīng)確定并保持不變的分片容量，而且傳感器在響應(yīng)消息中，也只發(fā)送當(dāng)前的分片序號和與該分片序號對應(yīng)的分片數(shù)據(jù)，不再發(fā)送分片容量。在這種情況下，num為1時，表示請求第一個分片的分片數(shù)據(jù)，依次類推。

以采用<get>命令從傳感器獲取數(shù)據(jù)資源為例，說明上述實施例，

如圖3所示，新的blockoption的設(shè)計如下：

其中結(jié)構(gòu)(1)用于num為0的情況：

在<get>請求中，num為0，szx是第二個字節(jié)，表示分片容量，totalnumber表示分片總數(shù)，在請求時不使用，不需要攜帶；在<get>響應(yīng)中，num為0，szx表示傳感器確定的分片容量，totalnumber表示分片總數(shù)。

在現(xiàn)有技術(shù)中，分片容量的間隔比較大，比如2048、1024、512，不夠靈活。而實際上，512對于一個block來說，比較小，最好是剛好能夠放到一個udp包里，即1472個字節(jié)。本發(fā)明對此進行了改進，在一種實施例中，對于szx，可以采取新的公式，比如：(szx+1)*8,則其范圍可以為：8～2048，但是遞減間隔為8。

圖3中的結(jié)構(gòu)(2)和結(jié)構(gòu)(3)用于<get>請求中num不為0的情況，即獲取分片數(shù)據(jù)時的情況：

當(dāng)num小于256時，用一個字節(jié)來表示分片序號，即結(jié)構(gòu)(2)；當(dāng)num大于2的8次方(即256)，小于2的16次方(即65536)時，使用兩個字節(jié)來表示分片序號，即結(jié)構(gòu)(3)。

由于結(jié)構(gòu)(2)中的num必須大于0，結(jié)構(gòu)(3)中的num字段的前一個字節(jié)也大于0，因此可以與結(jié)構(gòu)(1)區(qū)分開，對于<get>響應(yīng)，num字段的值與請求中一樣，也可以區(qū)分開。

以下舉例說明，消息實例為：

網(wǎng)關(guān)向傳感器發(fā)送資源獲取的請求：

get0000000000000101(num為0，szx為101，即5，表示分片容量為2的9次方，即512)

傳感器向網(wǎng)關(guān)發(fā)送的響應(yīng)：

ack00000000000001000000000000010000(num為0，totalnumber為10000，即分片總數(shù)為32，szx為100，即4，表示分片容量為2的8次方，即256)。

通過對blockoption重新設(shè)計，可以在每個請求或響應(yīng)中至少減少發(fā)送4個比特位，在分片較多的情況下，可以極大地提高傳輸效率，節(jié)省傳輸資源，同時也提高了網(wǎng)關(guān)和傳感器雙方的處理效率。

圖4示出了本發(fā)明的一種替代實施例。在圖4所示實施例中，es410至es420與圖2所示實施例的es210至es240相同，不再重復(fù)描述。

在圖4所示實施例中，在es450，網(wǎng)關(guān)向傳感器發(fā)送<get>請求，使用分片選項進行分片容量協(xié)商，指示網(wǎng)關(guān)推薦的分片容量。在es460中，傳感器選擇并確定合適的分片容量，用于將資源進行分片，并將所有分片數(shù)據(jù)主動推送給網(wǎng)關(guān)，而不需要網(wǎng)關(guān)再發(fā)<get>請求。

在圖4實施例獲取數(shù)據(jù)資源過程中，分片選項的設(shè)計如圖5所示，其中：

結(jié)構(gòu)(1)用于網(wǎng)關(guān)向傳感器發(fā)送<get>請求，szx字段表示網(wǎng)關(guān)推薦的分片容量，傳感器最終選擇并確定的分片容量小于等于網(wǎng)關(guān)推薦的分片容量，num為0表示網(wǎng)關(guān)請求完整資源，num不為0表示網(wǎng)關(guān)請求具體第num個分片數(shù)據(jù)，num不為0時傳感器只能使用szx字段所指示的分片容量。

結(jié)構(gòu)(2)和結(jié)構(gòu)(3)用于傳感器向網(wǎng)關(guān)返回完整資源的分片響應(yīng)消息，如果針對某個具體分片數(shù)據(jù)請求的應(yīng)答，不需要攜帶分片選項，結(jié)構(gòu)(2)和(3)中的m字段表示是否為最后一個分片，如果是m字段為0則表示最后一個分片，為1表示不是最后一個分片，num字段表示傳感器所返回的是第幾個分片。

以下舉例說明。消息實例為：

網(wǎng)關(guān)向傳感器發(fā)送數(shù)據(jù)資源獲取的請求：

conget0000000000000101(num為0，szx為101，即5，表示分片容量為2的9次方，即512)

傳感器向網(wǎng)關(guān)發(fā)送的響應(yīng)：

ack20000000011(num為1，m為1，表示發(fā)送的第一個分片，并且不是最后一個分片，分片容量為szx字段指定的容量)；

傳感器繼續(xù)向網(wǎng)關(guān)發(fā)送coap響應(yīng)：

con20000000101(num為2，m為1，表示發(fā)送的第二個分片，并且不是最后一個分片，分片容量為szx字段指定的容量)；

網(wǎng)關(guān)返回對con的ack響應(yīng)；

傳感器向網(wǎng)關(guān)發(fā)送最后一個分片：

con20000000110(num為3，m為0，表示發(fā)送的第三個分片，并且是最后一個分片，具體分片容量由實際讀出數(shù)據(jù)算出)。

根據(jù)圖4所示的實施例，在網(wǎng)關(guān)從傳感器獲取完整的數(shù)據(jù)資源時，僅需完成分片容量的協(xié)商，而不用發(fā)送大量的分片數(shù)據(jù)獲取請求，大大節(jié)省了數(shù)據(jù)傳輸流量。

圖6示出了本發(fā)明的另一種替代實施例。在圖6所示實施例中，es610至es640與圖2所示實施例的es210至es240相同，因此不再重復(fù)描述。

圖6與圖2所示實施例不同之處在于，在es650，網(wǎng)關(guān)向傳感器發(fā)送<get>請求，請求獲取資源，使用分片選項，指示網(wǎng)關(guān)推薦的分片容量，此時num字段填充的值為0，表示請求獲取最后一個分片；在es660，傳感器響應(yīng)網(wǎng)關(guān)請求，返回確定的分片容量以及最后一個分片的序號及與之對應(yīng)的分片數(shù)據(jù)。由于最后一個分片序號對應(yīng)分片總數(shù)，所以在es670，網(wǎng)關(guān)就可以依次或者并發(fā)獲取其他分片數(shù)據(jù)的請求。在es680，傳感器根據(jù)確定的分片容量，返回該分片的序號及對應(yīng)的分片數(shù)據(jù)。es670和es680可以多次進行交互，直至分片數(shù)據(jù)傳輸完畢。

圖6實施例中采用的分片選項如圖7所示，例如采用兩個字節(jié)的分片選項，僅包括num字段和szx字段。

以下結(jié)合圖6和圖7舉例說明，消息實例為：

網(wǎng)關(guān)向傳感器發(fā)送資源獲取的請求：

conget0000000000000101(num為0，表示要求獲取最后一個分片，szx為101，即5，表示推薦的分片容量為2的9次方，即512)。

傳感器向網(wǎng)關(guān)發(fā)送的響應(yīng)：

ack0000000001000101(num為1000即為8，表示返回的是第8個分片，szx為101即5，表示確定的分片容量為2的9次方，即512)；

根據(jù)第一次的返回信息，網(wǎng)關(guān)已經(jīng)知道了一共有8個分片，并且得到了第8個分片的數(shù)據(jù)，網(wǎng)關(guān)繼續(xù)向傳感器發(fā)送coap請求，可以依次獲取也可以并發(fā)獲取剩下的分片數(shù)據(jù)。以下消息實例為請求獲取第一個分片的分片數(shù)據(jù)：

conget0000000000001101(num為1，表示要求獲取第一個分片，szx為101，即5，表示分片容量為2的9次方，即512)；

傳感器返回對con的ack響應(yīng)，即第一個分片的數(shù)據(jù)；

網(wǎng)關(guān)可以依次或并發(fā)請求所有剩余分片，直到獲取完所有的數(shù)據(jù)。

根據(jù)圖6所示的實施例，可以在分片容量協(xié)商的同時，獲取最后一個分片的分片數(shù)據(jù)，在后續(xù)分片數(shù)據(jù)獲取過程中，所使用的分片容量均相同，因此可以結(jié)合前述優(yōu)選實施例的描述，網(wǎng)關(guān)可以在發(fā)送獲取分片數(shù)據(jù)的請求時，不再發(fā)送szx字段，而僅發(fā)送num字段，由此可以節(jié)省數(shù)據(jù)流量，提高傳輸效率。

圖8示出了使用分片選項向傳感器發(fā)送數(shù)據(jù)，例如使用資源創(chuàng)建(post)或更新(put)請求時的實施例。以下結(jié)合圖8進行具體描述。

圖8所示詳細的流程說明如下：

es810：網(wǎng)關(guān)向傳感器發(fā)送資源創(chuàng)建(post)或更新(put)請求消息，利用size選項發(fā)送資源的容量信息，利用分片選項指示推薦的分片容量及分片總數(shù)，此處所述的分片總數(shù)是基于推薦的分片容量和待發(fā)送的數(shù)據(jù)資源的容量計算出的，請求消息體中不攜帶具體的資源數(shù)據(jù)。

es820：傳感器如果愿意接收此數(shù)據(jù)，則返回狀態(tài)碼例如為100(即指示客戶端繼續(xù)發(fā)送)，同時向網(wǎng)關(guān)返回確定的分片容量，所述確定的分片容量只能小于或等于網(wǎng)關(guān)推薦的分片容量；如果傳感器不愿意接收此數(shù)據(jù)，則返回錯誤碼指示客戶端不要繼續(xù)發(fā)送數(shù)據(jù)。比如，傳感器的存儲容量不足以存儲所指示的資源容量的數(shù)據(jù)，則返回413“requestentitytoolarge”的返回碼。

es830：網(wǎng)關(guān)根據(jù)傳感器返回的確定的分片容量，判斷是否與推薦的分片容量相同，如果相同，則跳轉(zhuǎn)到es360；如果不相同，則根據(jù)傳感器返回的確定的分片容量信息，并根據(jù)數(shù)據(jù)資源容量，重新計算分片總數(shù)。

es840：網(wǎng)關(guān)重新向傳感器發(fā)送確定的分片容量和重新計算的分片總數(shù)。

es850：傳感器返回確定的分片容量。

es860：網(wǎng)關(guān)從根據(jù)分片序號從1一直到分片總數(shù)，依次向傳感器發(fā)送與分片序號對應(yīng)的數(shù)據(jù)資源的分片數(shù)據(jù)，直到完全傳輸完畢。

es870：傳感器返回確定接收的消息，其中包含接收到的分片序號。

根據(jù)本發(fā)明的一種優(yōu)選實施例，es860中可以進行并行處理，即網(wǎng)關(guān)可以同時向傳感器發(fā)送多個分片數(shù)據(jù)，而不需要等待傳感器返回對前一個分片消息的響應(yīng)消息?？蛇x地，根據(jù)本發(fā)明的一種優(yōu)選實施例，網(wǎng)關(guān)和傳感器在消息交互中，增加認證信息。認證消息的配置和交互方式可以采用參照圖2所述的相同方式。

為了提高傳輸效率，節(jié)省數(shù)據(jù)流量，根據(jù)本發(fā)明另一種優(yōu)選實施例，如前面針對<get>方法所述地那樣，在使用<put>/<post>方法的請求中，當(dāng)num為0是，不再是發(fā)送第一個分片數(shù)據(jù)，而是告知傳感器推薦的分片的容量和分片總數(shù)。傳感器可以返回響應(yīng)告知網(wǎng)關(guān)是否繼續(xù)發(fā)送數(shù)據(jù)。傳感器在響應(yīng)中，使用num字段返回總的分片數(shù)，使用szx字段返回傳感器確定的分片容量。并且網(wǎng)關(guān)和傳感器雙方存儲所確定的分片容量，用于之后的分片數(shù)據(jù)傳輸消息。除了最后一個分片數(shù)據(jù)之外。網(wǎng)關(guān)在后續(xù)<put>/<post>方法的請求中，只發(fā)送所請求的當(dāng)前分片序號，而不發(fā)送已經(jīng)確定并保持不變的分片容量，而且傳感器在響應(yīng)消息中，也只發(fā)送當(dāng)前的分片序號和與該分片序號對應(yīng)的分片數(shù)據(jù)，不再發(fā)送分片容量。在這種情況下，num為1時，表示請求第一個分片的分片數(shù)據(jù)，依次類推。

在此情況下，分片選項的設(shè)計以及使用方式均類似于圖3所示，以下參照圖3來說明。在<put>/<post>請求中，num字段為0，szx字段是第二個字節(jié)，表示推薦的分片容量，totalnumber表示待發(fā)送的分片總數(shù)數(shù)；在<put>/<post>響應(yīng)中，num字段為0，szx字段表示傳感器確定的分片容量，totalnumber沒用，不需要攜帶；如果網(wǎng)關(guān)接收到的szx字段與發(fā)送的不一致，需要用新的szx再次發(fā)送<put>/<post>請求，并攜帶重新計算的分片總數(shù)，傳感器再發(fā)回響應(yīng)。以后<put>/<post>請求和響應(yīng)中，不再攜帶szx字段。

通過對分片選項重新設(shè)計，可以在每個請求或響應(yīng)中至少減少發(fā)送4個比特位，在分片較多的情況下，可以極大地提高傳輸效率，節(jié)省傳輸資源，同時也提高了網(wǎng)關(guān)和傳感器雙方的處理效率。

另外，現(xiàn)有技術(shù)在每次分片傳輸?shù)恼埱笾?，都需要攜帶所請求資源的統(tǒng)一資源標識(uri，unifiedresourceidentifier)，通常uri都要占十幾到幾十個字節(jié)，重復(fù)的傳輸會浪費傳輸資源，本發(fā)明設(shè)計使用token(令牌)來關(guān)聯(lián)分片傳輸?shù)亩鄠€請求，只在第一個分片消息中傳送uri，在后續(xù)的分片傳輸請求中，只需要攜帶token即可，由于token通常是1～8個字節(jié)，因此可以節(jié)省一定的流量。

圖9是本發(fā)明一種通過分片傳輸數(shù)據(jù)資源的客戶端設(shè)備的實施例。圖9所示客戶端設(shè)備900包括：獲取單元910，用于獲取數(shù)據(jù)資源容量信息；發(fā)送單元920，用于發(fā)送攜帶分片選項的請求消息，其中所述分片選項包括推薦的分片容量，接收單元930，接收攜帶分片選項的響應(yīng)消息，其中所述分片選項包括確定的分片容量；和傳輸單元940，用于根據(jù)所述確定的分片容量以及所述數(shù)據(jù)資源容量信息，分片傳輸所述數(shù)據(jù)資源。

根據(jù)本發(fā)明的一種優(yōu)選實施例，所述客戶端設(shè)備可以進一步包括存儲單元950，用于保存所述確定的分片容量。以便在數(shù)據(jù)資源傳輸過程中，不需要每次均發(fā)送szx字段。

根據(jù)本發(fā)明的另一種優(yōu)選實施例，所述客戶端設(shè)備可以進一步包括認證單元960，用于發(fā)送和接收認證信息。

圖10是本發(fā)明一種通過分片傳輸數(shù)據(jù)資源的服務(wù)器設(shè)備的實施例。圖10所示服務(wù)器設(shè)備1000包括：接收單元1010，用于接收攜帶分片選項的請求消息，其中所述分片選項包括推薦的分片容量；發(fā)送單元1020，用于發(fā)送攜帶分片選項的響應(yīng)消息，其中所述分片選項包括確定的分片容量；和傳輸單元1030，用于根據(jù)所述確定的分片容量，分片傳輸所述數(shù)據(jù)資源。

根據(jù)本發(fā)明一種實施例，發(fā)送單元1020還用于發(fā)送攜帶數(shù)據(jù)資源容量信息的消息，以便于傳輸單元1030根據(jù)所述確定的分片容量和所述數(shù)據(jù)資源容量信息，分片傳輸所述數(shù)據(jù)資源。

根據(jù)本發(fā)明一種實施例，在接收到一次請求時，傳輸單元1030可以主動地分片傳輸數(shù)據(jù)，而不需要客戶端設(shè)備針對每個分片數(shù)據(jù)進行請求。

根據(jù)本發(fā)明一種優(yōu)選實施例，所述服務(wù)器設(shè)備可以進一步包括存儲單元1040，用于保存所述確定的分片容量。以便在數(shù)據(jù)資源傳輸過程中，不需要每次均發(fā)送szx字段。

根據(jù)本發(fā)明的另一種優(yōu)選實施例，所述服務(wù)器設(shè)備可以進一步包括認證單元1050，用于發(fā)送和接收認證信息。

根據(jù)本發(fā)明實施例，網(wǎng)關(guān)可以獲知目標資源的容量信息，用于決策是否用分片的方式來獲取資源，這樣避免了出錯的可能性，也可以實現(xiàn)并發(fā)地請求分片，提高數(shù)據(jù)請求的效率，而且得知資源的容量也便于分配存儲空間，計算分片的數(shù)量。

通過對分片選項重新設(shè)計，可以在每個請求或響應(yīng)中至少少發(fā)送4個比特位，在分片較多的情況下，可以極大地提高傳輸效率，節(jié)省傳輸資源，同時也提高了雙方的處理效率。

在現(xiàn)有技術(shù)中，在收到來自于客戶端的請求后，服務(wù)器可以立即發(fā)回響應(yīng)，也可以先發(fā)回一個ack(acknowledgement)響應(yīng)消息，表明接收到了請求消息，正在處理中，后續(xù)等處理完后，再發(fā)送響應(yīng)消息，即推遲的響應(yīng)。另外，客戶端可以訂閱一個資源的改變，服務(wù)器在接受客戶端對某個資源的訂閱后，一旦資源信息發(fā)生變化，就向客戶端發(fā)回通知消息。

現(xiàn)有技術(shù)不能滿足如下的需求：

1、客戶端在請求中指示服務(wù)器，自己需要哪種方式的響應(yīng)；

2、客戶端要求服務(wù)器在某個規(guī)定的時間內(nèi)發(fā)回響應(yīng)；

3、在通知消息的傳送過程中，由于網(wǎng)絡(luò)傳輸能力不穩(wěn)定，可能服務(wù)器先發(fā)出的通知消息，比服務(wù)器后發(fā)出的消息，到達客戶端的時間要晚。這樣，客戶端后收到的資源信息實際上是陳舊的信息，客戶端需要有一種機制能夠探測多個通知消息的順序。

圖11是本發(fā)明一種實施例的流程圖。在圖11所示實施例中，在s1110，客戶端向服務(wù)器發(fā)送請求消息，該請求消息攜帶響應(yīng)方式選項，所述響應(yīng)方式選項可以是推遲響應(yīng)(deferredresponse)選項或者是令牌(token)選項，用來指示服務(wù)器，客戶端是否接收推遲的響應(yīng)。例如，所述響應(yīng)方式選項表示：一次性的立即響應(yīng)、推遲的一次性的響應(yīng)、推遲的多個響應(yīng)和取消推遲的多個響應(yīng)。如果響應(yīng)方式選項不攜帶，默認為一次性響應(yīng)，服務(wù)器可以確定是采用一次性的立即響應(yīng)或是推遲的一次性響應(yīng)。然后，在s1120，客戶端可以接收服務(wù)器發(fā)送的根據(jù)響應(yīng)方式選項生成的響應(yīng)消息。

在現(xiàn)有技術(shù)中，在收到來自于客戶端的請求后，服務(wù)器可以立即發(fā)回響應(yīng)，也可以先發(fā)回一個ack，表明接收到了請求消息，正在處理中，后續(xù)等處理完后，再發(fā)送響應(yīng)消息，即推遲的響應(yīng)。另外，客戶端可以訂閱一個資源的改變，服務(wù)器在接受客戶端對某個資源的訂閱后，一旦資源信息發(fā)生變化，就向客戶端發(fā)回通知消息。

在本發(fā)明的一種實施例中，例如可以采用一個字節(jié)的延遲(deferred)選項來指示響應(yīng)方式，其中，可以使用前兩個比特位(bit)來表示，用c來表示：

c＝00:表示一次性的立即響應(yīng)；

c＝01:表示推遲的一次性的響應(yīng)；

c＝10：表示推遲的多個響應(yīng)，即訂閱；

c＝11：表示取消推遲的多個響應(yīng)，即取消訂閱。

對于客戶端發(fā)起的關(guān)于某個資源的訂閱，可以由客戶端取消訂閱，也可以服務(wù)器取消訂閱，比如服務(wù)器發(fā)回給客戶端一個需要確認的響應(yīng)消息，客戶端在預(yù)定的時間內(nèi)未能確認，則服務(wù)器可以認為客戶端失去連接，從而取消訂閱。

由于一個字節(jié)是8個比特位，多余的后6個比特位(假設(shè)其值為t)可以用于表示推遲的一次性的響應(yīng)的推遲時間或者推遲的多個響應(yīng)的截止時間，即超過此時間后，自動取消訂閱。當(dāng)c為01時，t表示推遲的一次性響應(yīng)的推遲時間；當(dāng)c為10時，t表示推遲的多個響應(yīng)的截止時間；當(dāng)t為00或11時，t沒有意義，置為0。

對于這6個比特位，可以表示0～63之間的數(shù)值，假設(shè)為t，可以用2的t次方，來表明這個時間長度，以秒為單位，即可以表示1～2^63秒。比如：

0:2^0＝1秒；

1:2^1＝2秒；

2:2^2＝4秒；

3:2^3＝8秒

4:2^4＝16秒；

…

63:2^63秒。

在現(xiàn)有技術(shù)中，max_age字段用于表明某個響應(yīng)可以被緩存的最大時間，即表明響應(yīng)的新鮮度。本發(fā)明擴展這一字段的含義，可以在請求中用max_age字段表示多個響應(yīng)之間的時間間隔的限制，比如多個通知消息不得高于此時間間隔，或者是不得低于此時間間隔。

對于多個響應(yīng)的順序，可以用消息標識(messageid)來區(qū)分。比如，規(guī)定消息標識必須根據(jù)通響應(yīng)的順序來遞增地生成，接收方根據(jù)消息標識的大小來判斷響應(yīng)的先后順序。

根據(jù)本發(fā)明的另一種實施例，可以使用token(令牌)選項來指示響應(yīng)方式，如果token值為0，來表示立即的響應(yīng)，如果token值不為0，則表示可以接受推遲的響應(yīng)。

根據(jù)本發(fā)明的另一種實施例，可以替代地或另外增加時間戳(timestamp)選項，與延遲選項單獨或者相結(jié)合地來指示響應(yīng)方式。具體來說，客戶端可以在請求中攜帶時間戳選項，所述時間戳選項包括一個截止時間的值，要求服務(wù)器在指定的時間內(nèi)返回響應(yīng)；服務(wù)器在響應(yīng)消息中，攜帶時間戳選項，表明響應(yīng)消息生成的時間，這樣，客戶端可以基于時間戳選項來判斷響應(yīng)消息的順序。

在本發(fā)明一種實施例中，所述時間戳選項的設(shè)計方案可以用1～6個字節(jié)來表示，如果表示的時間短，則用一個字節(jié)，如果時間長，則用3個字節(jié)或6個字節(jié)。具體表示方法例如以下兩種：

(1)用年、月、日、時、分、秒來表示，第一個字節(jié)表示年、第二個字節(jié)表示月，第三個字節(jié)表示日，第四個字節(jié)表示小時，第五個字節(jié)表示分鐘，第六個字節(jié)表示秒，對于年份，例如可以以2000年為基礎(chǔ)，其值表明2000年之后的第幾年，比如為0時，表明是2000年，為1時，表明是2001年，最多可以表示2063年。

(2)三個字節(jié)全部用秒來表示，最大可表示2^24-1秒，大約是136年。

由此，客戶端可以知道返回的響應(yīng)消息的順序，避免數(shù)據(jù)傳輸延遲導(dǎo)致的錯誤。

與圖11所示的實施例對應(yīng)，圖12是從服務(wù)器側(cè)來看，本發(fā)明實施例的方法的流程圖。本發(fā)明實施例的方法包括：

s1210：接收客戶端發(fā)送的攜帶響應(yīng)方式選項的請求消息；

s1220：向客戶端發(fā)送根據(jù)所述響應(yīng)方式選項生成的響應(yīng)消息。

下面結(jié)合具體的實施例進一步闡述本發(fā)明實施例的方案。

實施例1：

在步驟s1110中發(fā)送的所述請求消息中，所述響應(yīng)方式選項為推遲的一次性的響應(yīng)或者一次性的立即響應(yīng)，并且所述請求消息還攜帶消息類型指示信息和延遲時間選項。這里的消息類型指示信息指示所述請求消息為多播請求，并且延遲時間選項用于指示多個服務(wù)器在所述延遲時間選項所指示的時間內(nèi)，任意選擇一個時間向客戶端發(fā)送響應(yīng)消息，以避免多個服務(wù)器同時發(fā)回響應(yīng)給客戶端，造成網(wǎng)絡(luò)擁塞，而且客戶端也來不及處理。例如，在所述延遲時間選項所指示的時間內(nèi)，多個服務(wù)器各自經(jīng)過隨機延時后，再向客戶端發(fā)送響應(yīng)消息。

例如，某個大樓管理員利用控制臺(多播網(wǎng)關(guān))發(fā)送向整個大樓的多個電燈控制器(服務(wù)器)發(fā)送開燈的指令(多播請求)，要求各個電燈控制器在5秒鐘內(nèi)發(fā)回響應(yīng)以表明是否已經(jīng)開燈，則各個電燈控制器在5秒鐘內(nèi)分別經(jīng)過隨機延時后，向控制臺發(fā)回響應(yīng)，表明是否已經(jīng)開燈。

為了通知服務(wù)器所述請求消息為多播請求，這里所述的消息類型指示信息例如可以是預(yù)設(shè)的用于發(fā)送多播請求的套接字端口；或者預(yù)設(shè)的用于發(fā)送所述多播請求的網(wǎng)絡(luò)協(xié)議ip地址；或者預(yù)設(shè)的用于發(fā)送多播請求的端口號；或者所述請求消息中的消息類型指示選項。例如，

1)服務(wù)器打開一個特定的套接字(socket)端口，并設(shè)置為網(wǎng)絡(luò)協(xié)議(internetprotocol，簡稱ip)多播接收，則客戶端通過該特定的socket端口向服務(wù)器發(fā)送所述請求消息，以表示所述請求消息為多播請求；

2)客戶端在所述請求消息中攜帶預(yù)設(shè)的ip地址，例如ff00::/8的ipv6的前綴，服務(wù)器接收到請求消息后，檢查接收包的ip地址，如果該ip地址為預(yù)設(shè)的ip地址，則表示該請求消息是多播請求，否則是單播請求；

3)客戶端通過預(yù)設(shè)的用于發(fā)送多播請求的端口號來發(fā)送所述請求消息，例如：coap://用于單播請求，coapm://用于多播請求，則服務(wù)器可以根據(jù)接收的請求消息的端口號來確定所述請求消息是單播請求還是多播請求。

4)客戶端在請求消息中用消息類型指示選項字段來表明此請求是單播請求還是多播請求，服務(wù)器根據(jù)此字段來判斷。

根據(jù)本發(fā)明實施例，上述過程也適用于所述請求消息為單播請求的場景。

服務(wù)器的行為在單播和多播場景下有所不同，主要區(qū)別是，對于單播請求，超時后，服務(wù)器放棄發(fā)回響應(yīng)給客戶端；對于多播請求，超時后，服務(wù)器還是會發(fā)回響應(yīng)給客戶端，雖然響應(yīng)超時了，但由于不是所有的服務(wù)器都超時，所以不會造成擁塞問題。

根據(jù)本發(fā)明實施例，所述請求消息還包括截止時間選項，以指示服務(wù)器在該截止時間選項所指示的時間內(nèi)返回響應(yīng)消息。由此，客戶端可以在所述截止時間選項指示的時間超時之前，接收服務(wù)器發(fā)送的響應(yīng)消息。

實施例2：

在步驟s1110中發(fā)送的請求消息中，響應(yīng)方式選項為推遲的多個響應(yīng)，即表示客戶端訂閱(observe)服務(wù)器的數(shù)據(jù)。在這種情況下，服務(wù)器向客戶端發(fā)送通知響應(yīng)消息。根據(jù)本發(fā)明實施例，通知響應(yīng)消息攜帶最長存續(xù)時間(max-age)選項和留候時間(patience)選項，其中max-age選項用于表明資源的值的最長有效時間；所述patience選項用于指示服務(wù)器將在max－age過期后，在所述patience選項所指示的時間內(nèi)作出響應(yīng)。在資源的值沒有改變的情況下，服務(wù)器可以用此patience選項，來延遲響應(yīng)消息的發(fā)送。在這種情況下，客戶端可以用此來判斷，在max-age過期后，服務(wù)器將盡量在patience時間到期前，發(fā)送通知響應(yīng)給客戶端。因此，客戶端可以在max-age過期后，繼續(xù)保持與所述服務(wù)器的訂閱關(guān)系，保持時間為所述patience選項所指示的時間。這樣可以避免客戶端在max－age過期后，重新向服務(wù)器發(fā)送請求消息。

實施例3：

在步驟s1110中發(fā)送的所述請求消息中，所述響應(yīng)方式選項為推遲的多個響應(yīng)，表示客戶端訂閱(observe)服務(wù)器的數(shù)據(jù)。在這種情況下，客戶端向服務(wù)器發(fā)送的所述請求消息中包括保持時間(keepalive)選項?？蛻舳丝梢愿鶕?jù)情況設(shè)置keepalive選項的取值，比如在本例中可以設(shè)置為1000秒。服務(wù)器收到該請求消息后，向客戶端回復(fù)確認(acknowledgement，簡稱ack)消息，其中攜帶當(dāng)前訂閱資源的最新取值，同時獲取keepalive選項，并在此時開啟一個定時器，其值為keepalive設(shè)置的取值。

在keepalive選項所述指示的時間內(nèi)，如果客戶端訂閱的資源在服務(wù)器上發(fā)生變化，則服務(wù)器向客戶端發(fā)送第三通知響應(yīng)，即客戶端接收服務(wù)器發(fā)送的第三通知響應(yīng)，該所述第三通知響應(yīng)為不需要確認型消息。

當(dāng)按keep-alive指示的時間超時之后，服務(wù)器向客戶端發(fā)送第四通知響應(yīng)，即客戶端接收服務(wù)器發(fā)送的第四通知響應(yīng)，其中所述第四通知響應(yīng)為需要確認型消息。然后服務(wù)器等待客戶端返回ack消息。當(dāng)服務(wù)器收到來自客戶端的ack消息后，則說明客戶端運行正常。然后可以重復(fù)上面的過程，服務(wù)器重新開啟定時器，通過不需要確認型消息向客戶端發(fā)送響應(yīng)消息。

如果在一定時間內(nèi)服務(wù)器沒有收到客戶端的ack消息，則服務(wù)器將重新發(fā)送上述第四通知響應(yīng)。如果重發(fā)次數(shù)到達預(yù)設(shè)的次數(shù)閾值時，服務(wù)器還是沒有收到客戶端的返回的ack消息，則服務(wù)器停止重發(fā)，同時也停止同客戶端的訂閱關(guān)系。

圖13是實施例3的實現(xiàn)過程的消息交互圖。圖13中的各個消息如下：

es1310：客戶端向服務(wù)器發(fā)送訂閱請求，其中攜帶keepalive選項；

es1320:服務(wù)器向客戶端回復(fù)ack消息，其中攜帶當(dāng)前訂閱資源的最新取值，開啟定時器；

es1330：當(dāng)服務(wù)器上訂閱的資源發(fā)生變化時，該服務(wù)器向客戶端發(fā)送通知響應(yīng)，該通知響應(yīng)為不需要確認型消息；

es1340：當(dāng)定時器超時后，服務(wù)器采用需要確認型消息發(fā)送通知響應(yīng)，并等待客戶端返回的ack消息；

es1350：客戶端服務(wù)器返回一個ack消息；

es1360：服務(wù)器收到來自客戶端的ack消息，重新開啟定時器；

es1370：當(dāng)服務(wù)器上訂閱的資源發(fā)生變化時，該服務(wù)器向客戶端發(fā)送通知響應(yīng)，該通知響應(yīng)為不需要確認型消息；

es1380：當(dāng)定時器超時后，服務(wù)器采用需要確認型消息發(fā)送通知響應(yīng)，并等待客戶端返回的ack消息；

es1390：服務(wù)器在一定時間內(nèi)沒有收到客戶端的ack消息，服務(wù)器將重新發(fā)送上述通知響應(yīng)，當(dāng)重發(fā)次數(shù)到達最大，服務(wù)器還是沒有收到客戶端的ack消息，則服務(wù)器停止重發(fā)，同時也停止同客戶端的訂閱關(guān)系。

es1310至es1390的代碼例如為：

根據(jù)本發(fā)明實施例，keepalive選項可以定義為可選選項，即如果coap服務(wù)器不支持該選項，可以無視該選項，按沒有該選項處理收到的請求。

根據(jù)本發(fā)明實施例，該keepalive選項的取值是整數(shù)型的，大小可以是變長的。根據(jù)具體需要，其大小可以是4bit(比特)，或8個bit，或12bit，甚至更大，本發(fā)明實施例并不限制其具體的取值范圍。

實施例4：

在實際應(yīng)用中，服務(wù)器因為擁塞等原因而導(dǎo)致高負荷時，根據(jù)服務(wù)器設(shè)備的配置策略，為了防止后續(xù)信令處理等操作導(dǎo)致服務(wù)器設(shè)備徹底癱瘓，服務(wù)器設(shè)備在此時間點上開啟擁塞控制，即在接下來的一定時間內(nèi)，不再處理收到的任何新的請求消息。

考慮本發(fā)明實施例在這種場景中的應(yīng)用。例如，在步驟s1110中，客戶端向服務(wù)器發(fā)送請求消息，其中所述響應(yīng)方式選項為推遲的一次性的響應(yīng)或一次性的立即響應(yīng)，且所述請求消息還包括消息類型指示信息和截止時間選項，其中所述消息類型指示信息指示所述請求消息為單播請求，所述請求消息為需要確認型消息。本領(lǐng)域技術(shù)人員可以理解，如果服務(wù)器收到的是不需要確認型請求消息，則直接將消息忽略，不回復(fù)任何響應(yīng)。如果此時服務(wù)器發(fā)生擁塞并開啟了擁塞控制，則在步驟s1120中，服務(wù)器向所述客戶端發(fā)送特定ack消息，其中所述特定的確認消息攜帶響應(yīng)代碼和延遲接入時間選項，其中所述響應(yīng)代碼例如為5.03“serviceunavailable”(服務(wù)不可用)響應(yīng)代碼，用于表示服務(wù)器在所述截止時間選項所指示的時間內(nèi)無法返回針對所述請求消息的響應(yīng)?；蛘叻?wù)器可以先向所述客戶端發(fā)送ack消息，接著向所述客戶端發(fā)送響應(yīng)消息，其中所述響應(yīng)消息攜帶響應(yīng)代碼和延遲接入時間選項，其中所述響應(yīng)代碼表示所述服務(wù)器在所述截止時間選項所指示的時間內(nèi)無法返回針對所述請求消息的響應(yīng)。

延遲接入時間選項的值代表了延遲接入的具體時間，單位例如是秒，最大值例如為2ⁿ秒，超過該最大值的值例如被服務(wù)器按照默認值2^m秒來處理。如果此選項值為零時或者此選項沒有出現(xiàn)在響應(yīng)消息中時，則客戶端無需執(zhí)行額外操作，可在任意時間嘗試向服務(wù)器再次發(fā)出請求。根據(jù)本發(fā)明實施例，延遲接入時間選項為可選類型，即無法被coap客戶端識別時會直接被忽略。

圖14是實施例4的消息交互圖。如圖所示，

e1400：服務(wù)器開啟擁塞控制；

e1402：客戶端向所述服務(wù)器發(fā)送需要確認型請求消息；

e1404：服務(wù)器向客戶端發(fā)送ack消息，該ack消息包含延遲接入選項(新)、響應(yīng)代碼以及空的負載

e1404：客戶端立即清除緩存的等待向所述服務(wù)器發(fā)送的其他請求消息。

e1406：在延遲接入時間選項所指示的時間內(nèi)，向服務(wù)器發(fā)送請求消息；

e1408：服務(wù)器將該請求消息忽略；

e1410：等待延遲接入時間選項所指示的時間；

e1412：服務(wù)器負荷恢復(fù)正常；

e1414：客戶端向服務(wù)器重新發(fā)送所述請求消息；

e1416：服務(wù)器返回正常ack消息。

由于coap協(xié)議的版本不同，實際投入使用的coap客戶端可能沒有及時升級，以至于無法識別所述延遲接入選項。因此即使在e1404，帶有延遲接入時間選項的ack發(fā)送到了客戶端，由于客戶端版本較老無法識別延遲接入時間選項，該客戶端設(shè)備將會忽略該選項(也有可能是其他異常情況導(dǎo)致)，并且可能在接下來的任意時間，在e1406再次嘗試發(fā)送請求消息至已經(jīng)遭遇擁塞的服務(wù)器設(shè)備。服務(wù)器設(shè)備可以根據(jù)配置的策略，忽略該請求消息，或再次發(fā)送帶有新的延遲接入時間選項的響應(yīng)消息，該新的延遲接入時間選項的取值可以小于先前已經(jīng)發(fā)送的延遲接入時間選項的取值。

需要說明的是，本實施例中為了方便解釋，都使用了piggy-backed(附帶式)的響應(yīng)消息，即各選項夾帶在ack消息中直接傳輸。根據(jù)本發(fā)明實施例，也可以使用分離式的響應(yīng)，即確認消息和響應(yīng)消息分兩次發(fā)送，延遲接入選項總是屬于響應(yīng)消息的一部分。

實施例5：

與服務(wù)器側(cè)發(fā)生擁塞類似，客戶端也可能因為某種原因發(fā)生擁塞而導(dǎo)致高負荷。當(dāng)客戶端由于擁塞等原因而導(dǎo)致高負荷時，根據(jù)客戶端的配置策略，為了防止后續(xù)信令處理等操作導(dǎo)致客戶端徹底癱瘓，客戶端在此時間點上開啟擁塞控制，即在接下來的一定時間內(nèi)，不再處理收到的任何新的請求消息。

考慮本發(fā)明實施例在這種場景中的應(yīng)用。例如，在步驟s1110中，客戶端向服務(wù)器發(fā)送所述請求消息，其中所述響應(yīng)方式選項為推遲的多個響應(yīng)，即客戶端訂閱服務(wù)器上的資源信息。然后，在步驟s1120中，客戶端收到服務(wù)器發(fā)送的響應(yīng)消息，例如在所訂閱的資源在服務(wù)器上發(fā)生了變化的情況下，服務(wù)器向客戶端發(fā)送需要確認型響應(yīng)消息，其中攜帶最新的資源信息。如果此時客戶端開啟了擁塞控制，則會向服務(wù)器發(fā)送特定的ack消息，所述特定的確認消息攜帶響應(yīng)代碼和延遲接入時間選項，其中所述響應(yīng)代碼表示所述客戶端在所述延遲接入時間選項所指示的時間內(nèi)無法返回針對所述響應(yīng)消息的確認?；蛘呖蛻舳丝梢韵认蛩龇?wù)器發(fā)送ack消息，接著向所述客戶端發(fā)送特定的響應(yīng)消息，其中所述特定的響應(yīng)消息攜帶響應(yīng)代碼和延遲接入時間選項，其中所述響應(yīng)代碼表示所述客戶端在所述延遲接入時間選項所指示的時間內(nèi)無法返回針對所述需要確認型響應(yīng)消息的確認。在客戶端開啟擁塞控制的情況下，如果在步驟s1120中客戶端接收到的是不需要確認型響應(yīng)消息，則客戶端將該消息直接忽略，不回復(fù)任何確認消息。

如上所述，延遲接入時間選項的值代表了延遲接入的具體時間，單位例如是秒，最大值例如為2ⁿ秒，超過該最大值的值例如被客戶端按照默認值2^m秒來處理。如果此選項值為零時或者此選項沒有出現(xiàn)在響應(yīng)消息中時，則服務(wù)器無需執(zhí)行額外操作，可在任意時間嘗試向客戶端再次發(fā)出需要確認形響應(yīng)消息。根據(jù)本發(fā)明實施例，延遲接入時間選項為可選類型，即無法被coap服務(wù)器識別時會直接被忽略。

服務(wù)器收到上述特定的ack消息后，如果能夠識別消息中的延遲接入時間選項，則暫停所有的與所述客戶端之間的訂閱推送，開始等待，即等待所述客戶端恢復(fù)正常。

在延遲接入時間選項所指示的時間經(jīng)過之后，客戶端恢復(fù)正常，服務(wù)器的等待計時也已結(jié)束，因此服務(wù)器向客戶端設(shè)備重發(fā)需要確認的響應(yīng)消息，負載恢復(fù)正常的客戶端此時會回復(fù)一個正常的確認消息。

圖15是實施例5中的消息交互圖。如圖16所示，

es1500：客戶端向服務(wù)器發(fā)送訂閱請求；

es1502：服務(wù)器向客戶端發(fā)送需要確認的響應(yīng)消息；

es1504：客戶端向服務(wù)器發(fā)送ack消息；

es1506：客戶端開啟擁塞控制；

es1508：服務(wù)器向客戶端發(fā)送需要確認的響應(yīng)消息；

es1510：客戶端向服務(wù)器發(fā)送攜帶相應(yīng)代碼和延遲接入時間選項的特定的ack消息；

es1512：服務(wù)器暫停向服務(wù)器推送訂閱的資源；

es1514：服務(wù)器等待延遲接入時間選項所指示的時間；

es1516：客戶端負荷恢復(fù)正常；

es1518：服務(wù)器向客戶端重新發(fā)送需要確認的響應(yīng)消息；

es1520：客戶端向服務(wù)器發(fā)送ack消息。

值得說明的是，正常情況下，客戶端設(shè)備收到服務(wù)器設(shè)備推送的需要確認的請求消息后，都回復(fù)的是ack確認消息，只有當(dāng)客戶端需要向服務(wù)器通知延遲接入時才會用piggybacked的方式攜帶具體響應(yīng)內(nèi)容或者分開傳送ack和響應(yīng)。

根據(jù)本發(fā)明實施例，通過在消息交互過程中指定響應(yīng)方式選項，客戶端可以指定所需的響應(yīng)，提高了coap的消息交互效率。

實施例6：

本實施例描述了服務(wù)器和客戶端進行交互的流程：

1、客戶端向服務(wù)器發(fā)送請求，其中攜帶超時選項，并指示此請求是單播請求或是多播請求，是資源訂閱請求或是一次性請求；

2、服務(wù)器根據(jù)接收到的請求進行判斷，如果該請求是一次性請求，則服務(wù)器繼續(xù)判斷是單播請求還是多播請求：

a.如果該請求是單播一次性請求，服務(wù)器預(yù)先判斷自己是否能夠在超時選項指定的時間內(nèi)完成客戶端的請求，如果預(yù)測不能完成，則發(fā)回一個狀態(tài)碼(比如5.04,timeout，超時)給客戶端，表明不能在預(yù)定時間內(nèi)完成客戶端的請求；可選地，服務(wù)器預(yù)測自身空閑的時間，或是自身可以完成客戶端的請求的時間，并把這個預(yù)測時間在響應(yīng)中發(fā)回給客戶端，指示客戶端在指定的預(yù)測時間之后，再次發(fā)送請求；如果服務(wù)器能夠在指定的超時時間內(nèi)完成請求，則在超時時間過期前，發(fā)回響應(yīng)。

b.如果該請求是多播一次性請求，服務(wù)器在指定的時間內(nèi)任意選擇一個時間，返回響應(yīng)給客戶端。

3、如果服務(wù)器判斷客戶端的請求是訂閱請求，服務(wù)器繼續(xù)判斷該請求中攜帶的超時時間是patience選項，還是keep-alive選項：

a.如果請求中攜帶的是patience選項，則表明服務(wù)器需要在指定時間內(nèi)發(fā)回第一個通知消息；服務(wù)器在通知消息中攜帶資源的信息，以及max-age選項和patience時間選項，要求客戶端在指定時間內(nèi)保持與服務(wù)器資源的訂閱狀態(tài)。

b.如果請求中攜帶的是keep-alive時間選項，服務(wù)器在keep-alive時間內(nèi)，使用non-confirmable消息的方式，給客戶端發(fā)送通知消息；在keep-alive時間過期后，使用confirmable消息的方式，給客戶端發(fā)送通知消息。

圖16是根據(jù)本發(fā)明的一種傳輸數(shù)據(jù)資源的客戶端設(shè)備的實施例的框圖，其中所述客戶端設(shè)備1600包括：發(fā)送模塊1610，用于發(fā)送攜帶響應(yīng)方式選項的請求消息；和接收模塊1620，用于接收根據(jù)所述響應(yīng)方式選項生成的響應(yīng)消息。

參照圖11所述的本發(fā)明的實施例所描述的過程和特征均適用于圖16所示的客戶端設(shè)備。具體來說，例如，發(fā)送模塊1610發(fā)送的請求消息中攜帶的響應(yīng)方式選項可以是推遲選項，例如可以為：一次性的立即響應(yīng)、推遲的一次性的響應(yīng)、推遲的多個響應(yīng)和取消推遲的多個響應(yīng)。

根據(jù)一種實施例，發(fā)送模塊1610發(fā)送的請求消息中攜帶的響應(yīng)方式選項可以表示推遲的一次性的響應(yīng)的推遲時間或者推遲的多個響應(yīng)的截止時間。

根據(jù)一種實施例，發(fā)送模塊1610發(fā)送攜帶時間戳選項的請求消息，該時間戳表示接收響應(yīng)的截止時間；接收模塊1620接收攜帶時間戳選項的響應(yīng)消息，該時間戳表示響應(yīng)消息的生成時間。接收模塊1620根據(jù)接收到的響應(yīng)消息中的時間戳所表示的時間確定響應(yīng)消息的順序。

根據(jù)本發(fā)明實施例，在所述請求消息中，所述響應(yīng)方式選項為推遲的一次性的響應(yīng)或一次性的立即響應(yīng)，

所述請求消息還攜帶消息類型指示信息和延遲時間選項，其中所述消息類型指示信息指示所述請求消息為多播請求或單播請求；

所述接收模塊1620用于在所述延遲時間選項指示的時間內(nèi)，接收服務(wù)器發(fā)送的響應(yīng)消息。

根據(jù)本發(fā)明實施例，所述請求消息還包括截止時間選項，

所述接收模塊1620用于在所述截止時間選項指示的時間超時之前，接收服務(wù)器發(fā)送的響應(yīng)消息。

根據(jù)本發(fā)明實施例，在所述請求消息中，所述響應(yīng)方式選項為推遲的多個響應(yīng)，

所述接收模塊1620用于接收所述服務(wù)器發(fā)送的通知響應(yīng)消息，其中所述通知響應(yīng)消息攜帶最長存續(xù)時間選項和留候時間選項，其中所述留候時間選項用于指示，

在所述最長存續(xù)時間選項所指示時間超時之后，所述客戶端保持與所述服務(wù)器的訂閱關(guān)系，保持時間為所述留候選項所指示的時間。

根據(jù)本發(fā)明實施例，在所述請求消息中，所述響應(yīng)方式選項為推遲的多個響應(yīng)，所述請求消息還包括保持時間選項，所述接收模塊1620用于在所述保持時間選項指示的時間內(nèi)，接收服務(wù)器發(fā)送的第一通知響應(yīng)，其中所述第一通知響應(yīng)為不需要確認型消息；在所述保持時間選項指示的時間超時之后，所述接收模塊1620用于接收所述服務(wù)器發(fā)送的第二通知響應(yīng)，其中所述第二通知響應(yīng)為需要確認型消息，所述發(fā)送模塊1610用于向所述服務(wù)器發(fā)送確認ack消息。

根據(jù)本發(fā)明實施例，在所述請求消息中，所述響應(yīng)方式選項為推遲的一次性的響應(yīng)或一次性的立即響應(yīng)，所述請求消息還包括消息類型指示信息和截止時間選項，其中所述消息類型指示信息指示所述請求消息為單播請求，所述請求消息為需要確認型消息；

所述接收模塊1620用于接收所述服務(wù)器發(fā)送的特定的確認消息，其中所述特定的確認消息攜帶響應(yīng)代碼和延遲接入時間選項，其中所述響應(yīng)代碼表示所述服務(wù)器在所述截止時間選項所指示的時間內(nèi)無法返回針對所述請求消息的響應(yīng)；

或者

所述接收模塊1620用于接收所述服務(wù)器發(fā)送的確認消息；

并用于接收所述服務(wù)器發(fā)送的特定的響應(yīng)消息，其中所述特定的響應(yīng)消息攜帶響應(yīng)代碼和延遲接入時間選項，其中所述響應(yīng)代碼表示所述服務(wù)器在所述截止時間選項所指示的時間內(nèi)無法返回針對所述請求消息的響應(yīng)。

根據(jù)本發(fā)明實施例，所述接收模塊1620還用于清除緩存的等待向所述服務(wù)器發(fā)送的其他請求消息。

根據(jù)本發(fā)明實施例，在所述延遲接入時間選項所指示的時間之后，所述發(fā)送模塊1610還用于重新向所述服務(wù)器發(fā)送所述請求消息。

根據(jù)本發(fā)明實施例，在所述請求消息中，所述響應(yīng)方式選項為推遲的多個響應(yīng)，所述接收服務(wù)器發(fā)送的根據(jù)所述響應(yīng)方式選項生成的響應(yīng)消息是需要確認型消息，

所述發(fā)送模塊1610還用于向所述服務(wù)器發(fā)送特定的確認消息，其中所述特定的確認消息攜帶響應(yīng)代碼和延遲接入時間選項，其中所述響應(yīng)代碼表示客戶端在所述延遲接入時間選項所指示的時間內(nèi)無法返回針對所述響應(yīng)消息的確認；

或者

所述發(fā)送模塊1610用于向所述服務(wù)器發(fā)送確認消息；

并用于向所述服務(wù)器發(fā)送特定的響應(yīng)消息，其中所述特定的響應(yīng)消息攜帶響應(yīng)代碼和延遲接入時間選項，其中所述響應(yīng)代碼表示所述客戶端在所述延遲接入時間選項所指示的時間內(nèi)無法返回針對所述響應(yīng)消息的確認。

根據(jù)本發(fā)明實施例，所述響應(yīng)消息包括響應(yīng)消息生成時間，所述接收模塊1220還用于根據(jù)所述響應(yīng)消息生成時間確定響應(yīng)消息的順序。

圖17是根據(jù)本發(fā)明的一種傳輸數(shù)據(jù)資源的服務(wù)器設(shè)備的實施例，其中所述服務(wù)器設(shè)備1700包括：接收模塊1710，用于接收客戶端發(fā)送的攜帶響應(yīng)方式選項的請求消息；和發(fā)送模塊1720，向客戶端發(fā)送根據(jù)所述響應(yīng)方式選項生成的響應(yīng)消息。

參照圖12所述的本發(fā)明的實施例所描述的過程和特征均適用于圖17所示的服務(wù)器設(shè)備。具體來說，例如，接收模塊1710接收的請求消息中攜帶的響應(yīng)方式選項可以是推遲選項，例如可以為：一次性的立即響應(yīng)、推遲的一次性的響應(yīng)、推遲的多個響應(yīng)和取消推遲的多個響應(yīng)。

根據(jù)本發(fā)明實施例，在所述請求消息中，所述響應(yīng)方式選項為推遲的一次性的響應(yīng)或一次性的立即響應(yīng)，所述請求消息還包括消息類型指示信息和延遲時間選項，其中所述消息類型指示信息指示所述請求消息為多播請求或單播請求；所述發(fā)送模塊1720用于在所述延遲時間選項指示的時間內(nèi)，經(jīng)過隨機延時之后，向所述客戶端發(fā)送響應(yīng)消息。

根據(jù)本發(fā)明實施例，所述請求消息還包括截止時間選項，所述發(fā)送模塊1720用于在所述截止時間選項指示的時間超時之前，向所述客戶端發(fā)送響應(yīng)消息。

根據(jù)本發(fā)明實施例，在所述請求消息中，所述響應(yīng)方式選項為推遲的多個響應(yīng)，

所述發(fā)送模塊1720用于向所述客戶端發(fā)送通知響應(yīng)，其中所述通知響應(yīng)攜帶最長存續(xù)時間選項和留候時間選項，其中所述留候時間選項用于指示，

在所述最長存續(xù)時間選項所指示的時間超時之后，所述服務(wù)器將在所述留候時間選項所指示的時間內(nèi)作出響應(yīng)。

根據(jù)本發(fā)明實施例，在所述請求消息中，所述響應(yīng)方式選項為推遲的多個響應(yīng)，所述請求消息還包括保持時間選項，所述發(fā)送模塊1720用于在所述保持時間選項指示的時間內(nèi)，向所述客戶端發(fā)送第三通知響應(yīng)，其中所述第三通知響應(yīng)為不需要確認型消息；所述發(fā)送模塊1720還用于在所述保持時間選項指示的時間超時之后，向所述客戶端發(fā)送第四通知響應(yīng)，其中所述第四通知響應(yīng)為需要確認型消息；所述接收模塊1710用于接收所述客戶端發(fā)送的ack消息。

根據(jù)本發(fā)明實施例，在所述請求消息中，所述響應(yīng)方式選項為推遲的一次性的響應(yīng)或一次性的立即響應(yīng)，所述請求消息還包括消息類型指示信息和截止時間選項，其中所述消息類型指示信息指示所述請求消息為單播請求，所述請求消息為需要確認型消息；

所述發(fā)送模塊1720用于向客戶端發(fā)送特定的確認消息，其中所述特定的確認消息攜帶響應(yīng)代碼和延遲接入時間選項，其中所述響應(yīng)代碼表示所述服務(wù)器在所述截止時間選項所指示的時間內(nèi)無法返回針對所述請求消息的響應(yīng)；

或者

所述發(fā)送模塊1720用于向客戶端發(fā)送確認消息；

并用于向客戶端發(fā)送特定的響應(yīng)消息，其中所述特定的響應(yīng)消息攜帶響應(yīng)代碼和延遲接入時間選項，其中所述響應(yīng)代碼表示所述服務(wù)器在所述截止時間選項所指示的時間內(nèi)無法返回針對所述請求消息的響應(yīng)。

根據(jù)本發(fā)明實施例，在所述延遲接入時間選項所指示的時間之后，所述接收模塊1710用于接收所述客戶端重新發(fā)送的所述請求消息。

根據(jù)本發(fā)明實施例，在所述請求消息中，所述響應(yīng)方式選項為推遲的多個響應(yīng)，所述向客戶端發(fā)送的根據(jù)所述響應(yīng)方式選項生成的響應(yīng)消息是需要確認型消息，所述接收模塊1710用于接收所述客戶端發(fā)送的特定的確認消息，其中所述特定的確認消息攜帶響應(yīng)代碼和延遲接入時間選項，其中所述響應(yīng)代碼表示所述客戶端在所述延遲接入時間選項所指示的時間內(nèi)無法返回針對所述響應(yīng)消息的確認；

或者

所述接收模塊1710用于接收所述客戶端發(fā)送的確認消息；

并用于接收所述客戶端發(fā)送特定的響應(yīng)消息，其中所述特定的響應(yīng)消息攜帶響應(yīng)代碼和延遲接入時間選項，其中所述響應(yīng)代碼表示所述客戶端在所述延遲接入時間選項所指示的時間內(nèi)無法返回針對所述響應(yīng)消息的確認。

根據(jù)本發(fā)明實施例，在所述延遲接入時間選項所指示的時間超時后，所述發(fā)送模塊1720用于向所述客戶端重新發(fā)送所述需要確認型響應(yīng)消息。

根據(jù)本發(fā)明的另一種實施例，接收模塊1710接收的請求消息中可以攜帶時間戳選項，該時間戳選項表示接收響應(yīng)的截止時間，而發(fā)送模塊1320發(fā)送的響應(yīng)消息中也可以攜帶時間戳選項，所述時間戳選項表示響應(yīng)消息的生成時間。

本領(lǐng)域普通技術(shù)人員可以意識到，結(jié)合本文中所公開的實施例描述的各示例的單元及算法步驟，能夠以電子硬件、計算機軟件或者二者的結(jié)合來實現(xiàn)，為了清楚地說明硬件和軟件的可互換性，在上述說明中已經(jīng)按照功能一般性地描述了各示例的組成及步驟。這些功能究竟以硬件還是軟件方式來執(zhí)行，取決于技術(shù)方案的特定應(yīng)用和設(shè)計約束條件。專業(yè)技術(shù)人員可以對每個特定的應(yīng)用來使用不同方法來實現(xiàn)所描述的功能，但是這種實現(xiàn)不應(yīng)認為超出本發(fā)明的范圍。

結(jié)合本文中所公開的實施例描述的方法或算法的步驟可以用硬件、處理器執(zhí)行的軟件模塊，或者二者的結(jié)合來實施。軟件模塊可以置于隨機存儲器(ram)、內(nèi)存、只讀存儲器(rom)、電可編程rom、電可擦除可編程rom、寄存器、硬盤、可移動磁盤、cd-rom、或技術(shù)領(lǐng)域內(nèi)所公知的任意其它形式的存儲介質(zhì)中。

盡管已示出和描述了本發(fā)明的一些實施例，但本領(lǐng)域技術(shù)人員應(yīng)理解，在不脫離本發(fā)明的原理和精神的情況下，可對這些實施例進行各種修改，這樣的修改應(yīng)落入本發(fā)明的范圍內(nèi)。