CN107071826A - 数据资源传输的方法和设备 - Google Patents

数据资源传输的方法和设备 Download PDF

Info

Publication number
CN107071826A
CN107071826A CN201710132014.2A CN201710132014A CN107071826A CN 107071826 A CN107071826 A CN 107071826A CN 201710132014 A CN201710132014 A CN 201710132014A CN 107071826 A CN107071826 A CN 107071826A
Authority
CN
China
Prior art keywords
time
message
response
server
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201710132014.2A
Other languages
English (en)
Other versions
CN107071826B (zh
Inventor
李克鹏
田林
田林一
卞永刚
陈显锋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of CN107071826A publication Critical patent/CN107071826A/zh
Application granted granted Critical
Publication of CN107071826B publication Critical patent/CN107071826B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0231—Traffic management, e.g. flow control or congestion control based on communication conditions
    • H04W28/0236—Traffic management, e.g. flow control or congestion control based on communication conditions radio quality, e.g. interference, losses or delay
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1078—Resource delivery mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1078—Resource delivery mechanisms
    • H04L67/108—Resource delivery mechanisms characterised by resources being split in blocks or fragments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/142—Managing session states for stateless protocols; Signalling session states; State transitions; Keeping-state mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H04L67/5651—Reducing the amount or size of exchanged application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • H04W80/12—Application layer protocols, e.g. WAP [Wireless Application Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Abstract

本发明实施例涉及一种在物联网系统中数据资源的传输方法，包括：客户端向服务器发送的请求消息，所述请求消息中包含第一时间戳选项，所述第一时间戳选项包含一个截止时间值，用于指示所述服务器在所述截止时间值指定的时间内向所述客户端返回响应消息；所述客户端在所述截止时间指示的时间超时之前，接收所述服务器发送的响应消息。该方法由客户端在请求资源时向服务器指示响应时间，如果客户端未在指定响应时间内收到服务器的响应，客户端可以断开与服务器之间的连接，不需要为等待服务器响应长时间与服务器保持长连接，节省网络资源和功率消耗。

Description

数据资源传输的方法和设备
技术领域
本发明实施例涉及网络通信领域，并且更具体地涉及数据资源传输的方法和设备。
背景技术
轻量级应用层协议(Constrained Application Protocol，简称“CoAP”)主要是用于物联网(Machine to Machine，简称“M2M”)的场景中，比如：家庭控制器、楼宇自动化、智能能源、传感器网络等。在这样的环境中，这些机器的功能比较简单，一般处理器只有8位，存储空间小，不支持复杂的传输协议，数据传输速率也较低。CoAP提供一种请求/响应的交互模式，支持内嵌的资源发现，包括关键的网页概念，比如统一资源标识(URI)和内容类型。CoAP可以很容易地翻译到超文本链接协议(HTTP)，用于集成到网络中。基于CoAP传输数据的传统方案中不计算数据资源的准确容量，无法评估分包的精确数目，因此无法并发获取数据资源，造成传输效率低下。
另外由于很多使用CoAP的设备处理能力较低，最大传输速率也低，所以在激活多个连接或者同时处理多个请求时，CoAP设备就很容易面临拥塞问题，导致无法及时处理后续新发生的任务。为了解决拥塞，现有CoAP协议中规定了一种消息重发控制机制，当CoAP客户端设备向服务器设备发送的需要确认的(Confirmable)消息并且长时间没有得到响应时(拥塞等问题导致)，客户端设备会在Tn秒后重发该消息并重复若干次，直到收到服务器设备发回的响应消息或者达到最大重发次数限制而放弃尝试；设默认重发间隔为x秒且当前为第n次重发，则Tn＝x+random(0～2n)，其中random(0～2n)为0到2n之间的任一随机整数，因此该方法也被称为指数后退算法，每次重发的时间间隔以指数级增加，给予服务器设备更宽松的响应时间。但现有技术使用的算法是基于时隙的，消息级别的拥塞控制，并不能有效解决节点级别的拥塞问题，当server因为资源处理能力达到瓶颈，或者发生异常的时候，指数后退就显得杯水车薪了，而且因为是client端的随机算法，也完全没有考虑到server的具体状态，严重时候可能会进一步加重拥塞。
发明内容
本发明实施例提供了一种数据资源传输的方法和设备，能够支持在CoAP中提高传输效率。
在本发明实施例中，提供了一种在物联网系统中基于轻量级应用层协议的节点的数据资源传输方法，包括：向服务器发送携带响应方式选项的请求消息，其中所述响应方式选项表示以下响应方式其中一项：一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推迟的多个响应；接收所述服务器发送的根据所述响应方式选项生成的响应消息
在本发明实施例中，提供了一种在物联网系统中基于轻量级应用层协议的节点的数据资源传输方法，包括：接收客户端发送的携带响应方式选项的请求消息，其中所述响应方式选项表示以下响应方式其中一项：一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推迟的多个响应；向客户端发送根据所述响应方式选项生成的响应消息。
在本发明实施例中，提供了一种在物联网系统中基于轻量级应用层协议传输节点的数据资源的客户端，包括：发送模块，用于向服务器发送携带响应方式选项的请求消息，其中所述响应方式选项表示以下响应方式其中一项：一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推迟的多个响应；接收模块，用于接收根据响应方式选项生成的响应消息。
在本发明实施例中，提供了一种在物联网系统中基于轻量级应用层协议传输节点的数据资源的服务器设备，包括：接收模块，用于接收客户端发送的携带响应方式选项的请求消息，其中所述响应方式选项表示以下响应方式其中一项：一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推迟的多个响应；发送模块，向所述客户端发送根据所述响应方式选项生成的响应消息。
根据本发明实施例，通过在消息交互过程中指定响应方式选项，客户端可以指定所需的响应，提高了CoAP的消息交互效率。
根据本发明实施例，可以对响应方式进行指示，并根据所指示的响应方式接收响应消息，这样便于请求方进行会话处理，以提高传输效率，比如：在指示延迟响应时间的情况下，避免请求方一直等待响应消息，可以在指示的延迟时间过期后，提前结束会话；在请求方指示立即响应时，如果在请求方自定义的超时时间内，不能接收到响应消息，也可以提前结束会话；在指示延迟的多次响应时，请求方可以保存资源订阅的信息，以便于接收多个推迟的响应。
本发明另一实施例提供一种在物联网系统中基于轻量级应用层协议的节点的数据资源传输方法，包括：
向服务器发送携带响应方式选项的请求消息，其中所述响应方式选项表示以下响应方式其中一项：一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推迟的多个响应；
接收所述服务器发送的根据所述响应方式选项生成的响应消息。
根据该实施例的可选方式，在所述请求消息中，所述响应方式选项为推迟的一次性的响应或一次性的立即响应，
所述请求消息还携带消息类型指示信息和延迟时间选项，其中所述消息类型指示信息指示所述请求消息为多播请求或者单播请求；
接收根据所述响应方式选项生成的响应消息，包括：
在所述延迟时间选项指示的时间内，接收服务器发送的响应消息。
根据该实施例的可选方式，所述请求消息还包括截止时间选项，
接收根据所述响应方式选项生成的响应消息，包括：
在所述截止时间选项指示的时间超时之前，接收服务器发送的响应消息。
根据该实施例的可选方式，所述消息类型指示信息为以下其中一项：
预设的用于发送多播请求的套接字端口；
预设的用于发送多播请求的网络协议IP地址；
预设的用于发送多播请求的端口号；
所述请求消息中的消息类型指示选项。
根据该实施例的可选方式，在所述请求消息中，所述响应方式选项为推迟的多个响应，
所述接收服务器发送的根据所述响应方式选项生成的响应消息，包括：
接收所述服务器发送的通知响应消息，其中所述通知响应消息携带最长存续时间选项和留候时间选项，其中所述留候时间选项用于指示，在所述最长存续时间选项所指示时间超时之后，客户端保持与所述服务器的订阅关系，保持时间为所述留候选项所指示的时间。
根据该实施例的可选方式，在所述请求消息中，所述响应方式选项为推迟的多个响应，
所述请求消息还包括保持时间选项，
所述接收服务器发送的根据所述响应方式选项生成的响应消息，包括：
在所述保持时间选项指示的时间内，接收服务器发送的第一通知响应，其中所述第一通知响应为不需要确认型消息；
在所述保持时间选项指示的时间超时之后，接收所述服务器发送的第二通知响应，其中所述第二通知响应为需要确认型消息。
向所述服务器发送确认ACK消息。
根据该实施例的可选方式，在所述请求消息中，所述响应方式选项为推迟的一次性的响应或一次性的立即响应，
所述请求消息还包括消息类型指示信息和截止时间选项，其中所述消息类型指示信息指示所述请求消息为单播请求，所述请求消息为需要确认型消息；
接收服务器发送的根据所述响应方式选项生成的响应消息，包括：
接收所述服务器发送的特定的确认消息，其中所述特定的确认消息携带响应代码和延迟接入时间选项，其中所述响应代码表示所述服务器在所述截止时间选项所指示的时间内无法返回针对所述请求消息的响应；
或者
接收所述服务器发送的确认消息；
接收所述服务器发送的特定的响应消息，其中所述特定的响应消息携带响应代码和延迟接入时间选项，其中所述响应代码表示所述服务器在所述截止时间选项所指示的时间内无法返回针对所述请求消息的响应。
根据该实施例的可选方式，清除缓存的等待向所述服务器发送的其他请求消息。
根据该实施例的可选方式，在所述延迟接入时间选项所指示的时间之后，重新向所述服务器发送所述请求消息。
根据该实施例的可选方式，在所述请求消息中，所述响应方式选项为推迟的多个响应，
所述接收服务器发送的根据所述响应方式选项生成的响应消息是需要确认型消息，
所述方法进一步包括：
向所述服务器发送特定的确认消息，其中所述特定的确认消息携带响应代码和延迟接入时间选项，其中所述响应代码表示客户端在所述延迟接入时间选项所指示的时间内无法返回针对所述响应消息的确认；
或者
向所述服务器发送确认消息；
向所述服务器发送特定的响应消息，其中所述特定的响应消息携带响应代码和延迟接入时间选项，其中所述响应代码表示所述客户端在所述延迟接入时间选项所指示的时间内无法返回针对所述响应消息的确认。
根据该实施例的可选方式，所述响应消息包括响应消息生成时间，
所述方法还包括：
根据所述响应消息生成时间确定响应消息的顺序。
根据该实施例的可选方式，接收客户端发送的携带响应方式选项的请求消息，其中所述响应方式选项表示以下响应方式其中一项：一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推迟的多个响应；
向客户端发送根据所述响应方式选项生成的响应消息。
根据该实施例的可选方式，在所述请求消息中，所述响应方式选项为推迟的一次性的响应或一次性的立即响应，
所述请求消息还包括消息类型指示信息和延迟时间选项，其中所述消息类型指示信息指示所述请求消息为多播请求或单播请求；
所述向客户端发送根据所述响应方式选项生成的响应消息，包括：
在所述延迟时间选项指示的时间内，经过随机延时之后，向所述客户端发送响应消息。
根据该实施例的可选方式，所述请求消息还包括截止时间选项，
所述向客户端发送根据所述响应方式选项生成的响应消息，包括：
在所述截止时间选项指示的时间超时之前，向所述客户端发送响应消息。
根据该实施例的可选方式，所述消息类型指示信息为以下其中一项：
预设的用于发送多播请求的套接字端口；
预设的用于发送多播请求的网络协议IP地址；
预设的用于发送多播请求的端口号；
所述请求消息中的消息类型指示选项。
根据该实施例的可选方式，在所述请求消息中，所述响应方式选项为推迟的多个响应，
所述向客户端发送根据所述响应方式选项生成的响应消息，包括：
向所述客户端发送通知响应，其中所述第一通知响应携带最长存续时间选项和留候时间选项，其中所述留候时间选项用于指示，在所述最长存续时间选项所指示的时间超时之后，服务器将在所述留候时间选项所指示的时间内作出响应。
根据该实施例的可选方式，在所述请求消息中，所述响应方式选项为推迟的多个响应，
所述请求消息还包括保持时间选项，
所述向客户端发送根据所述响应方式选项生成的响应消息，包括：
在所述保持时间选项指示的时间内，向所述客户端发送第三通知响应，其中所述第三通知响应为不需要确认型消息；
在所述保持时间选项指示的时间超时之后，向所述客户端发送第四通知响应，其中所述第四通知响应为需要确认型消息；
接收所述客户端发送的确认ACK消息。
根据该实施例的可选方式，在所述请求消息中，所述响应方式选项为推迟的一次性的响应或一次性的立即响应，
所述请求消息还包括消息类型指示信息和截止时间选项，其中所述消息类型指示信息指示所述请求消息为单播请求，所述请求消息为需要确认型消息；
所述向客户端发送的根据所述响应方式选项生成的响应消息，包括：
向客户端发送特定的确认消息，其中所述特定确认消息携带响应代码和延迟接入时间选项，其中所述响应代码表示所述服务器在所述截止时间选项所指示的时间内无法返回针对所述请求消息的响应；
或者
向客户端发送确认消息；
向客户端发送特定的响应消息，其中所述特定的响应消息携带响应代码和延迟接入时间选项，其中所述响应代码表示所述服务器在所述截止时间选项所指示的时间内无法返回针对所述请求消息的响应。
根据该实施例的可选方式，在所述延迟接入时间选项所指示的时间之后，接收所述客户端重新发送的所述请求消息。
根据该实施例的可选方式，在所述请求消息中，所述响应方式选项为推迟的多个响应，
所述向客户端发送的根据所述响应方式选项生成的响应消息是需要确认型消息，
所述方法进一步包括：
接收所述客户端发送的特定的确认消息，其中所述特定的确认消息携带响应代码和延迟接入时间选项，其中所述响应代码表示所述客户端在所述延迟接入时间选项所指示的时间内无法返回针对所述响应消息的确认；
或者
接收所述客户端发送的确认消息；
接收所述客户端发送特定的响应消息，其中所述特定的响应消息携带响应代码和延迟接入时间选项，其中所述响应代码表示所述客户端在所述延迟接入时间选项所指示的时间内无法返回针对所述响应消息的确认。
根据该实施例的可选方式，在所述延迟接入时间选项所指示的时间超时后，向所述客户端重新发送的所述需要确认型响应消息；
接收所述客户端发送的确认消息。
根据该实施例的可选方式，所述响应消息包括响应消息生成时间。
根据该实施例的可选方式，发送模块，用于向服务器发送携带响应方式选项的请求消息，其中所述响应方式选项表示以下响应方式其中一项：一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推迟的多个响应；
接收模块，用于接收所述服务器根据所述响应方式选项生成的响应消息。
根据该实施例的可选方式，在所述请求消息中，所述响应方式选项为推迟的一次性的响应或一次性的立即响应，
所述请求消息还携带消息类型指示信息和延迟时间选项，其中所述消息类型指示信息指示所述请求消息为多播请求或单播请求；
所述接收模块用于在所述延迟时间选项指示的时间内，接收服务器发送的响应消息。
所述请求消息还包括截止时间选项，
所述接收模块用于在所述截止时间选项指示的时间超时之前，接收服务器发送的响应消息。
根据该实施例的可选方式，接收模块，用于接收客户端发送的携带响应方式选项的请求消息，其中所述响应方式选项表示以下响应方式其中一项：一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推迟的多个响应；
发送模块，向所述客户端发送根据所述响应方式选项生成的响应消息。
根据该实施例的可选方式，在所述请求消息中，所述响应方式选项为推迟的一次性的响应或一次性的立即响应，所述请求消息还包括消息类型指示信息和延迟时间选项，其中所述消息类型指示信息指示所述请求消息为多播请求或单播请求；
所述发送模块用于在所述延迟时间选项指示的时间内，经过随机延时之后，向所述客户端发送响应消息。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。在附图中：
图1是本发明一种实施例的传输数据的方法的流程图；
图2是本发明一种实施例的网关从传感器获取数据资源的具体实现过程的流程图；
图3是本发明一种实施例中改进的分片选项的结构图；
图4是本发明一种替代实施例的网关从传感器获取数据资源具体实现过程的流程图；
图5是本发明一种替代实施例中改进的分片选项的结构图；
图6是本发明一种替代实施例的网关从传感器获取数据资源的具体实现过程的流程图；
图7是本发明一种替代实施例中改进的分片选项的结构图；
图8是本发明一种实施例的网关向传感器发送数据资源的具体实现过程的流程图；
图9是本发明一种实施例的客户端设备的框图；
图10是本发明一种实施例的服务器设备的框图；
图11是本发明一种实施例的传输数据的方法的流程图；
图12是本发明一种实施例的传输数据的方法的流程图；
图13是本发明一种实施例的消息交互图；
图14是本发明一种实施例的消息交互图；
图15是本发明一种实施例的消息交互图；
图16是本发明一种实施例的传输数据的客户端的结构图；
图17是本发明一种实施例的传输数据的服务器的结构图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
CoAP是基于用户数据报协议(User Datagram Protocol，简称“UDP”)进行传输，是基于无连接的消息处理模式。其交互模式可以是同步的响应，也可以是异步的响应。消息类型可以是：需要确认的消息(Confirmable)、不需要确认的消息(Non-confirmable)、确认消息(Acknowledgement)、重置消息(Reset)。可以通过消息标识(Message ID)来关联一对请求和响应。
CoAP支持的方法有四个：获取资源(Get)、更新资源(Put)、创建资源(Post)和删除资源(Delete)。资源通过表述性状态转移(Representational State Transfer，简称“REST”)URI来识别。我们通常称资源的拥有方为节点或服务器，包括但不限于传感器、控制器、端点(End-point)等，请求资源方为客户端，包括但不限于网关(Proxy)、网络侧设备。
CoAP协议支持不同的选项(Option)，用以解释CoAP消息体中数据的语义，比如Block(分片)、Location(位置)、Token(令牌)选项等，不同的选项支持不同的功能，并且可以通过定义新的Option来扩展新的功能。
CoAP支持分片选项(Block Option)，主要用于将较大的资源进行分片传输，以适应于低带宽传输的应用场景。Block选项可以为1个字节、2个字节或3个字节，依据分片数目的容量所需要的长度进行选取。
传统方案中不计算数据资源的准确容量，无法评估分包的精确数目，因此无法并发获取。另外也不知道资源是静态的还是动态的。
在以下描述中，通常称资源的拥有方为服务器，以传感器作为示例，请求资源方为客户端，以网关作为示例。但是，传感器或者网关并不用作对服务器或者客户端的限制。
由于不知道目标资源的精确容量，网关在<Get>命令中使用Block Option时，只能按顺序来获取，即选获取Block 0，等Block 0返回时，再获取Block 1，一直到最后一个Block。不能并发地发送<Get>请求。
Block选项的字段结构一般包括NUM字段，M字段和SZX字段，其中
NUM表示分片的顺序序号，可以是4～20位的无符号整型数字。0表示第一个分片。
M：用一个比特位来表示当前分片后面是否还有其他分片，其值为1表示后面还有分片，为0表示后面没有分片，即为最后一个分片。
SZX：用于表征分片容量，其计算公式为：分片容量＝2^(SZX+4)，即2的(SZX+4)次方。由于SZX由3个比特位来表示，其值可以为0～7，所以分片容量的取值范围：2^4～2^11，即16～2048。
对于Block选项的使用说明如下：
在<Get>请求中，Block选项的NUM字段给出当前请求的分片的序号，并且当分片序号为0时，SZX给出网关建议的每个分片的容量。在<Get>响应中或是<Put>/<Post>请求中，Block选项的NUM字段描述当前传输的分片的序号，M字段表明后面是否还有后续分片。
在<Put>/<Post>响应中，Block选项的NUM字段表明当前响应的分片序号。
当网关使用<Get>方法获取第一个分片(Block)时，NUM被设置为0，并携带建议的分片容量(即SZX)，传感器节点可以选择同意建议的分片容量，或是选择一个比建议分片小的分片，并在响应中返回，同时，在响应中返回第一个分片的数据。
本发明考虑网关事先获知目标资源的精确容量，则网关可以选择是否用BlockOption来发送资源获取的请求，也可以实现并发请求，即在请求Block 0的同时，也可以请求Block 1，而不必等待。在请求Block的顺序上也可以灵活处理。
简单设计方案中，Block Option有三个选择，可以是一个字节，可以是2个字节，也可以是三个字节，依据资源的容量不同，分片(Block)的数量容量不同，所需要的长度也不一样。协议规定，除了最后一个分片外，分片的容量必须相同，但每次传输中，还是每次都需要携带M位(表明后面是否还有分片)和SZX(分片的容量)。
每次在请求和响应中，M位和SZX位都需要传送，而实际上，除了最后一个分片外，M位和SZX的值每次都是相同的，重复的传输浪费传输资源。重复发送SZX的目的假定双方都不保存协商后的SZX，第一次响应中携带的是协商后的SZX，网关从响应中获取并再次在请求中发送，从而网关和传感器都不需要保存状态。在一次的请求响应回合中，共浪费一个字节，如果分片数目很多时，浪费的字节就很多了，对于M2M设备，传输资源是受限的，这个传输资源的浪费是很可观的。假设要传送的数据为64M的话，每个Block的负载(payload)容量为1024byte则发送的block条目数为：65536。则发送的Block选项按照字节来分的个数为：
(1)一个字节：16个
(2)两个字节：4080个
(3)三个字节：61440个
如果M和SZX可以不发送，则请求加上响应能够节省的数据为65536字节(byte)，即64K数据。另外，如果这两个字段不要，则NUM字段可以用满所有位(bit)，则需要发送的数据包的数目变更为：
(1)一个字节：256个
(2)两个字节：65280个
此时不需要发送3个字节的结构，因此还可以节省数据为61440*2bytes，即60K数据。则总共节省数据位124K，节省数据率0.189％。头域节省百分比为(16+4080*2+61440*3-256-65280*2)/(16+4080*2+61440*3)＝61680/192496＝32％。
节省数据量的公式：
T为总的Block数量，S为分片容量(Block Size)，节省的流量的百分比(只比较头域)：
T<16时：无节省；两者都是一个字节；
16<T<256时：1-T*1/(16*1+(T-16)*2)，简单设计方案需要2个字节，优选方案只需要一个字节；
256<T<4096时：1-(256*1+(T-256)*2))/(16*1+(T-16)*2)，简单设计方案需要2个字节，优选方案需要2个字节；
4096<T<65256时：1-(256*1+(4096-256)*2+(T-4096)*3))/(256*1+(T-256)*2)，简单设计方案需要3个字节，优选方案需要2个字节。
T>65256时，无节省，本发明优选方案实施例和简单设计方案都需要3个字节。
简单设计方案中，使用Put/Post命令时，分片容量协商缺乏效率。在Put/Post请求中，对于第一个分片，需要发送第一个分片的数据和推荐的分片容量，如果传感器节点选择不一样的分片容量，网关需要按照传感器的分片容量进行重新发送，则上次发送的分片数据被浪费掉了。而且，网关在使用Put/Post请求基于分片选项发送容量大的资源时，事先无法告知传感器资源容量信息，在传输过程中，传感器边接收，边缓存所接收的资源，如果传感器发现存储空间不够，而资源又未传输完成时，只能发送回一个413的错误状态码，表示请求的资源太大，结束此次传输。此前传输的部分资源则没用了，传输资源被浪费了。如果网关能够在第一个分片消息中告知传感器所要传输的资源的容量信息，传感器则可以比较资源容量信息与存储容量，如果容量不足，提前返回413“请求的资源太大”的状态码，来结束资源传输，以此来达到节省传输资源的目的。
互联网上的断点续传，也就是要从文件已经下载的地方开始继续下载。网关在向传感器请求数据的时候，要多加一条信息来表示请求下载数据的范围(Range)，表明从哪里开始。
比如，网关用浏览器来传递请求信息给Web传感器，要求从2000070字节开始：
GET/down.zip HTTP/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字节开始传，前面的字节不用传了。
这种方案的缺点是，没有分片机制，不支持分片容量的协商，也不支持分片总数的协商。本发明实施例考虑了在分片传输过程中，进行分片容量和/或分片总数的协商。为此本发明提供了一种数据分片传输的方法，可以获取目标数据资源的精确容量，进行分片容量的协商，获取分片总数，并根据分片总数进行数据资源传输。
以下参照图1具体说明本发明一种实施例的流程。图1是本发明一种实施例的流程图。
在S110过程中，获取节点的数据资源的容量信息。如果是网关从传感器获取数据，则节点的数据资源容量信息保存在传感器上。网关可以通过请求消息，向传感器获取节点的数据资源的容量信息。如果是网关向传感器发送数据，则网关本地已经知道了节点的数据资源的容量信息。获取节点的数据资源容量信息，是为下一步进行分片容量的协商并确定分片总数做准备。
接着，在S120的过程中，网关向传感器发送携带第一分片选项的请求消息，其中所述第一分片选项包括推荐的分片容量。传感器在收到S120中发送的请求消息之后，根据自身能力，确定本次数据资源传输过程中所使用的分片容量，并且传感器确定的分片容量小于等于网关推荐的分片容量。
在S130，网关接收携带第二分片选项的响应消息，其中所述第二分片选项包括确定的分片容量，所述确定的分片容量小于等于所述推荐的分片容量。网关在接到确定的分片容量之后，根据掌握的节点的数据资源容量信息，确定将要传输的节点的数据资源的分片总数。
然后，在S140，根据所述确定的分片容量以及所述节点的数据资源容量信息，分片传输所述数据资源。
根据本发明实施例，可以获知需要传输的数据资源的容量信息，并通过分片容量协商确定传输数据时使用的分片容量，由此可以实现传输过程中错误率降低，并且可以并发地传输数据。
以下结合图2说明如图1所示实施例的具体实现过程。图2表示的是网关从传感器获取数据的说明性示例，仅为说明本发明的构思，而不作为对本发明的限制。
图2所示数据资源获取过程具体描述如下：
ES210：网关向传感器发送资源发现请求，即通过Get./wellknown/core来获取传感器上的资源列表。
ES220：传感器向网关返回资源列表，以及资源指示信息；资源指示信息主要包括资源的寻址信息(即URI)、资源名称、资源描述信息、内容类型等。本发明对资源指示信息进行扩展，扩展的资源指示信息包括：资源是动态资源还是静态资源的指示信息。
ES230：网关根据传感器返回的资源列表，根据资源的指示信息，从中选择目标资源，并根据识别标识(能唯一识别资源的信息，比如资源名称、URI等)，获取目标资源。
ES240：传感器对目标资源容量进行判断，如果资源容量小于一个传输层消息包的容量，则直接返回资源内容给网关；如果资源容量超过一个传输层消息包的容量，则返回资源容量信息。可选地，传感器可使用分片选项，根据自身确定的分片容量，直接返回第一个分片。后续客户端和传感器根据此确定的分片容量，使用分片选项传输如下的分片。
在本发明一种替代实施例中，如果目标数据资源为动态数据资源，同时返回动态数据资源指示给网关，并用413“请求资源太大”的状态码指示网关使用Block选项来获取资源。
如果数据资源为动态资源，则指示信息中的资源容量表示的是当前的资源快照(Snapshot)的容量信息，传感器需要缓存此快照数据；如果是静态资源，则指示信息中的资源容量信息是精确的容量信息。本领域技术人员应该理解，如果数据资源为动态资源，则传感器可以发送资源快照的校验码，网关如果需要更新鲜的数据，可以后续再发送新的资源获取请求。
ES250：网关根据数据资源容量信息，判断需要使用分片选项，并发送携带分片选项的请求消息，与传感器器进行分片容量协商，指示推荐的分片容量。
ES260：传感器根据自身能力，确定分片容量，并将其返回给网关。可选地，传感器同时返回分片总数。当然，由于网关已经获取了数据资源容量信息，分片总数也可以由网关确定。需要说明的是，传感器确定的分片容量只能小于或等于网关推荐的分片容量。
ES270：网关从1一直到分片总数，依次向传感器发送请求，请求获取与分片序号对应的数据资源的分片数据。
ES280：传感器根据确定的分片容量，返回该分片序号及与该分片序号对应的数据资源的分片数据，直到完全传输完毕。
根据本发明的一种优选实施例，ES270中可以实现并行处理，即网关可以同时请求获取多个分片消息，而不需要等待传感器返回对前一个分片请求消息的响应消息。
ES210至ES240的代码例如为：
REQ:GET/.well-known/core---发送请求到默认的URI，即根目录获取资源列表；
RES:200OK--响应标识获取成功，并携带了2组资源指示信息；
</sensors/temp>；ct＝41；n＝"TemperatureC",--温度资源，内容类型41，名称为TemperatureC；
</sensors/light>；ct＝41；n＝"LightLux"--灯光资源，内容类型41，名称为LightLux；
</sensors/firmware>；ct＝52；n＝"firmware"；snapshot＝0--固件资源，内容类型52，名称为firmware，非动态资源；
</sensors/log>；ct＝52；n＝"log"；snapshot＝1--固件资源，内容类型52，名称为log，动态资源，当前数据为快照snapshot；
REQ:GET/sensors/firmware–请求固件资源
RES:413“Request Entity Too Large”Size:88000.413状态码表明请求的资源太大，其精确容量为88000字节。
如果数据资源为动态资源，即数据资源在传输的过程会动态变化，例如可以采用以下两种方案实施处理：
(1)在开始传送数据资源时，对该资源建立快照(Snapshot)，即缓存此刻该数据资源的容量信息，并传输这个容量信息，不管后续的变化；对应上述方案。
(2)如果数据资源在传输过程中被修改，传感器可以在任意一个获取数据资源的请求消息的响应消息中，返回错误码，指示数据资源已更改，网关需要重新获取。
可选地，网关和传感器在消息交互中，增加认证信息。认证信息中可包含身份标识(ID)、基于身份标识和密码(Password)算出来的密钥信息(Digest)。身份标识和密码可以是预先配置给网关和传感器双方。配置过程：
例如，密钥的算法可以为：Digest＝MD5(ID:Password)，即对ID和Password组成的字符串使用MD5算法进行哈希(Hash)，Hash的值为Digest。发送方发送ID和Digest，接收方根据接收到ID和预先存储的Password，根据同样的算法得出Digest，与发送方发送的Digest进行比较，如果一致，则认证通过。
网关从传感器获取数据资源时，如图2所示，需要知道数据资源容量信息。根据本发明一种实施例，网关可以采用如下方案来获取存储于传感器的数据资源容量信息。
(1)扩展链接格式(Link-format)关键字
在Link-format中，扩展一个关键字，-sn，或-snapshot，用于在获取数据资源请求的响应中，表明资源数据是否是快照数据。如果此参数不存在，或其值为0，表明是静态资源，如果此参数的值为1，则表明是当前数据是动态资源，获取的数据是当前的快照。静态资源是指一段时间内相对稳定的资源，即资源内容不会频繁更改。具体含义可以在标准中进行定义。在本发明中，主要指资源的值不改变的情况。
还扩展关键字：-asz,表明资源的准确容量的信息。
消息实例：
网关向传感器发送资源发现的请求：
REQ:GET/.well-known/core---发送请求到默认的URI，即根目录获取资源列表
传感器向网关发送资源的响应：
RES:200OK--响应标识获取成功，并携带了2组资源指示信息
</sensors/temp>；ct＝41；n＝"TemperatureC",--温度资源，内容类型41，名称为TemperatureC
</sensors/light>；ct＝41；n＝"LightLux"--灯光资源，内容类型41，名称为LightLux
</sensors/firmware>；ct＝52；n＝"firmware"；asz＝65000；snapshot＝0--固件资源，内容类型52，名称为firmware，非动态资源，精确容量为65000字节；
</sensors/log>；ct＝52；n＝"log"；asz＝88000；snapshot＝1--固件资源，内容类型52，名称为log，动态资源，当前数据为快照snapshot，其精确容量为88000字节；
此响应消息是封装在CoAP消息的消息体中的，接收方(即网关)根据Link-format标准中的规定进行解析。
(2)增加状态码
在收到网关的数据资源获取请求时，如果资源太大，一个包传送不下，传感器用状态码来通知网关，用于表明，资源太大，需要用Block Option来请求。
比如，可以规定状态码413，用于表明当前数据资源容量过大，指示网关在请求中用Block选项。可以根据需要规定其他的状态码，以用于表示其他含义，用于其它目的。
消息实例：
网关向传感器发送资源获取的请求：
GET/sensordata
传感器向网关发送带状态码的响应：
ACK 413(状态码，表明数据资源容量太大)
(3)在CoAP的头字段(Header)中增加一个表明容量(Size)的选项(Option)
网关在请求中，可以用容量选项(Size Option)来指示传感器，让传感器返回数据资源的容量；传感器在响应中，用Size Option来指明数据资源的容量。
或者是，即使网关没有Size Option的指示，传感器也在响应中用Size Option指明资源容量，尤其是资源比较大的情况下，传感器应该指示。
如果资源较小，传感器直接在消息体(Body)中返回资源数据，则网关应该以资源数据的实际容量为准，Size Option中表明的资源容量可以用于核对。
如果资源较大，传感器不返回资源数据，只用Size Option返回数据的容量，同时用状态码指示给网关，让网关发起新的请求，用Block Option来请求。
Size Option的代码可以为16，数据类型为整型，数据长度为1～4个字节，数据单位为字节。Size Option主要用于<Get>方法的响应中，<Put>/<Post>方法的请求中，用于表示资源的容量；如果是在<Get>方法的请求中，其值没有实际的意义，推荐置为0。
消息实例：
网关向传感器发送资源获取的请求：
GET/sensordata
传感器向网关发送带状态码的响应：
ACK+413+Size 51200(50K字节)
以下结合图3说明如图1所示实施例的具体实现过程。图3表示的是网关向传感器发送数据的说明性示例，仅为说明本发明的构思，而不作为对本发明的限制。
当网关使用<Get>方法获取第一个分片(Block)数据时，NUM字段被设置为0，并携带推荐的分片容量(即SZX)，传感器可以选择同意推荐的分片容量，或是选择一个小于等于推荐的分片容量的分片容量，并在响应中返回，同时，在响应中返回第一个分片的分片数据。因此，在NUM字段为0时，<Get>请求有双重语义，一是获取第一个分片数据，二是进行分片容量的协商。这样带来协议在处理上的二义性，而且无法携带数据容量等信息。
本发明实施例对此进行了改进，在本发明的一种实施例中，网关在<Get>方法的请求中使用Block Option时，如果NUM字段被设置为0，表示双方只进行分片容量的协商，以及分片总数的协商。即传感器在响应中，使用NUM字段返回分片总数，使用SZX字段返回传感器确定的分片容量。M字段可以去掉，节省一个Bit，用于NUM字段。因为请求方，例如网关知道分片总数，所以从分片的NUM字段就可以知道该分片是否是最后一个分片，因此就不需要再使用M字段。在这种情况下，如果请求获取第一个分片的分片数据，则将NUM设置为1，依次类推。
需要说明的是，如果网关发送第一个请求时，不知道数据资源的容量，所以BlockOption可以使用一个字节，如果传感器的数据资源较大，分片数目较大，则传感器可以在响应中使用二个字节或者三个字节来返回分片总数。
当Block Option为2个字节时，其设计成SZX字段占用第二个字节的最后三位，表示分片容量；NUM字段占用第一个字节加上第二个字节的前5位，表示当前分片序号；如果是在NUM为0的请求对应的响应消息中，则表示分片总数。本领域技术人员理解，可以用消息标识(Message ID)来关联请求与响应，即请求和响应中都携带唯一的事务标识，这样传感器就能理解此响应消息是用于返回分片总数。
以下举例说明分片容量协商过程，消息实例为：
网关向传感器发送资源获取的请求：
GET 00000 101(NUM为0，SZX为101，即5，表示分片容量为2的9次方，即512)
传感器向网关发送的响应：
ACK 10000 100(NUM为:10000，即总分片数为32，SZX为100，即4，表示分片容量为2的8次方，即256)
此设计省掉了一个比特位(Bit)，即把M位给省掉了，技术优势是节省了数据流量并且对现有设计的改动不大。在这种实施方式中，分片容量(SZX)字段每次仍然要发送。
在现有技术中，分片容量(即SZX字段)每次都要发送，不管是在请求消息中还是响应消息中，除了第一个分片和最后一个分片中使用的分片容量可能不一样之外，其他的分片容量全部都是一样的。重复互相传输相同的NUM字段浪费了传输资源。
在本发明实施例中，网关在<Get>方法的请求中使用Block Option时，如果NUM被设置为0，表示双方只进行分片容量的协商，以及分片总数的协商。即传感器在响应中，使用NUM字段返回总的分片数，使用SZX字段返回传感器确定的分片容量。并且网关和传感器双方存储所确定的分片容量，用于之后的分片数据传输消息。除了最后一个分片数据之外。网关在后续<Get>方法的请求中，只发送所请求的当前分片序号，而不发送已经确定并保持不变的分片容量，而且传感器在响应消息中，也只发送当前的分片序号和与该分片序号对应的分片数据，不再发送分片容量。在这种情况下，NUM为1时，表示请求第一个分片的分片数据，依次类推。
以采用<GET>命令从传感器获取数据资源为例，说明上述实施例，
如图3所示，新的Block Option的设计如下：
其中结构(1)用于NUM为0的情况：
在<Get>请求中，NUM为0，SZX是第二个字节，表示分片容量，Total Number表示分片总数，在请求时不使用，不需要携带；在<Get>响应中，NUM为0，SZX表示传感器确定的分片容量，Total Number表示分片总数。
在现有技术中，分片容量的间隔比较大，比如2048、1024、512，不够灵活。而实际上，512对于一个Block来说，比较小，最好是刚好能够放到一个UDP包里，即1472个字节。本发明对此进行了改进，在一种实施例中，对于SZX，可以采取新的公式，比如：(SZX+1)*8,则其范围可以为：8～2048，但是递减间隔为8。
图3中的结构(2)和结构(3)用于<Get>请求中NUM不为0的情况，即获取分片数据时的情况：
当NUM小于256时，用一个字节来表示分片序号，即结构(2)；当NUM大于2的8次方(即256)，小于2的16次方(即65536)时，使用两个字节来表示分片序号，即结构(3)。
由于结构(2)中的NUM必须大于0，结构(3)中的NUM字段的前一个字节也大于0，因此可以与结构(1)区分开，对于<Get>响应，NUM字段的值与请求中一样，也可以区分开。
以下举例说明，消息实例为：
网关向传感器发送资源获取的请求：
GET 00000000 00000101(NUM为0，SZX为101，即5，表示分片容量为2的9次方，即512)
传感器向网关发送的响应：
ACK 00000000 00000100 00000000 00010000(NUM为0，Total Number为10000，即分片总数为32，SZX为100，即4，表示分片容量为2的8次方，即256)。
通过对Block Option重新设计，可以在每个请求或响应中至少减少发送4个比特位，在分片较多的情况下，可以极大地提高传输效率，节省传输资源，同时也提高了网关和传感器双方的处理效率。
图4示出了本发明的一种替代实施例。在图4所示实施例中，ES410至ES420与图2所示实施例的ES210至ES240相同，不再重复描述。
在图4所示实施例中，在ES450，网关向传感器发送<GET>请求，使用分片选项进行分片容量协商，指示网关推荐的分片容量。在ES460中，传感器选择并确定合适的分片容量，用于将资源进行分片，并将所有分片数据主动推送给网关，而不需要网关再发<GET>请求。
在图4实施例获取数据资源过程中，分片选项的设计如图5所示，其中：
结构(1)用于网关向传感器发送<GET>请求，SZX字段表示网关推荐的分片容量，传感器最终选择并确定的分片容量小于等于网关推荐的分片容量，NUM为0表示网关请求完整资源，NUM不为0表示网关请求具体第NUM个分片数据，NUM不为0时传感器只能使用SZX字段所指示的分片容量。
结构(2)和结构(3)用于传感器向网关返回完整资源的分片响应消息，如果针对某个具体分片数据请求的应答，不需要携带分片选项，结构(2)和(3)中的M字段表示是否为最后一个分片，如果是M字段为0则表示最后一个分片，为1表示不是最后一个分片，NUM字段表示传感器所返回的是第几个分片。
以下举例说明。消息实例为：
网关向传感器发送数据资源获取的请求：
CON GET 00000000 00000101(NUM为0，SZX为101，即5，表示分片容量为2的9次方，即512)
传感器向网关发送的响应：
ACK 200 00000011(NUM为1，M为1，表示发送的第一个分片，并且不是最后一个分片，分片容量为SZX字段指定的容量)；
传感器继续向网关发送CoAP响应：
CON 200 00000101(NUM为2，M为1，表示发送的第二个分片，并且不是最后一个分片，分片容量为SZX字段指定的容量)；
网关返回对CON的ACK响应；
传感器向网关发送最后一个分片：
CON 200 00000110(NUM为3，M为0，表示发送的第三个分片，并且是最后一个分片，具体分片容量由实际读出数据算出)。
根据图4所示的实施例，在网关从传感器获取完整的数据资源时，仅需完成分片容量的协商，而不用发送大量的分片数据获取请求，大大节省了数据传输流量。
图6示出了本发明的另一种替代实施例。在图6所示实施例中，ES610至ES640与图2所示实施例的ES210至ES240相同，因此不再重复描述。
图6与图2所示实施例不同之处在于，在ES650，网关向传感器发送<GET>请求，请求获取资源，使用分片选项，指示网关推荐的分片容量，此时NUM字段填充的值为0，表示请求获取最后一个分片；在ES660，传感器响应网关请求，返回确定的分片容量以及最后一个分片的序号及与之对应的分片数据。由于最后一个分片序号对应分片总数，所以在ES670，网关就可以依次或者并发获取其他分片数据的请求。在ES680，传感器根据确定的分片容量，返回该分片的序号及对应的分片数据。ES670和ES680可以多次进行交互，直至分片数据传输完毕。
图6实施例中采用的分片选项如图7所示，例如采用两个字节的分片选项，仅包括NUM字段和SZX字段。
以下结合图6和图7举例说明，消息实例为：
网关向传感器发送资源获取的请求：
CON GET 00000000 00000101(NUM为0，表示要求获取最后一个分片，SZX为101，即5，表示推荐的分片容量为2的9次方，即512)。
传感器向网关发送的响应：
ACK 00000000 01000101(NUM为1000即为8，表示返回的是第8个分片，SZX为101即5，表示确定的分片容量为2的9次方，即512)；
根据第一次的返回信息，网关已经知道了一共有8个分片，并且得到了第8个分片的数据，网关继续向传感器发送CoAP请求，可以依次获取也可以并发获取剩下的分片数据。以下消息实例为请求获取第一个分片的分片数据：
CON GET 00000000 00001101(NUM为1，表示要求获取第一个分片，SZX为101，即5，表示分片容量为2的9次方，即512)；
传感器返回对CON的ACK响应，即第一个分片的数据；
网关可以依次或并发请求所有剩余分片，直到获取完所有的数据。
根据图6所示的实施例，可以在分片容量协商的同时，获取最后一个分片的分片数据，在后续分片数据获取过程中，所使用的分片容量均相同，因此可以结合前述优选实施例的描述，网关可以在发送获取分片数据的请求时，不再发送SZX字段，而仅发送NUM字段，由此可以节省数据流量，提高传输效率。
图8示出了使用分片选项向传感器发送数据，例如使用资源创建(Post)或更新(Put)请求时的实施例。以下结合图8进行具体描述。
图8所示详细的流程说明如下：
ES810：网关向传感器发送资源创建(Post)或更新(Put)请求消息，利用Size选项发送资源的容量信息，利用分片选项指示推荐的分片容量及分片总数，此处所述的分片总数是基于推荐的分片容量和待发送的数据资源的容量计算出的，请求消息体中不携带具体的资源数据。
ES820：传感器如果愿意接收此数据，则返回状态码例如为100(即指示客户端继续发送)，同时向网关返回确定的分片容量，所述确定的分片容量只能小于或等于网关推荐的分片容量；如果传感器不愿意接收此数据，则返回错误码指示客户端不要继续发送数据。比如，传感器的存储容量不足以存储所指示的资源容量的数据，则返回413“Request EntityToo Large”的返回码。
ES830：网关根据传感器返回的确定的分片容量，判断是否与推荐的分片容量相同，如果相同，则跳转到ES360；如果不相同，则根据传感器返回的确定的分片容量信息，并根据数据资源容量，重新计算分片总数。
ES840：网关重新向传感器发送确定的分片容量和重新计算的分片总数。
ES850：传感器返回确定的分片容量。
ES860：网关从根据分片序号从1一直到分片总数，依次向传感器发送与分片序号对应的数据资源的分片数据，直到完全传输完毕。
ES870：传感器返回确定接收的消息，其中包含接收到的分片序号。
根据本发明的一种优选实施例，ES860中可以进行并行处理，即网关可以同时向传感器发送多个分片数据，而不需要等待传感器返回对前一个分片消息的响应消息。可选地，根据本发明的一种优选实施例，网关和传感器在消息交互中，增加认证信息。认证消息的配置和交互方式可以采用参照图2所述的相同方式。
为了提高传输效率，节省数据流量，根据本发明另一种优选实施例，如前面针对<GET>方法所述地那样，在使用<Put>/<Post>方法的请求中，当NUM为0是，不再是发送第一个分片数据，而是告知传感器推荐的分片的容量和分片总数。传感器可以返回响应告知网关是否继续发送数据。传感器在响应中，使用NUM字段返回总的分片数，使用SZX字段返回传感器确定的分片容量。并且网关和传感器双方存储所确定的分片容量，用于之后的分片数据传输消息。除了最后一个分片数据之外。网关在后续<Put>/<Post>方法的请求中，只发送所请求的当前分片序号，而不发送已经确定并保持不变的分片容量，而且传感器在响应消息中，也只发送当前的分片序号和与该分片序号对应的分片数据，不再发送分片容量。在这种情况下，NUM为1时，表示请求第一个分片的分片数据，依次类推。
在此情况下，分片选项的设计以及使用方式均类似于图3所示，以下参照图3来说明。在<Put>/<Post>请求中，NUM字段为0，SZX字段是第二个字节，表示推荐的分片容量，Total Number表示待发送的分片总数数；在<Put>/<Post>响应中，NUM字段为0，SZX字段表示传感器确定的分片容量，Total Number没用，不需要携带；如果网关接收到的SZX字段与发送的不一致，需要用新的SZX再次发送<Put>/<Post>请求，并携带重新计算的分片总数，传感器再发回响应。以后<Put>/<Post>请求和响应中，不再携带SZX字段。
通过对分片选项重新设计，可以在每个请求或响应中至少减少发送4个比特位，在分片较多的情况下，可以极大地提高传输效率，节省传输资源，同时也提高了网关和传感器双方的处理效率。
另外，现有技术在每次分片传输的请求中，都需要携带所请求资源的统一资源标识(URI，Unified Resource Identifier)，通常URI都要占十几到几十个字节，重复的传输会浪费传输资源，本发明设计使用Token(令牌)来关联分片传输的多个请求，只在第一个分片消息中传送URI，在后续的分片传输请求中，只需要携带Token即可，由于Token通常是1～8个字节，因此可以节省一定的流量。
图9是本发明一种通过分片传输数据资源的客户端设备的实施例。图9所示客户端设备900包括：获取单元910，用于获取数据资源容量信息；发送单元920，用于发送携带分片选项的请求消息，其中所述分片选项包括推荐的分片容量，接收单元930，接收携带分片选项的响应消息，其中所述分片选项包括确定的分片容量；和传输单元940，用于根据所述确定的分片容量以及所述数据资源容量信息，分片传输所述数据资源。
根据本发明的一种优选实施例，所述客户端设备可以进一步包括存储单元950，用于保存所述确定的分片容量。以便在数据资源传输过程中，不需要每次均发送SZX字段。
根据本发明的另一种优选实施例，所述客户端设备可以进一步包括认证单元960，用于发送和接收认证信息。
图10是本发明一种通过分片传输数据资源的服务器设备的实施例。图10所示服务器设备1000包括：接收单元1010，用于接收携带分片选项的请求消息，其中所述分片选项包括推荐的分片容量；发送单元1020，用于发送携带分片选项的响应消息，其中所述分片选项包括确定的分片容量；和传输单元1030，用于根据所述确定的分片容量，分片传输所述数据资源。
根据本发明一种实施例，发送单元1020还用于发送携带数据资源容量信息的消息，以便于传输单元1030根据所述确定的分片容量和所述数据资源容量信息，分片传输所述数据资源。
根据本发明一种实施例，在接收到一次请求时，传输单元1030可以主动地分片传输数据，而不需要客户端设备针对每个分片数据进行请求。
根据本发明一种优选实施例，所述服务器设备可以进一步包括存储单元1040，用于保存所述确定的分片容量。以便在数据资源传输过程中，不需要每次均发送SZX字段。
根据本发明的另一种优选实施例，所述服务器设备可以进一步包括认证单元1050，用于发送和接收认证信息。
根据本发明实施例，网关可以获知目标资源的容量信息，用于决策是否用分片的方式来获取资源，这样避免了出错的可能性，也可以实现并发地请求分片，提高数据请求的效率，而且得知资源的容量也便于分配存储空间，计算分片的数量。
通过对分片选项重新设计，可以在每个请求或响应中至少少发送4个比特位，在分片较多的情况下，可以极大地提高传输效率，节省传输资源，同时也提高了双方的处理效率。
在现有技术中，在收到来自于客户端的请求后，服务器可以立即发回响应，也可以先发回一个Ack(Acknowledgement)响应消息，表明接收到了请求消息，正在处理中，后续等处理完后，再发送响应消息，即推迟的响应。另外，客户端可以订阅一个资源的改变，服务器在接受客户端对某个资源的订阅后，一旦资源信息发生变化，就向客户端发回通知消息。
现有技术不能满足如下的需求：
1、客户端在请求中指示服务器，自己需要哪种方式的响应；
2、客户端要求服务器在某个规定的时间内发回响应；
3、在通知消息的传送过程中，由于网络传输能力不稳定，可能服务器先发出的通知消息，比服务器后发出的消息，到达客户端的时间要晚。这样，客户端后收到的资源信息实际上是陈旧的信息，客户端需要有一种机制能够探测多个通知消息的顺序。
图11是本发明一种实施例的流程图。在图11所示实施例中，在S1110，客户端向服务器发送请求消息，该请求消息携带响应方式选项，所述响应方式选项可以是推迟响应(Deferred Response)选项或者是令牌(Token)选项，用来指示服务器，客户端是否接收推迟的响应。例如，所述响应方式选项表示：一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推迟的多个响应。如果响应方式选项不携带，默认为一次性响应，服务器可以确定是采用一次性的立即响应或是推迟的一次性响应。然后，在S1120，客户端可以接收服务器发送的根据响应方式选项生成的响应消息。
在现有技术中，在收到来自于客户端的请求后，服务器可以立即发回响应，也可以先发回一个Ack，表明接收到了请求消息，正在处理中，后续等处理完后，再发送响应消息，即推迟的响应。另外，客户端可以订阅一个资源的改变，服务器在接受客户端对某个资源的订阅后，一旦资源信息发生变化，就向客户端发回通知消息。
在本发明的一种实施例中，例如可以采用一个字节的延迟(Deferred)选项来指示响应方式，其中，可以使用前两个比特位(Bit)来表示，用C来表示：
C＝00:表示一次性的立即响应；
C＝01:表示推迟的一次性的响应；
C＝10：表示推迟的多个响应，即订阅；
C＝11：表示取消推迟的多个响应，即取消订阅。
对于客户端发起的关于某个资源的订阅，可以由客户端取消订阅，也可以服务器取消订阅，比如服务器发回给客户端一个需要确认的响应消息，客户端在预定的时间内未能确认，则服务器可以认为客户端失去连接，从而取消订阅。
由于一个字节是8个比特位，多余的后6个比特位(假设其值为T)可以用于表示推迟的一次性的响应的推迟时间或者推迟的多个响应的截止时间，即超过此时间后，自动取消订阅。当C为01时，T表示推迟的一次性响应的推迟时间；当C为10时，T表示推迟的多个响应的截止时间；当T为00或11时，T没有意义，置为0。
对于这6个比特位，可以表示0～63之间的数值，假设为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秒。
在现有技术中，Max_Age字段用于表明某个响应可以被缓存的最大时间，即表明响应的新鲜度。本发明扩展这一字段的含义，可以在请求中用Max_Age字段表示多个响应之间的时间间隔的限制，比如多个通知消息不得高于此时间间隔，或者是不得低于此时间间隔。
对于多个响应的顺序，可以用消息标识(Message ID)来区分。比如，规定消息标识必须根据通响应的顺序来递增地生成，接收方根据消息标识的大小来判断响应的先后顺序。
根据本发明的另一种实施例，可以使用Token(令牌)选项来指示响应方式，如果Token值为0，来表示立即的响应，如果Token值不为0，则表示可以接受推迟的响应。
根据本发明的另一种实施例，可以替代地或另外增加时间戳(Timestamp)选项，与延迟选项单独或者相结合地来指示响应方式。具体来说，客户端可以在请求中携带时间戳选项，所述时间戳选项包括一个截止时间的值，要求服务器在指定的时间内返回响应；服务器在响应消息中，携带时间戳选项，表明响应消息生成的时间，这样，客户端可以基于时间戳选项来判断响应消息的顺序。
在本发明一种实施例中，所述时间戳选项的设计方案可以用1～6个字节来表示，如果表示的时间短，则用一个字节，如果时间长，则用3个字节或6个字节。具体表示方法例如以下两种：
(1)用年、月、日、时、分、秒来表示，第一个字节表示年、第二个字节表示月，第三个字节表示日，第四个字节表示小时，第五个字节表示分钟，第六个字节表示秒，对于年份，例如可以以2000年为基础，其值表明2000年之后的第几年，比如为0时，表明是2000年，为1时，表明是2001年，最多可以表示2063年。
(2)三个字节全部用秒来表示，最大可表示2^24-1秒，大约是136年。
由此，客户端可以知道返回的响应消息的顺序，避免数据传输延迟导致的错误。
与图11所示的实施例对应，图12是从服务器侧来看，本发明实施例的方法的流程图。本发明实施例的方法包括：
S1210：接收客户端发送的携带响应方式选项的请求消息；
S1220：向客户端发送根据所述响应方式选项生成的响应消息。
下面结合具体的实施例进一步阐述本发明实施例的方案。
实施例1：
在步骤S1110中发送的所述请求消息中，所述响应方式选项为推迟的一次性的响应或者一次性的立即响应，并且所述请求消息还携带消息类型指示信息和延迟时间选项。这里的消息类型指示信息指示所述请求消息为多播请求，并且延迟时间选项用于指示多个服务器在所述延迟时间选项所指示的时间内，任意选择一个时间向客户端发送响应消息，以避免多个服务器同时发回响应给客户端，造成网络拥塞，而且客户端也来不及处理。例如，在所述延迟时间选项所指示的时间内，多个服务器各自经过随机延时后，再向客户端发送响应消息。
例如，某个大楼管理员利用控制台(多播网关)发送向整个大楼的多个电灯控制器(服务器)发送开灯的指令(多播请求)，要求各个电灯控制器在5秒钟内发回响应以表明是否已经开灯，则各个电灯控制器在5秒钟内分别经过随机延时后，向控制台发回响应，表明是否已经开灯。
为了通知服务器所述请求消息为多播请求，这里所述的消息类型指示信息例如可以是预设的用于发送多播请求的套接字端口；或者预设的用于发送所述多播请求的网络协议IP地址；或者预设的用于发送多播请求的端口号；或者所述请求消息中的消息类型指示选项。例如，
1)服务器打开一个特定的套接字(Socket)端口，并设置为网络协议(InternetProtocol，简称IP)多播接收，则客户端通过该特定的Socket端口向服务器发送所述请求消息，以表示所述请求消息为多播请求；
2)客户端在所述请求消息中携带预设的IP地址，例如FF00::/8的IPv6的前缀，服务器接收到请求消息后，检查接收包的IP地址，如果该IP地址为预设的IP地址，则表示该请求消息是多播请求，否则是单播请求；
3)客户端通过预设的用于发送多播请求的端口号来发送所述请求消息，例如：coap://用于单播请求，coapm://用于多播请求，则服务器可以根据接收的请求消息的端口号来确定所述请求消息是单播请求还是多播请求。
4)客户端在请求消息中用消息类型指示选项字段来表明此请求是单播请求还是多播请求，服务器根据此字段来判断。
根据本发明实施例，上述过程也适用于所述请求消息为单播请求的场景。
服务器的行为在单播和多播场景下有所不同，主要区别是，对于单播请求，超时后，服务器放弃发回响应给客户端；对于多播请求，超时后，服务器还是会发回响应给客户端，虽然响应超时了，但由于不是所有的服务器都超时，所以不会造成拥塞问题。
根据本发明实施例，所述请求消息还包括截止时间选项，以指示服务器在该截止时间选项所指示的时间内返回响应消息。由此，客户端可以在所述截止时间选项指示的时间超时之前，接收服务器发送的响应消息。
实施例2：
在步骤S1110中发送的请求消息中，响应方式选项为推迟的多个响应，即表示客户端订阅(Observe)服务器的数据。在这种情况下，服务器向客户端发送通知响应消息。根据本发明实施例，通知响应消息携带最长存续时间(Max-Age)选项和留候时间(Patience)选项，其中Max-Age选项用于表明资源的值的最长有效时间；所述Patience选项用于指示服务器将在Max－Age过期后，在所述Patience选项所指示的时间内作出响应。在资源的值没有改变的情况下，服务器可以用此Patience选项，来延迟响应消息的发送。在这种情况下，客户端可以用此来判断，在Max-Age过期后，服务器将尽量在Patience时间到期前，发送通知响应给客户端。因此，客户端可以在Max-Age过期后，继续保持与所述服务器的订阅关系，保持时间为所述Patience选项所指示的时间。这样可以避免客户端在Max－Age过期后，重新向服务器发送请求消息。
实施例3：
在步骤S1110中发送的所述请求消息中，所述响应方式选项为推迟的多个响应，表示客户端订阅(Observe)服务器的数据。在这种情况下，客户端向服务器发送的所述请求消息中包括保持时间(Keep Alive)选项。客户端可以根据情况设置Keep Alive选项的取值，比如在本例中可以设置为1000秒。服务器收到该请求消息后，向客户端回复确认(Acknowledgement，简称ACK)消息，其中携带当前订阅资源的最新取值，同时获取KeepAlive选项，并在此时开启一个定时器，其值为Keep Alive设置的取值。
在Keep Alive选项所述指示的时间内，如果客户端订阅的资源在服务器上发生变化，则服务器向客户端发送第三通知响应，即客户端接收服务器发送的第三通知响应，该所述第三通知响应为不需要确认型消息。
当按Keep-Alive指示的时间超时之后，服务器向客户端发送第四通知响应，即客户端接收服务器发送的第四通知响应，其中所述第四通知响应为需要确认型消息。然后服务器等待客户端返回ACK消息。当服务器收到来自客户端的ACK消息后，则说明客户端运行正常。然后可以重复上面的过程，服务器重新开启定时器，通过不需要确认型消息向客户端发送响应消息。
如果在一定时间内服务器没有收到客户端的ACK消息，则服务器将重新发送上述第四通知响应。如果重发次数到达预设的次数阈值时，服务器还是没有收到客户端的返回的ACK消息，则服务器停止重发，同时也停止同客户端的订阅关系。
图13是实施例3的实现过程的消息交互图。图13中的各个消息如下：
ES1310：客户端向服务器发送订阅请求，其中携带Keep Alive选项；
ES1320:服务器向客户端回复ACK消息，其中携带当前订阅资源的最新取值，开启定时器；
ES1330：当服务器上订阅的资源发生变化时，该服务器向客户端发送通知响应，该通知响应为不需要确认型消息；
ES1340：当定时器超时后，服务器采用需要确认型消息发送通知响应，并等待客户端返回的ACK消息；
ES1350：客户端服务器返回一个ACK消息；
ES1360：服务器收到来自客户端的ACK消息，重新开启定时器；
ES1370：当服务器上订阅的资源发生变化时，该服务器向客户端发送通知响应，该通知响应为不需要确认型消息；
ES1380：当定时器超时后，服务器采用需要确认型消息发送通知响应，并等待客户端返回的ACK消息；
ES1390：服务器在一定时间内没有收到客户端的ACK消息，服务器将重新发送上述通知响应，当重发次数到达最大，服务器还是没有收到客户端的ACK消息，则服务器停止重发，同时也停止同客户端的订阅关系。
ES1310至ES1390的代码例如为：
REQ:GET/resource-URI/observe＝0/keep-alive＝1000---发送请求到需要订阅的资源的URI，携带订阅标示observe选项和Keep Alive选项；
RES:ACK/payload---先回复ACK响应，在payload里携带资源最新的数据；
RES:NON/payload---当资源有更新时，服务器采用非确认的消息回复通知响应；
RES:CON/payload---过了Keep Alive选项设置的定时器后，服务器采用需要确认型消息回复通知响应；
REQ:ACK/---客户端回复ACK消息
RES:NON/payload---当资源有更新时，服务器采用非确认的消息回复通知响应；
RES:CON/payload---过了Keep Alive选项设置的定时器后，服务器采用确认的消息回复通知响应；
RES:CON/payload---在一定时间内没有收到客户端的ACK消息，重新发送上述消息；
根据本发明实施例，Keep Alive选项可以定义为可选选项，即如果CoAP服务器不支持该选项，可以无视该选项，按没有该选项处理收到的请求。
根据本发明实施例，该Keep Alive选项的取值是整数型的，大小可以是变长的。根据具体需要，其大小可以是4bit(比特)，或8个bit，或12bit，甚至更大，本发明实施例并不限制其具体的取值范围。
实施例4：
在实际应用中，服务器因为拥塞等原因而导致高负荷时，根据服务器设备的配置策略，为了防止后续信令处理等操作导致服务器设备彻底瘫痪，服务器设备在此时间点上开启拥塞控制，即在接下来的一定时间内，不再处理收到的任何新的请求消息。
考虑本发明实施例在这种场景中的应用。例如，在步骤S1110中，客户端向服务器发送请求消息，其中所述响应方式选项为推迟的一次性的响应或一次性的立即响应，且所述请求消息还包括消息类型指示信息和截止时间选项，其中所述消息类型指示信息指示所述请求消息为单播请求，所述请求消息为需要确认型消息。本领域技术人员可以理解，如果服务器收到的是不需要确认型请求消息，则直接将消息忽略，不回复任何响应。如果此时服务器发生拥塞并开启了拥塞控制，则在步骤S1120中，服务器向所述客户端发送特定ACK消息，其中所述特定的确认消息携带响应代码和延迟接入时间选项，其中所述响应代码例如为5.03“service unavailable”(服务不可用)响应代码，用于表示服务器在所述截止时间选项所指示的时间内无法返回针对所述请求消息的响应。或者服务器可以先向所述客户端发送ACK消息，接着向所述客户端发送响应消息，其中所述响应消息携带响应代码和延迟接入时间选项，其中所述响应代码表示所述服务器在所述截止时间选项所指示的时间内无法返回针对所述请求消息的响应。
延迟接入时间选项的值代表了延迟接入的具体时间，单位例如是秒，最大值例如为2N秒，超过该最大值的值例如被服务器按照默认值2M秒来处理。如果此选项值为零时或者此选项没有出现在响应消息中时，则客户端无需执行额外操作，可在任意时间尝试向服务器再次发出请求。根据本发明实施例，延迟接入时间选项为可选类型，即无法被CoAP客户端识别时会直接被忽略。
图14是实施例4的消息交互图。如图所示，
E1400：服务器开启拥塞控制；
E1402：客户端向所述服务器发送需要确认型请求消息；
E1404：服务器向客户端发送ACK消息，该ACK消息包含延迟接入选项(新)、响应代码以及空的负载
E1404：客户端立即清除缓存的等待向所述服务器发送的其他请求消息。
E1406：在延迟接入时间选项所指示的时间内，向服务器发送请求消息；
E1408：服务器将该请求消息忽略；
E1410：等待延迟接入时间选项所指示的时间；
E1412：服务器负荷恢复正常；
E1414：客户端向服务器重新发送所述请求消息；
E1416：服务器返回正常ACK消息。
由于CoAP协议的版本不同，实际投入使用的CoAP客户端可能没有及时升级，以至于无法识别所述延迟接入选项。因此即使在E1404，带有延迟接入时间选项的ACK发送到了客户端，由于客户端版本较老无法识别延迟接入时间选项，该客户端设备将会忽略该选项(也有可能是其他异常情况导致)，并且可能在接下来的任意时间，在E1406再次尝试发送请求消息至已经遭遇拥塞的服务器设备。服务器设备可以根据配置的策略，忽略该请求消息，或再次发送带有新的延迟接入时间选项的响应消息，该新的延迟接入时间选项的取值可以小于先前已经发送的延迟接入时间选项的取值。
需要说明的是，本实施例中为了方便解释，都使用了Piggy-backed(附带式)的响应消息，即各选项夹带在ACK消息中直接传输。根据本发明实施例，也可以使用分离式的响应，即确认消息和响应消息分两次发送，延迟接入选项总是属于响应消息的一部分。
实施例5：
与服务器侧发生拥塞类似，客户端也可能因为某种原因发生拥塞而导致高负荷。当客户端由于拥塞等原因而导致高负荷时，根据客户端的配置策略，为了防止后续信令处理等操作导致客户端彻底瘫痪，客户端在此时间点上开启拥塞控制，即在接下来的一定时间内，不再处理收到的任何新的请求消息。
考虑本发明实施例在这种场景中的应用。例如，在步骤S1110中，客户端向服务器发送所述请求消息，其中所述响应方式选项为推迟的多个响应，即客户端订阅服务器上的资源信息。然后，在步骤S1120中，客户端收到服务器发送的响应消息，例如在所订阅的资源在服务器上发生了变化的情况下，服务器向客户端发送需要确认型响应消息，其中携带最新的资源信息。如果此时客户端开启了拥塞控制，则会向服务器发送特定的ACK消息，所述特定的确认消息携带响应代码和延迟接入时间选项，其中所述响应代码表示所述客户端在所述延迟接入时间选项所指示的时间内无法返回针对所述响应消息的确认。或者客户端可以先向所述服务器发送ACK消息，接着向所述客户端发送特定的响应消息，其中所述特定的响应消息携带响应代码和延迟接入时间选项，其中所述响应代码表示所述客户端在所述延迟接入时间选项所指示的时间内无法返回针对所述需要确认型响应消息的确认。在客户端开启拥塞控制的情况下，如果在步骤S1120中客户端接收到的是不需要确认型响应消息，则客户端将该消息直接忽略，不回复任何确认消息。
如上所述，延迟接入时间选项的值代表了延迟接入的具体时间，单位例如是秒，最大值例如为2N秒，超过该最大值的值例如被客户端按照默认值2M秒来处理。如果此选项值为零时或者此选项没有出现在响应消息中时，则服务器无需执行额外操作，可在任意时间尝试向客户端再次发出需要确认形响应消息。根据本发明实施例，延迟接入时间选项为可选类型，即无法被CoAP服务器识别时会直接被忽略。
服务器收到上述特定的ACK消息后，如果能够识别消息中的延迟接入时间选项，则暂停所有的与所述客户端之间的订阅推送，开始等待，即等待所述客户端恢复正常。
在延迟接入时间选项所指示的时间经过之后，客户端恢复正常，服务器的等待计时也已结束，因此服务器向客户端设备重发需要确认的响应消息，负载恢复正常的客户端此时会回复一个正常的确认消息。
图15是实施例5中的消息交互图。如图16所示，
ES1500：客户端向服务器发送订阅请求；
ES1502：服务器向客户端发送需要确认的响应消息；
ES1504：客户端向服务器发送ACK消息；
ES1506：客户端开启拥塞控制；
ES1508：服务器向客户端发送需要确认的响应消息；
ES1510：客户端向服务器发送携带相应代码和延迟接入时间选项的特定的ACK消息；
ES1512：服务器暂停向服务器推送订阅的资源；
ES1514：服务器等待延迟接入时间选项所指示的时间；
ES1516：客户端负荷恢复正常；
ES1518：服务器向客户端重新发送需要确认的响应消息；
ES1520：客户端向服务器发送ACK消息。
值得说明的是，正常情况下，客户端设备收到服务器设备推送的需要确认的请求消息后，都回复的是ACK确认消息，只有当客户端需要向服务器通知延迟接入时才会用piggybacked的方式携带具体响应内容或者分开传送ACK和响应。
根据本发明实施例，通过在消息交互过程中指定响应方式选项，客户端可以指定所需的响应，提高了CoAP的消息交互效率。
实施例6：
本实施例描述了服务器和客户端进行交互的流程：
1、客户端向服务器发送请求，其中携带超时选项，并指示此请求是单播请求或是多播请求，是资源订阅请求或是一次性请求；
2、服务器根据接收到的请求进行判断，如果该请求是一次性请求，则服务器继续判断是单播请求还是多播请求：
A.如果该请求是单播一次性请求，服务器预先判断自己是否能够在超时选项指定的时间内完成客户端的请求，如果预测不能完成，则发回一个状态码(比如5.04,Timeout，超时)给客户端，表明不能在预定时间内完成客户端的请求；可选地，服务器预测自身空闲的时间，或是自身可以完成客户端的请求的时间，并把这个预测时间在响应中发回给客户端，指示客户端在指定的预测时间之后，再次发送请求；如果服务器能够在指定的超时时间内完成请求，则在超时时间过期前，发回响应。
B.如果该请求是多播一次性请求，服务器在指定的时间内任意选择一个时间，返回响应给客户端。
3、如果服务器判断客户端的请求是订阅请求，服务器继续判断该请求中携带的超时时间是Patience选项，还是Keep-alive选项：
A.如果请求中携带的是Patience选项，则表明服务器需要在指定时间内发回第一个通知消息；服务器在通知消息中携带资源的信息，以及Max-Age选项和Patience时间选项，要求客户端在指定时间内保持与服务器资源的订阅状态。
B.如果请求中携带的是Keep-alive时间选项，服务器在Keep-alive时间内，使用Non-confirmable消息的方式，给客户端发送通知消息；在Keep-alive时间过期后，使用Confirmable消息的方式，给客户端发送通知消息。
图16是根据本发明的一种传输数据资源的客户端设备的实施例的框图，其中所述客户端设备1600包括：发送模块1610，用于发送携带响应方式选项的请求消息；和接收模块1620，用于接收根据所述响应方式选项生成的响应消息。
参照图11所述的本发明的实施例所描述的过程和特征均适用于图16所示的客户端设备。具体来说，例如，发送模块1610发送的请求消息中携带的响应方式选项可以是推迟选项，例如可以为：一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推迟的多个响应。
根据一种实施例，发送模块1610发送的请求消息中携带的响应方式选项可以表示推迟的一次性的响应的推迟时间或者推迟的多个响应的截止时间。
根据一种实施例，发送模块1610发送携带时间戳选项的请求消息，该时间戳表示接收响应的截止时间；接收模块1620接收携带时间戳选项的响应消息，该时间戳表示响应消息的生成时间。接收模块1620根据接收到的响应消息中的时间戳所表示的时间确定响应消息的顺序。
根据本发明实施例，在所述请求消息中，所述响应方式选项为推迟的一次性的响应或一次性的立即响应，
所述请求消息还携带消息类型指示信息和延迟时间选项，其中所述消息类型指示信息指示所述请求消息为多播请求或单播请求；
所述接收模块1620用于在所述延迟时间选项指示的时间内，接收服务器发送的响应消息。
根据本发明实施例，所述请求消息还包括截止时间选项，
所述接收模块1620用于在所述截止时间选项指示的时间超时之前，接收服务器发送的响应消息。
根据本发明实施例，在所述请求消息中，所述响应方式选项为推迟的多个响应，
所述接收模块1620用于接收所述服务器发送的通知响应消息，其中所述通知响应消息携带最长存续时间选项和留候时间选项，其中所述留候时间选项用于指示，
在所述最长存续时间选项所指示时间超时之后，所述客户端保持与所述服务器的订阅关系，保持时间为所述留候选项所指示的时间。
根据本发明实施例，在所述请求消息中，所述响应方式选项为推迟的多个响应，所述请求消息还包括保持时间选项，所述接收模块1620用于在所述保持时间选项指示的时间内，接收服务器发送的第一通知响应，其中所述第一通知响应为不需要确认型消息；在所述保持时间选项指示的时间超时之后，所述接收模块1620用于接收所述服务器发送的第二通知响应，其中所述第二通知响应为需要确认型消息，所述发送模块1610用于向所述服务器发送确认ACK消息。
根据本发明实施例，在所述请求消息中，所述响应方式选项为推迟的一次性的响应或一次性的立即响应，所述请求消息还包括消息类型指示信息和截止时间选项，其中所述消息类型指示信息指示所述请求消息为单播请求，所述请求消息为需要确认型消息；
所述接收模块1620用于接收所述服务器发送的特定的确认消息，其中所述特定的确认消息携带响应代码和延迟接入时间选项，其中所述响应代码表示所述服务器在所述截止时间选项所指示的时间内无法返回针对所述请求消息的响应；
或者
所述接收模块1620用于接收所述服务器发送的确认消息；
并用于接收所述服务器发送的特定的响应消息，其中所述特定的响应消息携带响应代码和延迟接入时间选项，其中所述响应代码表示所述服务器在所述截止时间选项所指示的时间内无法返回针对所述请求消息的响应。
根据本发明实施例，所述接收模块1620还用于清除缓存的等待向所述服务器发送的其他请求消息。
根据本发明实施例，在所述延迟接入时间选项所指示的时间之后，所述发送模块1610还用于重新向所述服务器发送所述请求消息。
根据本发明实施例，在所述请求消息中，所述响应方式选项为推迟的多个响应，所述接收服务器发送的根据所述响应方式选项生成的响应消息是需要确认型消息，
所述发送模块1610还用于向所述服务器发送特定的确认消息，其中所述特定的确认消息携带响应代码和延迟接入时间选项，其中所述响应代码表示客户端在所述延迟接入时间选项所指示的时间内无法返回针对所述响应消息的确认；
或者
所述发送模块1610用于向所述服务器发送确认消息；
并用于向所述服务器发送特定的响应消息，其中所述特定的响应消息携带响应代码和延迟接入时间选项，其中所述响应代码表示所述客户端在所述延迟接入时间选项所指示的时间内无法返回针对所述响应消息的确认。
根据本发明实施例，所述响应消息包括响应消息生成时间，所述接收模块1220还用于根据所述响应消息生成时间确定响应消息的顺序。
图17是根据本发明的一种传输数据资源的服务器设备的实施例，其中所述服务器设备1700包括：接收模块1710，用于接收客户端发送的携带响应方式选项的请求消息；和发送模块1720，向客户端发送根据所述响应方式选项生成的响应消息。
参照图12所述的本发明的实施例所描述的过程和特征均适用于图17所示的服务器设备。具体来说，例如，接收模块1710接收的请求消息中携带的响应方式选项可以是推迟选项，例如可以为：一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推迟的多个响应。
根据本发明实施例，在所述请求消息中，所述响应方式选项为推迟的一次性的响应或一次性的立即响应，所述请求消息还包括消息类型指示信息和延迟时间选项，其中所述消息类型指示信息指示所述请求消息为多播请求或单播请求；所述发送模块1720用于在所述延迟时间选项指示的时间内，经过随机延时之后，向所述客户端发送响应消息。
根据本发明实施例，所述请求消息还包括截止时间选项，所述发送模块1720用于在所述截止时间选项指示的时间超时之前，向所述客户端发送响应消息。
根据本发明实施例，在所述请求消息中，所述响应方式选项为推迟的多个响应，
所述发送模块1720用于向所述客户端发送通知响应，其中所述通知响应携带最长存续时间选项和留候时间选项，其中所述留候时间选项用于指示，
在所述最长存续时间选项所指示的时间超时之后，所述服务器将在所述留候时间选项所指示的时间内作出响应。
根据本发明实施例，在所述请求消息中，所述响应方式选项为推迟的多个响应，所述请求消息还包括保持时间选项，所述发送模块1720用于在所述保持时间选项指示的时间内，向所述客户端发送第三通知响应，其中所述第三通知响应为不需要确认型消息；所述发送模块1720还用于在所述保持时间选项指示的时间超时之后，向所述客户端发送第四通知响应，其中所述第四通知响应为需要确认型消息；所述接收模块1710用于接收所述客户端发送的ACK消息。
根据本发明实施例，在所述请求消息中，所述响应方式选项为推迟的一次性的响应或一次性的立即响应，所述请求消息还包括消息类型指示信息和截止时间选项，其中所述消息类型指示信息指示所述请求消息为单播请求，所述请求消息为需要确认型消息；
所述发送模块1720用于向客户端发送特定的确认消息，其中所述特定的确认消息携带响应代码和延迟接入时间选项，其中所述响应代码表示所述服务器在所述截止时间选项所指示的时间内无法返回针对所述请求消息的响应；
或者
所述发送模块1720用于向客户端发送确认消息；
并用于向客户端发送特定的响应消息，其中所述特定的响应消息携带响应代码和延迟接入时间选项，其中所述响应代码表示所述服务器在所述截止时间选项所指示的时间内无法返回针对所述请求消息的响应。
根据本发明实施例，在所述延迟接入时间选项所指示的时间之后，所述接收模块1710用于接收所述客户端重新发送的所述请求消息。
根据本发明实施例，在所述请求消息中，所述响应方式选项为推迟的多个响应，所述向客户端发送的根据所述响应方式选项生成的响应消息是需要确认型消息，所述接收模块1710用于接收所述客户端发送的特定的确认消息，其中所述特定的确认消息携带响应代码和延迟接入时间选项，其中所述响应代码表示所述客户端在所述延迟接入时间选项所指示的时间内无法返回针对所述响应消息的确认；
或者
所述接收模块1710用于接收所述客户端发送的确认消息；
并用于接收所述客户端发送特定的响应消息，其中所述特定的响应消息携带响应代码和延迟接入时间选项，其中所述响应代码表示所述客户端在所述延迟接入时间选项所指示的时间内无法返回针对所述响应消息的确认。
根据本发明实施例，在所述延迟接入时间选项所指示的时间超时后，所述发送模块1720用于向所述客户端重新发送所述需要确认型响应消息。
根据本发明的另一种实施例，接收模块1710接收的请求消息中可以携带时间戳选项，该时间戳选项表示接收响应的截止时间，而发送模块1320发送的响应消息中也可以携带时间戳选项，所述时间戳选项表示响应消息的生成时间。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
尽管已示出和描述了本发明的一些实施例，但本领域技术人员应理解，在不脱离本发明的原理和精神的情况下，可对这些实施例进行各种修改，这样的修改应落入本发明的范围内。

Claims (14)

1.一种M2M系统中的资源传输的方法，其特征在于，包括：
客户端向服务器发送请求消息，所述请求消息中包含第一时间戳选项，所述第一时间戳选项包含一个截止时间值，用于指示所述服务器在所述截止时间值指定的时间内向所述客户端返回响应消息；
所述客户端在所述截止时间指示的时间超时之前，接收所述服务器发送的响应消息。
2.如权利要求1所述的方法，其特征在于，所述客户端接收的响应消息包括第二时间戳选项，所述第二时间戳选项包含所述响应消息的生成时间。
3.如权利要求1或2所述的方法，其特征在于，所述客户端发送的请求消息还携带响应类型，用以指示所述服务器根据所述响应类型向所述客户端发送响应消息。
4.如权利要求3所述的方法，其特征在于，所述响应类型包括推迟响应。
5.如权利要求4所述的方法，其特征在于，所述客户端还接收所述服务器根据所述推迟响应返回的确认消息(Ack),所述确认消息用以告知所述客户端，服务器接收到了请求消息，正在处理中，后续处理完后，再向所述客户端发送响应消息。
6.如权利要求4所述的方法，其特征在于，在所述请求消息中，所述响应类型为推迟的多个响应，所述客户端还用于接收所述服务器发送的根据所述响应类型生成的通知响应消息，其中所述通知响应消息携带最长存续时间选项和留候时间选项，其中所述留候时间选项用于指示，在所述最长存续时间选项所指示时间超时之后，客户端保持与所述服务器的订阅关系，保持时间为所述留候选项所指示的时间。
7.一种M2M系统中的数据资源传输的方法，其特征在于，包括：
服务器接收客户端发送的请求消息，所述请求消息中包含第一时间戳选项，所述第一时间戳选项包含一个截止时间值，用于指示所述服务器在所述截止时间值指定的时间内向所述客户端返回响应消息；
所述服务器在所述截止时间指示的时间超时之前，向所述客户端返回响应消息。
8.如权利要求7所述的方法，其特征在于，所述服务器返回的响应消息包括第二时间戳选项，所述第二时间戳选项包含所述响应消息的生成时间。
9.如权利要求7或8所述的方法，其特征在于，所述服务器接收的请求消息还携带响应类型，用以指示所述服务器根据所述响应类型向所述客户端发送响应消息。
10.如权利要求9所述的方法，其特征在于，所述响应类型包括推迟响应。
11.如权利要求10所述的方法，其特征在于，所述服务器还根据所述推迟响应类型向所述客户端返回确认消息(Ack)，所述确认消息用以告知所述客户端，服务器接收到了请求消息，正在处理中，后续处理完后，再向所述客户端发送响应消息。
12.如权利要求9所述的方法，其特征在于，所述服务器接收的所述请求消息中，所述响应类型为推迟的多个响应，所述服务器还根据所述响应类型向所述客户端返回通知响应消息，其中所述通知响应消息携带最长存续时间选项和留候时间选项，其中所述留候时间选项用于指示，在所述最长存续时间选项所指示时间超时之后，客户端保持与所述服务器的订阅关系，保持时间为所述留候选项所指示的时间。
13.一种客户端，包括：处理器和存储器，其特征在于，所述存储器存储可执行的程序，当其在所述处理器中运行时，用以执行如权利要求1-6任一项所述的消息交互方法。
14.一种服务器，包括：处理器和存储器，其特征在于，所述存储器存储可执行的程序，当其在所述处理器中运行时，用以执行如权利要求7-12任一项所述的消息交互方法。
CN201710132014.2A 2011-03-17 2012-03-06 数据资源传输的方法和设备 Active CN107071826B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN2011100645493A CN102130954A (zh) 2011-03-17 2011-03-17 数据资源传输的方法和设备
CN2011100645493 2011-03-17
CN201210056456.0A CN102685204B (zh) 2011-03-17 2012-03-06 数据资源传输的方法和设备

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
CN201210056456.0A Division CN102685204B (zh) 2011-03-17 2012-03-06 数据资源传输的方法和设备

Publications (2)

Publication Number Publication Date
CN107071826A true CN107071826A (zh) 2017-08-18
CN107071826B CN107071826B (zh) 2020-07-07

Family

ID=44268843

Family Applications (7)

Application Number Title Priority Date Filing Date
CN2011100645493A Pending CN102130954A (zh) 2011-03-17 2011-03-17 数据资源传输的方法和设备
CN201210054892.4A Active CN102685203B (zh) 2011-03-17 2012-03-02 数据资源传输的方法和设备
CN201710131638.2A Active CN107070990B (zh) 2011-03-17 2012-03-02 数据资源传输的方法和设备
CN201710132013.8A Active CN106850841B (zh) 2011-03-17 2012-03-02 数据资源传输的方法和设备
CN201710131415.6A Active CN106878442B (zh) 2011-03-17 2012-03-06 数据资源传输的方法和设备
CN201710132014.2A Active CN107071826B (zh) 2011-03-17 2012-03-06 数据资源传输的方法和设备
CN201210056456.0A Active CN102685204B (zh) 2011-03-17 2012-03-06 数据资源传输的方法和设备

Family Applications Before (5)

Application Number Title Priority Date Filing Date
CN2011100645493A Pending CN102130954A (zh) 2011-03-17 2011-03-17 数据资源传输的方法和设备
CN201210054892.4A Active CN102685203B (zh) 2011-03-17 2012-03-02 数据资源传输的方法和设备
CN201710131638.2A Active CN107070990B (zh) 2011-03-17 2012-03-02 数据资源传输的方法和设备
CN201710132013.8A Active CN106850841B (zh) 2011-03-17 2012-03-02 数据资源传输的方法和设备
CN201710131415.6A Active CN106878442B (zh) 2011-03-17 2012-03-06 数据资源传输的方法和设备

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN201210056456.0A Active CN102685204B (zh) 2011-03-17 2012-03-06 数据资源传输的方法和设备

Country Status (1)

Country Link
CN (7) CN102130954A (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108900370A (zh) * 2018-06-08 2018-11-27 努比亚技术有限公司 长连接多重超时判断方法、装置及计算机可读存储介质
CN110636551A (zh) * 2018-06-25 2019-12-31 上海华为技术有限公司 避免报文分片的方法和装置
CN110875952A (zh) * 2018-09-04 2020-03-10 中国移动通信有限公司研究院 一种基于物联网的数据响应处理方法及设备、存储介质
CN112187931A (zh) * 2020-09-29 2021-01-05 中国平安财产保险股份有限公司 会话管理方法、装置、计算机设备和存储介质
CN112367387A (zh) * 2020-10-30 2021-02-12 湖北亿咖通科技有限公司 一种车联网通信方法及系统
WO2021126024A1 (en) * 2019-12-17 2021-06-24 Telefonaktiebolaget Lm Ericsson (Publ) Observation of resources by a coap client
CN115103005A (zh) * 2022-06-14 2022-09-23 北京京东乾石科技有限公司 请求响应方法、装置、电子设备及存储介质

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103227803A (zh) * 2012-01-30 2013-07-31 华为技术有限公司 一种物联网资源获取的方法、客户端和物联网资源装置
CN103780483A (zh) * 2012-10-26 2014-05-07 中兴通讯股份有限公司 一种物联网终端设备的资源信息获取方法、系统及设备
CN103428273B (zh) * 2013-07-18 2016-12-28 北京百度网讯科技有限公司 在异步式交互中进行响应询问的方法与装置
WO2015070441A1 (zh) * 2013-11-15 2015-05-21 华为技术有限公司 M2m网络及应用、通用业务实体、信息回复方法
CN104468594B (zh) * 2014-12-15 2018-04-27 北京奇安信科技有限公司 一种数据请求的方法、装置及系统
CN104580396B (zh) * 2014-12-19 2018-07-20 华为技术有限公司 一种任务调度方法、节点及系统
WO2016178623A1 (en) * 2015-05-04 2016-11-10 Telefonaktiebolaget Lm Ericsson (Publ) Delayed response to requesting device
CN106658348A (zh) * 2015-10-28 2017-05-10 西安中兴新软件有限责任公司 监控资源管理的方法、装置和cse
CN106817314B (zh) * 2015-12-02 2020-03-20 中国电信股份有限公司 大数据采集方法、装置以及系统
CN105868029A (zh) * 2015-12-11 2016-08-17 鼎点视讯科技有限公司 一种一致性容错处理方法和系统
CN107222450A (zh) * 2016-03-21 2017-09-29 中兴通讯股份有限公司 一种网络节点及实现网络节点间通信的方法和装置
CN106303059A (zh) * 2016-08-24 2017-01-04 努比亚技术有限公司 电子设备及信息处理方法
CN106331117B (zh) * 2016-08-26 2019-05-03 中国科学技术大学 一种数据传输方法
CN106790603A (zh) * 2016-12-29 2017-05-31 东软集团股份有限公司 消息交互的方法、装置及系统
US10191825B2 (en) * 2017-03-01 2019-01-29 Wipro Limited System and method for testing a device using a light weight device validation protocol
CN107105035A (zh) * 2017-04-24 2017-08-29 常州信息职业技术学院 一种智能家居监控装置及监控系统
CN108809858B (zh) * 2017-04-28 2020-11-10 华为技术有限公司 网络拥塞控制方法、设备及系统
CN109586855A (zh) * 2017-09-29 2019-04-05 西安中兴新软件有限责任公司 一种车载设备数据传输方法和装置
CN109729039B (zh) * 2017-10-27 2022-05-13 中兴通讯股份有限公司 链路管理协议的协商分片方法与装置
CN107864135A (zh) * 2017-11-07 2018-03-30 山东网智物联网科技有限公司 物联网通信方法、装置及物联网通信的实现装置
CN109936588B (zh) * 2017-12-15 2021-08-31 华为技术有限公司 一种物联网数据传输方法、设备及系统
CN108599904B (zh) * 2018-03-21 2021-09-28 中兴通讯股份有限公司 一种数据传输方法及装置
CN108834110B (zh) * 2018-05-30 2021-05-25 上海顺舟智能科技股份有限公司 zigbee网络的数据传输控制方法及系统
CN110881021B (zh) * 2018-09-06 2022-06-03 中国移动通信有限公司研究院 Msrp分片的处理方法及装置、网络设备及存储介质
CN109787884B (zh) * 2019-01-02 2021-03-12 中国联合网络通信集团有限公司 一种消息推送方法和装置
KR102622252B1 (ko) * 2019-05-27 2024-01-08 삼성에스디에스 주식회사 콘텐츠 전송 장치 및 방법
CN111083161A (zh) * 2019-12-27 2020-04-28 中消云（北京）物联网科技研究院有限公司 数据传输的处理方法及装置、物联网设备
CN111259371B (zh) * 2020-01-13 2023-08-18 平安科技（深圳）有限公司 物联网设备认证方法、电子装置及存储介质
CN112541788B (zh) * 2020-12-11 2023-11-17 江西蔚乐科技有限公司 基于coap协议的广告请求方法
CN114125746B (zh) * 2021-11-19 2022-08-16 山东华科信息技术有限公司 基于UCB的动态CoAP模式选择方法及设备
CN114363831B (zh) * 2021-12-02 2023-05-26 北京万集科技股份有限公司 传输v2x消息的方法、设备以及计算机可读存储介质
CN114884913A (zh) * 2022-01-10 2022-08-09 中国移动通信有限公司研究院 消息交互方法、装置、电子设备、消息服务器及存储介质

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1157034C (zh) * 1999-06-18 2004-07-07 艾利森电话股份有限公司 使用压缩头标和时间戳字段传送数据分组的系统和方法
WO2006020934A2 (en) * 2004-08-13 2006-02-23 Conexant Systems, Inc. Systems and methods for decreasing latency in a digital transmission system
US7239648B1 (en) * 2001-11-27 2007-07-03 Marvell International Ltd. Extension mode for wireless lans complying with short interframe space requirement
CN101217402A (zh) * 2008-01-15 2008-07-09 杭州华三通信技术有限公司 一种提高集群可靠性的方法和一种高可靠性通信节点
EP1949584A2 (en) * 2005-10-28 2008-07-30 ViaSat, Inc. Adaptive coding and modulation for broadband data transmission
JP2008271312A (ja) * 2007-04-23 2008-11-06 Matsushita Electric Ind Co Ltd 無線パケット通信装置
CN101741701A (zh) * 2008-11-12 2010-06-16 中兴通讯股份有限公司 同步调度方法和装置
CN101867882A (zh) * 2009-04-14 2010-10-20 中兴通讯股份有限公司 消息发送及消息反馈预处理方法
CN101945427A (zh) * 2009-07-03 2011-01-12 深圳市融创天下科技发展有限公司 一种高效的流媒体传输方法
CN107113091A (zh) * 2014-12-19 2017-08-29 高通股份有限公司 用于实现即时应答的传输技术

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5909542A (en) * 1996-11-20 1999-06-01 Cfi Proservices, Inc. Distributed computing system for executing intercommunicating applications programs
US20030202487A1 (en) * 2002-04-26 2003-10-30 Harris John M. Method and apparatus for reducing call setup time
US9886309B2 (en) * 2002-06-28 2018-02-06 Microsoft Technology Licensing, Llc Identity-based distributed computing for device resources
KR20040087161A (ko) * 2003-04-04 2004-10-13 엘지전자 주식회사 이동 통신 단말기의 파일 용량 관리 방법
CN100349088C (zh) * 2005-07-26 2007-11-14 华为技术有限公司 一种数字信息控制方法和终端
CN1905518B (zh) * 2005-07-29 2010-12-01 北京航空航天大学 保证数据交换可靠传输的方法
CN100461673C (zh) * 2005-12-02 2009-02-11 华为技术有限公司 一种数据包交互方法及个人域网络通信设备
CN100490380C (zh) * 2005-12-26 2009-05-20 北大方正集团有限公司 轻量级分布式文件存储系统文件上传的方法
CN101155054A (zh) * 2006-09-28 2008-04-02 华为技术有限公司 自治系统域间pce路径自动探测和计算的方法和装置
US20080275808A1 (en) * 2007-05-01 2008-11-06 Instinet Europe Limited Anonymous block trade matching system
CN101335742B (zh) * 2007-06-25 2011-09-21 中兴通讯股份有限公司 一种轻量级目录访问协议下访问目录的系统及方法
CN101102282A (zh) * 2007-08-08 2008-01-09 中兴通讯股份有限公司 一种数据广播业务发送和接收方法
CN101374020B (zh) * 2007-08-20 2012-11-14 中兴通讯股份有限公司 一种中继网络中的集中式带宽分配方法
CN101150506B (zh) * 2007-08-24 2011-07-06 华为技术有限公司 内容获取方法、装置和内容传输系统
CN101471992B (zh) * 2007-12-24 2012-05-09 联想(北京)有限公司 一种移动终端、接收或推送业务信息的方法和推送服务器
CN101222395B (zh) * 2008-02-03 2010-10-27 华为技术有限公司 实现选择网络引导配置信息的方法、系统及装置
CN101635703A (zh) * 2008-07-24 2010-01-27 北京启明星辰信息技术股份有限公司 一种web服务异常检测方法
CN101729593A (zh) * 2008-11-03 2010-06-09 北大方正集团有限公司 一种上传和接收文件的方法、系统及装置
WO2010137844A2 (ko) * 2009-05-25 2010-12-02 엘지전자 주식회사 대역폭 요청 수행 방법 및 이를 위한 단말 장치
CN101635744B (zh) * 2009-08-26 2012-08-29 华为技术有限公司 一种数据传输方法及数据传输系统以及相关设备
CN101789958B (zh) * 2009-12-30 2013-06-05 中兴通讯股份有限公司 一种基于设备管理业务的数据同步方法、系统及设备

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1157034C (zh) * 1999-06-18 2004-07-07 艾利森电话股份有限公司 使用压缩头标和时间戳字段传送数据分组的系统和方法
US7239648B1 (en) * 2001-11-27 2007-07-03 Marvell International Ltd. Extension mode for wireless lans complying with short interframe space requirement
WO2006020934A2 (en) * 2004-08-13 2006-02-23 Conexant Systems, Inc. Systems and methods for decreasing latency in a digital transmission system
EP1949584A2 (en) * 2005-10-28 2008-07-30 ViaSat, Inc. Adaptive coding and modulation for broadband data transmission
EP1949584B1 (en) * 2005-10-28 2019-03-06 ViaSat, Inc. Adaptive coding and modulation for broadband data transmission
JP2008271312A (ja) * 2007-04-23 2008-11-06 Matsushita Electric Ind Co Ltd 無線パケット通信装置
CN101217402A (zh) * 2008-01-15 2008-07-09 杭州华三通信技术有限公司 一种提高集群可靠性的方法和一种高可靠性通信节点
CN101741701A (zh) * 2008-11-12 2010-06-16 中兴通讯股份有限公司 同步调度方法和装置
CN101867882A (zh) * 2009-04-14 2010-10-20 中兴通讯股份有限公司 消息发送及消息反馈预处理方法
CN101945427A (zh) * 2009-07-03 2011-01-12 深圳市融创天下科技发展有限公司 一种高效的流媒体传输方法
CN107113091A (zh) * 2014-12-19 2017-08-29 高通股份有限公司 用于实现即时应答的传输技术

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108900370A (zh) * 2018-06-08 2018-11-27 努比亚技术有限公司 长连接多重超时判断方法、装置及计算机可读存储介质
CN108900370B (zh) * 2018-06-08 2021-12-17 努比亚技术有限公司 长连接多重超时判断方法、装置及计算机可读存储介质
CN110636551A (zh) * 2018-06-25 2019-12-31 上海华为技术有限公司 避免报文分片的方法和装置
WO2020001355A1 (zh) * 2018-06-25 2020-01-02 华为技术有限公司 避免报文分片的方法和装置
CN110636551B (zh) * 2018-06-25 2022-05-17 上海华为技术有限公司 避免报文分片的方法和装置
US11394656B2 (en) 2018-06-25 2022-07-19 Huawei Technologies Co., Ltd. Method and apparatus for avoiding packet fragmentation
CN110875952A (zh) * 2018-09-04 2020-03-10 中国移动通信有限公司研究院 一种基于物联网的数据响应处理方法及设备、存储介质
WO2021126024A1 (en) * 2019-12-17 2021-06-24 Telefonaktiebolaget Lm Ericsson (Publ) Observation of resources by a coap client
CN112187931A (zh) * 2020-09-29 2021-01-05 中国平安财产保险股份有限公司 会话管理方法、装置、计算机设备和存储介质
CN112367387A (zh) * 2020-10-30 2021-02-12 湖北亿咖通科技有限公司 一种车联网通信方法及系统
CN115103005A (zh) * 2022-06-14 2022-09-23 北京京东乾石科技有限公司 请求响应方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
CN106850841B (zh) 2020-11-17
CN102685204A (zh) 2012-09-19
CN107071826B (zh) 2020-07-07
CN102130954A (zh) 2011-07-20
CN107070990B (zh) 2021-04-09
CN107070990A (zh) 2017-08-18
CN106850841A (zh) 2017-06-13
CN106878442A (zh) 2017-06-20
CN102685203B (zh) 2017-07-07
CN102685203A (zh) 2012-09-19
CN106878442B (zh) 2020-12-04
CN102685204B (zh) 2017-04-26

Similar Documents

Publication Publication Date Title
CN102685204B (zh) 数据资源传输的方法和设备
US11064330B2 (en) Methods for enabling delay-awareness in the constrained application protocol (CoAP)
KR100781911B1 (ko) 웹 페이지 다운로딩
US10498831B2 (en) Communication sessions at a CoAP protocol layer
Lindgren et al. Probabilistic routing protocol for intermittently connected networks
US10708885B2 (en) Methods and nodes for enabling context-awareness in CoAP
CN109412946B (zh) 一种确定回源路径的方法、装置、服务器及可读存储介质
US20020133615A1 (en) Nack suppression for multicast protocols in mostly one-way networks
CN103384181B (zh) 数据包的传输方法和设备
US10623145B2 (en) Network node, wireless device and methods performed thereby for the network node to provide information to the wireless device
CN107995233B (zh) 建立连接的方法及相应的设备
Herrero Analysis of the constrained application protocol over quick UDP internet connection transport
EP3576371B1 (en) Method and system for transmitting streaming media resource
CN113992307A (zh) 数据报文的传输方法、装置、电子设备及计算机存储介质
WO2015106524A1 (zh) 业务套餐使用情况的通知/发送方法及装置、服务器
CN116032998A (zh) 数据传输方法、装置、计算机可读存储介质及电子设备
Chakravarthi et al. M2M Communication Protocols
KR100921491B1 (ko) 링형 통신망에서 손실없는 메시지 전송방법
CN116016396A (zh) 一种重发报文的处理方法、处理装置、处理设备及介质
CN116418892A (zh) 基于udp的数据安全传输方法及系统
CN114640729A (zh) 一种通信方法、通信设备及计算机可读存储介质
CN117812165A (zh) 一种行情跨区域传输方法、装置、设备及存储介质
CN107637051A (zh) 在下层支持分组查询响应事务
Ergin et al. ONE: Adaptive One-to-N Error Recovery in Wireless Sensor Networks

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant