WO2012167659A1 - 受限应用协议中数据通信的方法和装置 - Google Patents

受限应用协议中数据通信的方法和装置 Download PDF

Info

Publication number
WO2012167659A1
WO2012167659A1 PCT/CN2012/073539 CN2012073539W WO2012167659A1 WO 2012167659 A1 WO2012167659 A1 WO 2012167659A1 CN 2012073539 W CN2012073539 W CN 2012073539W WO 2012167659 A1 WO2012167659 A1 WO 2012167659A1
Authority
WO
WIPO (PCT)
Prior art keywords
option information
request
via option
proxy node
response
Prior art date
Application number
PCT/CN2012/073539
Other languages
English (en)
French (fr)
Inventor
陈显锋
卞永刚
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2012167659A1 publication Critical patent/WO2012167659A1/zh

Links

Classifications

    • 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
    • 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
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network

Definitions

  • CoAP Constrained Application Protocol
  • M2M machine to machine
  • the functions of these machines are relatively simple.
  • the general processor has only 8 bits, the storage space is small, the complex transmission protocol is not supported, and the data transmission rate is also low.
  • CoAP provides a request/response interaction model that supports embedded resource discovery, including key web page concepts such as the Unique Resources Identifier (URI) and content type.
  • URI Unique Resources Identifier
  • CoAP nodes can be used as a proxy node. Agent functions are always supported on nodes between subnets and associated nodes on restricted networks and external networks.
  • the CoAP supports subscription. If the subscription request initiated by the terminal passes through the proxy node, the proxy node needs to save the state relationship between the session between the terminal and the proxy node and the session with the proxy node. During the subscription process, the proxy node needs to record the address of the terminal, the token option information between the terminal and the proxy node, the address of the server, the token option information between the proxy node and the server.
  • the proxy node needs to process the session state and record session related data, and the proxy node usually serves many CoAP terminals and servers, the proxy nodes are different.
  • the proxy node that stores multiple session states and records session-related data is processed faster than the proxy node that stores a session state and records session-related data, so the former can handle the same time period.
  • the number of subscriptions is less than the latter.
  • the server storage capacity increases.
  • the performance of the server as a proxy node is limited.
  • the increase in the storage capacity reduces the number of subscriptions that can be simultaneously stored. , causing communication delay or failure to send.
  • An aspect of the present invention provides a method for data communication in a restricted application protocol CoAP, the method comprising: receiving a request sent by a terminal; and performing the request according to whether a proxy node stores a parameter and a state of a session corresponding to the request.
  • the path records the processing of the Via option information, wherein the Via option information is used to record the request path and the response route; the processed request is sent.
  • Another aspect of the present invention provides a method for data communication in a restricted application protocol CoAP, the method comprising: generating a request carrying Via option information, and the Via option information is used to record a request path and a response. Routing; sending a request to the proxy node to facilitate processing of the Via option information for the request based on whether the proxy node will store the parameters and status of the session corresponding to the request; and receiving a response based on the request sent by the proxy node.
  • a method for data communication in a restricted application protocol CoAP comprising: receiving a request sent by a proxy node from a terminal; generating a response carrying Via option information based on the request, where the Via option The information is used to record the request path and the response route; send a response to the proxy node, so that the proxy node processes the Via option information according to whether the proxy node has stored the parameter and state of the session corresponding to the request, and sends the response to the terminal. The processed response.
  • An aspect of the present invention provides an apparatus for restricted application protocol CoAP data communication, the apparatus comprising: a receiving module, configured to receive a request sent by a terminal, and a processing module, configured to: according to whether the device will store the request corresponding to the session Parameter and status, processing the request path Via option information, wherein the Via option information is used to record the request path and the response route; and the sending module is configured to send the processed request.
  • a server for data communication in a restricted application protocol CoAP comprising: a receiving module, configured to receive a request sent by a proxy node from a terminal; and a generating module, configured to generate, according to the request a response carrying the Via option information, wherein the Via option information is used to record the request path and the response route; and the sending module is configured to send a response to the proxy node, so that the proxy node stores the parameter of the session corresponding to the request according to whether the proxy node has stored the request And the status, the response of the Via option information is processed, and the processed response is sent to the terminal.
  • FIG. 4 is a schematic diagram of an example of data communication in a restricted application protocol CoAP in accordance with another embodiment of the present invention.
  • FIG. 7 is a schematic diagram of an example of data communication in a restricted application protocol CoAP in accordance with an embodiment of the present invention.
  • 8 is a flow diagram of another method of data communication in a restricted application protocol CoAP in accordance with an embodiment of the present invention.
  • FIG. 9 is a flow diagram of yet another method of data communication in a restricted application protocol CoAP in accordance with an embodiment of the present invention.
  • FIG. 10 is a block diagram of an apparatus for data communication in a restricted application protocol CoAP, in accordance with an embodiment of the present invention.
  • Figure 11 is a block diagram of an apparatus for data communication in a restricted application protocol CoAP in accordance with another embodiment of the present invention.
  • FIG. 12 is a block diagram of a terminal for data communication in a restricted application protocol CoAP, in accordance with an embodiment of the present invention.
  • 13 is a block diagram of a server for data communication in a restricted application protocol CoAP, in accordance with an embodiment of the present invention.
  • FIG. 1 is a flow diagram of a method 100 of data communication in a restricted application protocol CoAP, in accordance with an embodiment of the present invention.
  • the request sent by the terminal may be a request directly from the terminal, or may be a request sent by the terminal sent by the other proxy node. Specifically, the proxy node can directly receive the request sent by the terminal, or can receive the request sent by the terminal from another proxy node.
  • the embodiment of the present invention allows the proxy node to be divided into a stateless proxy node and a stateful proxy node according to whether the proxy node stores the parameters and state of the session corresponding to the current request in the CoAP, and may exist simultaneously on the transmission path of the same session.
  • a session includes requests and responses.
  • the proxy node that stores the parameters and status of the session and the proxy node that stores the parameters and status of the session when processing the response of one session are referred to as stateful agents in the session.
  • the proxy node judges that it will act as a stateful proxy node or a stateless proxy node can be judged by the following method. For example, setting an identifier in a configuration file of the proxy node, the proxy node determining to act as a stateful proxy node or a stateless proxy node by identifying the identifier, and the identifier may be changed by manual configuration, so that the proxy node changes the role; The size of the allocated memory space is determined.
  • the proxy node will act as a stateful proxy, and vice versa as a stateless proxy; how the proxy node determines that it acts as a stateful proxy or a stateless proxy is not
  • the problem solved by the invention is merely exemplified herein.
  • the proxy node When in the session, the proxy node does not store the parameters and status of the session corresponding to the request when processing the request, or when the proxy node processes the response, the proxy node does not store the request corresponding to the response.
  • Session parameter or state ie this proxy node is a stateless proxy node.
  • the stateless proxy node adds Via option information to the request to send a request to the server.
  • the proxy node When in the session, the proxy node will store the parameters and status of the session corresponding to the request when processing the request; or when the proxy node processes the response, the proxy node has stored the request corresponding to the response Session parameter or state, ie this proxy node is a stateful proxy node.
  • the stateful proxy node stores the Via option information in the request and deletes the Via option information in the request.
  • the Via option is used to record the request path and response route.
  • the assignment carried by the Via option is called Via option information.
  • the Via option is defined by the Type Length Value (TLV, Type Length Value) field as shown in Table 1 below.
  • the Via option information as a string can be the address of the Proxy through which the request passes, and can be a URI, an IP address, or a unique device number.
  • the Via option information is routable, that is, according to the assignment and The corresponding device implements communication, and it is known from the above that there is no default value for the Via option.
  • C/E It is one of the attributes of the Via option.
  • C means that the node on the CoAP path must understand the option and handle it accordingly.
  • E means that the node on the CoAP path can not understand the option and does not handle it accordingly.
  • the Via option information when the Via option information includes multiple address information, the Via option information can be implemented in the following two ways.
  • the embodiment of the present invention takes the second implementation as an example, and the newly added address information is sequentially placed on the above.
  • the uppermost address information is referred to as first Via option information
  • the lowermost address information is referred to as second Via option information.
  • the stateless proxy node adds Via option information carrying the address of the proxy node to the request.
  • the stateful proxy node and the stateless proxy node are allowed to exist simultaneously on the transmission path of the same session, and the routing information of the path in the protocol packet is extracted and deleted by the stateful proxy node, and then changed.
  • the routing information of the local storage path is such that the load of the requested Via option information is as small as possible, and the routing information carried in the protocol packet is shortened, thereby improving the efficiency of using the proxy node resource, thereby reducing the consumption of the transmission and reducing the transmission.
  • step 350 is directly executed.
  • the routing information of the path in the protocol packet is deleted by the stateful proxy node, and the routing information of the path in the protocol packet is deleted, and the routing information carried in the protocol packet is shortened. This improves the efficiency of proxy node resource usage and reduces communication delays or interruptions caused by busy or faulty proxy nodes.
  • the terminal or proxy node no longer adds its own address to the Via option information, which is added by the proxy node of the next hop of the path, thereby further reducing the consumption of the transmission resources of the proxy node.
  • a hop in the path is taken as an example.
  • the path can have multiple hops, where the proxy nodes are stateless proxy nodes or stateful proxy nodes, respectively.
  • Adjacent proxy nodes in a multi-hop path may be consecutive stateless proxy nodes, or may be consecutive stateful proxy nodes, or they may alternate. This embodiment of the present invention is not limited thereto.
  • the addresses used by the Via option information of the stateless proxy node and the stateful proxy node are uniform. That is, when the stateless proxy node uses the requested source address as the added Via option information, the stateful proxy node adds the requested source address to the stored Via option information, as shown in example 300. Or when the stateless proxy node uses the address of the proxy node as the Via option information, the stateful proxy node uses the address of the proxy node as the Via option information after deleting the Via option information in the request, as shown in example 200. vice versa.
  • FIG. 4 is a schematic diagram of an example 400 of data communication in a restricted application protocol CoAP, in accordance with another embodiment of the present invention.
  • the proxy node receiving the response can be a stateless proxy node or a stateful proxy node.
  • the response includes information such as token option information, and/or terminal information.
  • the stateful proxy node and the stateless proxy node are allowed to exist simultaneously on the transmission path of the same session, and the routing information of the path in the protocol packet is extracted and deleted by the stateful proxy node, and then changed.
  • the routing information of the local storage path shortens the routing information carried in the protocol packets, thereby improving the efficiency of using the proxy node resources.
  • FIG. 5 is a schematic diagram of an example 500 of data communication in a restricted application protocol CoAP, in accordance with another embodiment of the present invention.
  • FIG. 5 illustrates another embodiment implementation.
  • the server or proxy node Before sending a response, the server or proxy node first sends the top Via option information in the message (the first Via option information). )delete.
  • the proxy node receiving the response can be a stateless proxy node or a stateful proxy node.
  • the proxy node that deletes the top Via option information (first Via option information) in the response may be a stateless proxy node or a stateful proxy node.
  • the proxy node deletes the stored session parameters after the session ends, including the Via option information.
  • the end of the session represents the end of the subscription, and the method for determining the end of the subscription may be to add a validity period to the subscription, or be displayed by the subscriber. End the subscription by answering.
  • the stateful proxy node and the stateless proxy node are allowed to exist simultaneously on the transmission path of the same session, and the routing information of the path in the protocol packet is extracted and deleted by the stateful proxy node, and then changed.
  • the routing information of the local storage path shortens the routing information carried in the protocol packets, thereby improving the efficiency of using the proxy node resources and reducing communication delays or interruptions caused by busy or faulty proxy nodes.
  • the server or proxy node no no longer adds its own address to the Via option information, which is joined by the proxy node at the next hop of the path.
  • the embodiment of Figure 6 is another alternative to the stateful proxy node implementation of the embodiment of Figures 4 and 5.
  • the server or stateful proxy node When the server or stateful proxy node returns a response to the client, it will try to skip the stateless proxy node. Only when the skip fails will the proxy node passing the request be returned in the original path.
  • an attempt flag indicating an attempt is added, with a bit of 1 indicating that the stateless proxy node has been attempted to be skipped, and a 0 indicating that it is attempting to skip the stateless proxy node, where the attempt to identify the bit is attempted.
  • the method is merely an example and may be expressed in any other way.
  • FIG. 6 is a schematic diagram of an example 600 of data communication in a restricted application protocol CoAP, in accordance with another embodiment of the present invention.
  • the response may be sent successfully by an acknowledgment (ACK) response to the acknowledgment request CON;
  • ACK acknowledgment response to the acknowledgment request CON;
  • the use of the attempt flag in the above embodiment is merely an example of an attempt to skip the implementation of the stateless proxy node, and the present invention is not limited thereto.
  • Other implementations may, for example, send a response directly to the device corresponding to the lowest one (second Via option information) in the response by determining that there are multiple Via option information.
  • Fig. 6 The embodiment in Fig. 6 can be applied in the following scenario example. Assume that the proxy node through which the request passes and the session state information stored by each proxy node for the request are:
  • the server When the server processes the return response, it tries to skip the stateless proxy node ProxyE and tries to send the response directly to the ProxyD. Only when the direct transmission fails, it will be sent to the ProxyE, and the ProxyE will forward the response to the ProxyD. The ProxyD also tries to skip the stateless proxy.
  • the node ProxyC directly attempts to send a response to the ProxyB, and only forwards it via the ProxyC when the response is unsuccessful.
  • the stateful proxy node and the stateless proxy node are allowed to exist simultaneously on the transmission path of the same session, and the routing information of the path in the protocol packet is extracted and deleted by the stateful proxy node, and then changed.
  • the routing information of the local storage path is shortened in the protocol packet. The routing information carried, thereby improving the efficiency of the use of the proxy node resources, and reducing the communication delay or interruption caused by the busy or faulty proxy node.
  • FIG. 7 is a schematic diagram of an example of data communication in a restricted application protocol CoAP in accordance with an embodiment of the present invention.
  • ProxyA is a stateless proxy node
  • ProxyB is a stateful proxy node
  • the addresses of Client, ProxyA, ProxyB, and Server are respectively:
  • the URI of the client is: coap: ⁇ clientsensor.example/clientl
  • the communication address is: 192.0.2.2
  • the communication address of ProxyA is: 192.0.2.1
  • ProxyB's mailing address is: 192.1.2.1
  • the URI of the server is: coap ://server. sensor. example/Server 1
  • the ProxyA does not store the parameter and the status of the requested session. It adds the Via option information carrying the address to the request, and places it on the Via option information of the terminal:
  • ProxyB is a stateful proxy node, which first stores the Via option information in the request locally, and then deletes the requested Via option information in step 703 in the request, and adds its own address as the new Via option information:
  • step 706-710 sending a response of the server based on the request of step 701 to the terminal.
  • the server sends an asynchronous notification message to the terminal.
  • the asynchronous notification message can be one of the multiple responses to the current request.
  • the Server first extracts the Via option information and the Token option letter in the request of the obtaining step 705.
  • the message generates a response carrying the Via option information and the Token option information:
  • ProxyB according to the message type (Type): 200 discovery is a response message, according to the Token option information to find the locally stored session information, and extract the previously stored Via option information from the session information.
  • the ProxyA parses the response forwarded from the ProxyB. According to the Token option information, the local session information is not found, and the response is forwarded to the terminal client according to the routing information extracted from the Via option.
  • the response information at this time is:
  • steps 708, 710, 712, 714 and 716 are acknowledgements returned after receiving the response.
  • FIG. 8 is a flow diagram of another method 800 of data communication in a restricted application protocol CoAP in accordance with an embodiment of the present invention. This method is done by the terminal.
  • Via option information is used to record the request path and the response route.
  • the URI of the server is: coap: ⁇
  • the URI of the server.sensor.example/ServerlClient is: coap: ⁇ clientsensor.example/clientl
  • the communication address is: 192.0.2.2, and the Via option information of the own address is generated. Via: 192.0.2.2
  • proxy node through which the request passes and the session state information stored by each proxy node for the request are:
  • the passed stateless proxy node ProxyA does not store the session state of the request, it adds the Via option information carrying its own address in the request, and places it on the Via option information of the terminal:
  • the passed stateful proxy node ProxyB first stores the previous Via option information locally, then deletes the previous Via option information in the request and adds the Via option information with its own address: Via: 192.1.2.1
  • the server first extracts the address carried by the Via option information of the stateful proxy node and the Token option information:
  • the stateful proxy node ProxyB finds the response message according to the message type (Type): 200, finds the locally stored session information according to TokenlD, and extracts the previously stored Via option information from the session information.
  • the stateless proxy node ProxyA resolves the response forwarded from the stateful proxy node ProxyB. According to TokenlD, the corresponding session information is not found locally, and the response is forwarded to the terminal according to the routing information extracted from the Via option.
  • the response information at this time is:
  • the stateful proxy node and the stateless proxy node are allowed to exist simultaneously on the transmission path of the same session, and the routing information of the path in the protocol packet is extracted and deleted by the stateful proxy node, and then changed.
  • the routing information of the local storage path shortens the routing information carried in the protocol packets, thereby improving the efficiency of using the proxy node resources and reducing communication delays or interruptions caused by busy or faulty proxy nodes.
  • FIG. 9 is a flow diagram of yet another method 900 of data communication in a restricted application protocol CoAP in accordance with an embodiment of the present invention. This method is done by the server.
  • method 900 of Figure 9 it includes:
  • the stateless proxy node or stateful proxy node refers to the method of Figure 1 for the method of sending a request to the server.
  • the URI of the client is: coap: ⁇ sensor.
  • the address of the client/client is: 192.0.2.2, which generates the Via option information with its own address.
  • proxy node through which the request passes and the session state information stored by each proxy node for the request are:
  • the passed stateful proxy node ProxyB first stores the previous Via option information locally, then deletes the previous Via option information in the request and adds the Via option information with its own address: Via: 192.1.2.1
  • the server receives the request and stores the Via option information.
  • the server first extracts the address carried by the Via option information of the stateful proxy node ProxyB and
  • the stateful proxy node ProxyB finds the response message according to the message type (Type): 200, finds the locally stored session information according to TokenlD, and extracts the previously stored Via option information from the session information.
  • the stateless proxy node ProxyA resolves the response forwarded from the stateful proxy node ProxyB. According to TokenlD, the corresponding session information is not found locally, and the response is forwarded to the terminal according to the routing information extracted from the Via option.
  • the response information at this time is:
  • the stateful proxy node and the stateless proxy node are allowed to exist simultaneously on the transmission path of the same session, and the routing information of the path in the protocol packet is extracted and deleted by the stateful proxy node, and then changed.
  • the routing information of the local storage path shortens the routing information carried in the protocol packets, thereby improving the efficiency of using the proxy node resources and reducing communication delays or interruptions caused by busy or faulty proxy nodes.
  • FIG. 10 is a block diagram of an apparatus for data communication in a restricted application protocol CoAP, in accordance with an embodiment of the present invention.
  • the apparatus of FIG. 10 may be a proxy node in a CoAP, including a receiving module 1010, a processing module 1020, and a sending module 1030.
  • the receiving module 1010 is configured to receive a request sent by the terminal.
  • the request includes token option information, server address information, and the like.
  • the token option information is used to associate the request with the response, ie the token option information for the request and the corresponding response is the same.
  • the processing module 1020 is configured to perform processing of the Via option information on the request according to whether the device stores the parameters and status of the session corresponding to the request, where the Via option information is used to record the request path and the response route.
  • the sending module 1030 is configured to send the processed request.
  • Embodiments of the present invention allow a proxy node to be divided into a stateless proxy node and a stateful proxy node according to whether the device (proxy node) stores the state and parameters of the session corresponding to the current request in the CoAP, and may be on the transmission path of the same session. simultaneously exist.
  • a session includes requests and responses.
  • the proxy node that stores the parameters and status of the session and the proxy node that stores the parameters and status of the session when processing the response of one session are referred to as stateful agents in the session.
  • a node referred to as a stateful proxy node; similarly, when processing a request for that session
  • a proxy node that does not store the parameters and status of the session and a proxy node that does not store the parameters and status of the session when processing the response of the session is referred to as a stateless proxy node in the session, referred to as a stateless proxy node.
  • the parameters of the session include token option information, Via option information, etc., and the state of the session includes establishment, establishment, and termination. Whether the proxy node is a stateful proxy node or a stateless proxy node is defined for one session.
  • the proxy node judges that it will act as a stateful proxy node or a stateless proxy node can be judged by the following method.
  • the identifier bit is set in the configuration file of the proxy node, and the proxy node determines to act as a stateful proxy node or a stateless proxy node by identifying the identifier bit, and the identifier bit can be changed by manual configuration, so that the proxy node changes the role; It can be determined by the size of the allocated memory space.
  • the proxy node will act as a stateful proxy, and vice versa as a stateless proxy; how the proxy node determines itself to act as a stateful proxy or stateless
  • the agent is not a problem solved by the present invention, and is merely exemplified herein.
  • the stateless proxy node When the stateless proxy node adds Via option information to the request in the session, it sends a request to the server. When in this session, the stateful proxy node stores the Via option information in the request and deletes the Via option information in the request.
  • the processing module 1020 is specifically configured to: when the device does not store the parameter and the status of the session corresponding to the request, add the Via option information to the request; the sending module 1030 is specifically configured to send the added a request for the Via option information; or the processing module 1020 is specifically configured to: when the device stores the parameters and status of the session corresponding to the request, store the Via option information in the request, and delete the Via in the request. Option information; the sending module 1030 is specifically configured to send a request to delete the Via option information.
  • the Via record option referred to as the Via option, is used to record the request path and response route.
  • the assignment carried by the Via option is called Via option information.
  • the Via option is defined by the Type Length Value (TLV, Type Length Value) field as shown in Table 1.
  • the Via option information can be the address of the Proxy through which the request passes, and can be a URI, an IP address, or a unique device number.
  • the Via option information is routable, that is, according to the assignment and The corresponding device implements communication, and it is known from the above that there is no default value for the Via option.
  • C/E is one of the attributes of the Via option.
  • C means that the node on the CoAP path must understand the option and handle it accordingly.
  • E means that the node on the CoAP path can not understand the option and does not handle it accordingly.
  • the Via option information when the Via option information includes multiple address information, the Via option information can be implemented in the following two ways.
  • the newly added address information is placed in the order.
  • the first address information is called the second Via option information
  • the last address information is called the first Via option information.
  • the embodiment of the present invention takes the second implementation as an example, and the newly added address information is sequentially placed on the above.
  • the uppermost address information is referred to as first Via option information
  • the lowermost address information is referred to as second Via option information.
  • the processing module 1020 uses the source address of the request as an increase.
  • the Via option information or if the device is to store parameters and states of the session corresponding to the request, the processing module 1020 adds the source address of the request to the stored Via option information; or
  • the processing module 102 uses the address of the device as the added Via option. Information; or if the device is to store the parameters and status of the session corresponding to the request, the processing module 1020 adds the address of the device to delete the Via option information after deleting the Via option information in the request. After the request.
  • the stateful proxy node and the stateless proxy node are allowed to exist simultaneously on the transmission path of the same session, and the routing information of the path in the protocol packet is extracted and deleted by the stateful proxy node, and then changed.
  • the routing information of the local storage path shortens the routing information carried in the protocol packets, thereby improving the efficiency of using the proxy node resources and reducing communication delays or interruptions caused by busy or faulty proxy nodes.
  • 11 is a block diagram of an apparatus for data communication in a restricted application protocol CoAP, in accordance with another embodiment of the present invention.
  • the receiving module 1101, the processing module 1102, and the sending module 1103 of the device can perform the functions of the receiving module 1010, the processing module 1020, and the sending module 1030 of the device 1000, and can also perform more functions, as shown in the following description.
  • the device further includes a determining module 1104 and a lookup module 1105.
  • the apparatus when the receiving module 1101 receives the request from the terminal (i.e., receives a request directly from the terminal) and when the request uses the source address of the request as Via option information, the apparatus further includes a determining module 1104.
  • the determining module 1104 is configured to: when the first Via option information and the requested source address are inconsistent, modify the first Via option information to the requested source address.
  • the receiving module 1101 is further configured to: receive, by the terminal, a response based on the request from the server, to send the response to the terminal;
  • the sending module 1103 is further configured to delete the first Via option information carried in the response when the device does not store the parameter and the status of the session corresponding to the request. Transmitting, to the device corresponding to the first Via option information in the remaining Via option information, to the device corresponding to the first Via option information in the remaining Via option information; or when the response carries the Via option information, the sending module 1103 is further used to When the device does not store the parameter and status of the session corresponding to the request, deleting the first Via option information in the response, and sending a response that deletes the first Via option information to the first Via The device corresponding to the option information.
  • the device when the response does not carry the Via option information, and the device has stored the parameters and status of the session corresponding to the request, the device further includes a searching module 1105.
  • the searching module 1105 is configured to search, according to the token option information in the response, locally stored Via option information corresponding to the token option information; and the processing module 1102 is further configured to: according to the token option The stored Via option information found by the information is added to the response, and the first Via option information in the added Via option information is deleted; the sending module 1103 is further configured to send a response after deleting the first Via option information to The device corresponding to the first Via option information; or
  • the device When the response carries one of the Via option information, and the device has stored the parameters and status of the session corresponding to the request, the device further includes a lookup module 1105.
  • the searching module 1105 is configured to search, according to the token option information carried in the response, the stored Via option information corresponding to the token option information.
  • the processing module 1102 is further configured to delete the carried in the response. Via option information; adding Via option information corresponding to the token option information found according to the token option information to the response that deletes the Via option information; the sending module 1103 is further configured to join the lookup The response after the Via option information corresponding to the token option information is sent to the device corresponding to the first Via option information in the Via option information corresponding to the token option information.
  • the sending module selects the second Via option information of the stored Via option information as the Via option information of the response, and The response is sent to the device corresponding to the second Via option information.
  • the stateful proxy node and the stateless proxy node are allowed to exist simultaneously on the transmission path of the same session, and the routing information of the path in the protocol packet is deleted by the stateful proxy node, and changed to local.
  • the routing information of the storage path shortens the routing information carried in the protocol packets, thereby improving the efficiency of using the proxy node resources and reducing communication delays or interruptions caused by busy or faulty proxy nodes.
  • Figure 12 is a block diagram of a terminal for data communication in a restricted application protocol CoAP, in accordance with another embodiment of the present invention.
  • the terminal of FIG. 12 performs the functions of a terminal in CoAP, and the terminal includes a generating module 1210 transmitting module 1220 and a receiving module 1230.
  • the generating module 1210 generates a request to carry the path record Via option information, wherein the Via option information is used to record the request path and the response route.
  • the sending module 1220 sends a request to the proxy node, so that the proxy node performs the processing of the Via option information according to whether the proxy node stores the parameter and the state corresponding request of the session corresponding to the current request.
  • the receiving module 1230 receives a response sent by the proxy node based on the request.
  • the terminal implements the method 800.
  • the stateful proxy node and the stateless proxy node are allowed to exist simultaneously on the transmission path of the same session, and the routing information of the path in the protocol packet is extracted and deleted by the stateful proxy node, and then changed.
  • the routing information of the local storage path shortens the routing information carried in the protocol packets, thereby improving the efficiency of using the proxy node resources and reducing communication delays or interruptions caused by busy or faulty proxy nodes.
  • the server includes a receiving module 1310, a generating module 1320, and a sending module 1330.
  • the receiving module 1310 receives the request sent by the proxy node from the terminal.
  • the generating module 1320 generates a response carrying the Via option information based on the request, where the Via option information is used to record the request path and the response route.
  • the sending module 1330 sends a response to the proxy node, so that the proxy node processes the Via option information according to whether the proxy node has stored the parameter and state of the session corresponding to the request, and sends the processed response to the terminal.
  • the server implements the method 900.
  • the stateful proxy node and the stateless proxy node are allowed to exist simultaneously on the transmission path of the same session, and the routing information of the path in the protocol packet is extracted and deleted by the stateful proxy node, and then changed.
  • the routing information of the local storage path shortens the routing information carried in the protocol packets, thereby improving the efficiency of using the proxy node resources and reducing communication delays or interruptions caused by busy or faulty proxy nodes.
  • the CoAP terminal in the foregoing embodiment of the present invention may be a mobile terminal, such as a mobile device such as various mobile phones, notebooks, PDAs, or a fixed terminal, such as a PC.
  • the proxy node in the above embodiment of the present invention may be a network device in a network, or may be a device such as a computer.
  • the server in the above embodiment of the present invention may be a server.
  • the functional modules of the above-mentioned embodiments of the present invention may be functional modules that are executed in the processor of the above device, and the present invention is not limited thereto.
  • modules and algorithm steps of the various examples described in connection with the embodiments disclosed herein can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether such functions are performed in hardware or software depends on the functionality described for the particular application of the technical solution, but such implementation should not be considered to be beyond the scope of the present invention.
  • the disclosed systems, devices, and methods may be implemented in other ways.
  • the device embodiments described above are merely illustrative
  • the division of the modules is only a logical function division, and the actual implementation may have another division manner, for example, multiple modules or components may be combined or may be integrated into another system, or some features may be ignored. Or not.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or module, and may be in an electrical, mechanical or other form.
  • the modules described as separate components may or may not be physically separate.
  • the components displayed as modules may or may not be physical modules, that is, may be located in one place, or may be distributed to multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the objectives of the solution of the embodiment.
  • each functional module in each embodiment of the present invention may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.
  • the functions, if implemented in the form of software functional modules and sold or used as separate products, may be stored in a computer readable storage medium.
  • the technical solution of the present invention which is essential or contributes to the prior art, or a part of the technical solution, may be embodied in the form of a software product, which is stored in a storage medium, including
  • the instructions are used to cause a computer device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present invention.
  • the foregoing storage medium includes: a U disk, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and the like, which can store program codes. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明实施例提供了一种受限应用协议CoAP中数据通信的方法和装置。该方法包括：接收来自终端发送的请求；根据代理节点是否存储该请求对应的会话的参数和状态对该请求进行Via选项信息的处理，其中Via选项信息用于记录请求路径和响应路由；发送经处理后的请求。通过上述方案，能够实现无状态代理，允许有状态代理节点和无状态代理节点可以在同一会话的传输路径上同时存在，并且通过有状态代理节点将协议报文中的路径的路由信息提取后删除，改为本地存储路径的路由信息，缩短协议报文中携带的路由信息，由此提高代理节点资源使用的效率，减少了代理节点繁忙或故障时引起的通信延误或中断。

Description

受限应用协议中数据通信的方法和装置
本申请要求于 2011年 07月 14日提交中国专利局、 申请号为 201110197032.1、 发明名称为 "受限应用协议中数据通信的方法和装置" 的中 国专利申请的优先权， 其全部内容通过引用结合在本申请中。
技术领域
本发明涉及数据通信领域， 并且更具体地， 涉及受限应用协议 CoAP中数 据通信的方法和装置。 背景技术
受限应用协议 CoAP ( Constrained Application Protocol )主要是用于 M2M (机器对机器）的场景中， 比如： 家庭控制器、 楼宇自动化、 智能能源、 传感 器网络等。 在这样的环境中， 这些机器的功能比较简单， 一般处理器只有 8位， 存储空间小， 不支持复杂的传输协议， 数据传输速率也较低。 CoAP提供一种 请求 /响应的交互模式， 支持内嵌的资源发现， 包括关键的网页概念， 比如统 一资源标识符（ Unique Resources Identifier, 简称 URI )和内容类型。
CoAP基于用户数据报协议 ( User Datagram Protocol, 简称 UDP )进行传 输。 其交互模式可以是同步的响应， 也可以是异步的响应。 消息类型可以是： 需要确认的消息（ Confirmable ) 、 不需要确认的消息（ Non-confirmable ) 、 确 认消息（ Acknowledgement )、重置消息（ Reset )。可以通过事务标识 ( Messages ID )来关联一对请求和响应。
CoAP支持的方法有四个： Get (获取资源） 、 Put (更新资源） 、 Post (创 建资源）和 Delete (删除资源） 。 资源通过 URI来识别。 我们通常称资源的拥 有方为服务器（Server ) , 请求资源方为终端 （Client ) 。
CoAP协议支持不同的选项（Option ) , 比如 Block (分片 )、 Location (位 置）、 Token (令牌） 等， 不同的选项支持不同的功能， 并且可以通过定义新 的 Option来扩展新的功能。
CoAP中代理节点 （Proxy )是指一个 CoAP逻辑实体， 它位于 CoAP终端 ( Client )和 CoAP服务器（Server )路由路径之间， 对 CoAP协议消息进行处理 并路由转发， 其处理可以是过滤， 权限检查， 目标地址查询等等。 任何一个
CoAP节点都可以作为一个代理节点， 一般在子网之间的节点与受限网络和外 部网络的关联节点上始终支持代理功能。
CoAP支持订阅， 如果终端发起的订阅请求经过代理节点， 则该代理节点 需要保存终端和代理节点之间的会话以及的和代理节点之间的会话的状态关 系。 在该订阅过程， 代理节点需要记录终端的地址、 终端和代理节点之间的令 牌选项信息、 服务器的地址、 代理节点和服务器之间的令牌选项信息
由于代理节点需要处理会话状态以及记录会话相关数据，而代理节点通常 是为很多 CoAP终端和服务器提供服务， 因此代理节点有差异。
相同的处理能力的情况下，存储了多个会话状态以及记录会话相关数据的 代理节点处理速度要低于存储了一个会话状态以及记录会话相关数据的代理 节点， 因此同一时间段内前者能够处理的订阅数量就少于后者。
已存储会话状态以及记录会话相关数据的代理节点受限于存储能力，只能 存储一定数量的订阅会话状态，如果订阅数量超出， 则此代理节点不能处理新 的订阅请求。
因为路由信息增加造成报文需要分片，或者报文路由信息增加带来服务器 存储量的增加， 而作为代理节点的服务器性能是受限的，存储量增加造成能同 时存储的订阅数量就会减少， 导致通信延误或无法发送。 发明内容
本发明实施例提供了一种受限应用协议 CoAP中数据通信的方法， 根据代 理节点是否将存储本次请求对应的会话的参数和状态进行 Via选项信息的处 理， 减少因为报文中路由信息增加带来通信延误或无法发送问题的可能性。
本发明一方面提供了一种受限应用协议 CoAP中数据通信的方法， 该方法 包括： 接收来自终端发送的请求； 根据代理节点是否将存储该请求对应的会话 的参数和状态， 对该请求进行路径记录 Via选项信息的处理， 其中 Via选项信息 用于记录请求路径和响应路由； 发送经处理后的请求。
本发明另一方面提供了一种受限应用协议 CoAP中数据通信的方法， 该方 法包括： 生成携带 Via选项信息的请求， Via选项信息用于记录请求路径和响应 路由； 向代理节点发送请求， 以便于根据代理节点是否将存储该请求对应的会 话的参数和状态， 对该请求进行 Via选项信息的处理； 以及接收经代理节点的 基于请求发送的响应。
本发明又一方面， 提供了一种受限应用协议 CoAP中数据通信的方法， 该 方法包括： 接收来自终端的经代理节点发送的请求； 基于请求， 生成携带 Via 选项信息的响应， 其中 Via选项信息用于记录请求路径和响应路由； 向代理节 点发送响应，以便于代理节点根据代理节点是否已存储该请求对应的会话的参 数和状态， 对该响应进行 Via选项信息的处理， 并向终端发送经处理后的响应。
本发明一方面还提供了一种受限应用协议 CoAP数据通信的装置， 该装置 包括： 接收模块， 用于接收来自终端发送的请求； 处理模块， 用于根据装置是 否将存储请求对应的会话的参数和状态，对请求进行路径 Via选项信息的处理， 其中 Via选项信息用于记录请求路径和响应路由； 发送模块， 用于发送经处理 后的请求。
本发明另一方面， 提供了一种受限应用协议 CoAP中数据通信的终端， 该 终端包括： 生成模块， 用于生成携带 Via选项信息的请求， Via选项信息用于 记录请求路径和响应路由； 发送模块， 用于向代理节点发送请求， 以便于代理 节点根据代理节点是否将存储该请求对应的会话的参数和状态，对该请求进行 Via选项信息的处理； 接收模块， 用于接收经代理节点的基于请求发送的响应。
本发明又一方面， 提供了一种受限应用协议 CoAP中数据通信的服务器， 该服务器包括： 接收模块， 用于接收来自终端的经代理节点发送的请求； 生成 模块， 用于基于请求， 生成携带 Via选项信息的响应， 其中， Via选项信息用于 记录请求路径和响应路由； 发送模块， 用于向代理节点发送响应， 以便于代理 节点根据代理节点是否已存储所述请求对应的会话的参数和状态，对该响应进 行 Via选项信息的处理， 并向终端发送经处理后的响应。
通过上述方案， 本发明实施例能够实现无状态代理， 允许有状态代理节点 和无状态代理节点可以在同一会话的传输路径上同时存在，通过有状态代理将 协议报文中的路径的路由信息提取后删除， 改为本地存储路径的路由信息， 缩 短协议报文中携带的路由信息， 由此提高代理节点资源使用的效率， 减少了代 理节点繁忙或故障时引起的通信延误或中断。 附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所 需要使用的附图作简单地介绍，显而易见地， 下面所描述的附图仅仅是本发明 的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下， 还可以根据这些附图获得其他的附图。
图 1是根据本发明实施例受限应用协议 CoAP中数据通信的方法的流程图。 图 2是根据本发明实施例受限应用协议 CoAP中数据通信的例子的示意图。 图 3是根据本发明另一实施例受限应用协议 CoAP中数据通信的例子的示 意图。
图 4是根据本发明另一实施例受限应用协议 CoAP中数据通信的例子的示 意图。
图 5是根据本发明另一实施例受限应用协议 CoAP中数据通信的例子的示 意图。
图 6是根据本发明另一实施例受限应用协议 CoAP中数据通信的例子的示 意图。
图 7是根据本发明实施例受限应用协议 CoAP中数据通信的例子的示意图。 图 8是根据本发明实施例受限应用协议 CoAP中数据通信的另一方法的流 程图。
图 9是根据本发明实施例受限应用协议 CoAP中数据通信的又一方法的流 程图。
图 10是根据本发明实施例受限应用协议 CoAP中数据通信的装置的框图。 图 11是根据本发明另一实施例受限应用协议 CoAP中数据通信的装置的框 图。
图 12是根据本发明实施例受限应用协议 CoAP中数据通信的终端的框图。 图 13是根据本发明实施例受限应用协议 CoAP中数据通信的服务器的框 图。 具体实施方式 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清 楚、 完整地描述， 显然， 所描述的实施例是本发明的一部分实施例， 而不是全 部实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳 动的前提下所获得的所有其他实施例， 都应属于本发明保护的范围。
图 1是根据本发明实施例受限应用协议 CoAP中数据通信的方法 100的流程 图。
如图 1的方法 100所示， 包括：
110, 接收来自终端发送的请求。 请求中包括令牌选项信息， 服务器地址 信息等。令牌选项信息用于将请求和响应关联， 即请求和对应响应的令牌选项 信息是相同的。 其中， 所述来自终端发送的请求可以为直接来自终端的请求， 也可以为由别的代理节点发送的来自终端发送的请求。具体的，代理节点既可 以直接接收终端发送的请求， 也可以从别的代理节点处接收由终端发送的请 求。
120, 根据代理节点是否将存储本次请求对应的会话的参数和状态， 对所 述请求进行路径记录（ Via )选项信息的处理， 其中 Via选项信息用于记录请求 路径和响应路由。
130, 发送经处理后的请求。
本发明实施例允许在 CoAP中， 根据代理节点是否存储本次请求对应的会 话的参数和状态将代理节点分成无状态代理节点和有状态代理节点，并且可以 在同一会话的传输路径上同时存在。一个会话包括请求和响应。本发明实施例 中，处理一个会话的请求时将存储该会话的参数和状态的代理节点和处理一个 会话的响应时已存储该会话的参数和状态的代理节点称为该会话中的有状态 代理节点， 简称有状态代理节点； 相似的， 在处理该次会话的请求时不存储该 会话的参数和状态的代理节点以及在处理该次会话的响应时未存储该会话的 参数和状态的代理节点称为该会话中的无状态代理节点， 简称无状态代理节 点。 会话的参数包括令牌选项信息， Via选项信息等， 会话的状态包括建立中， 已建立， 结束等。代理节点是否是有状态代理节点或无状态代理节点是针对一 个会话定义的， 对不同的会话， 代理节点可以充当不同的角色， 即同一代理节 点可以在一个会话中充当有状态代理节点，而在另一会话中充当无状态代理节 点， 但是一个会话过程进行中不能更改在该会话中的状态。
代理节点判断自己会充当有状态代理节点或无状态代理节点可以通过以 下方法判断。 例如， 在代理节点的配置文件中设置标识， 代理节点通过识别该 标识来确定充当有状态代理节点或无状态代理节点，可以通过人工配置改变该 标识， 从而使代理节点改变角色； 也可以通过所分配的内存空间大小来决定， 如果内存空间大小可以存储会话参数和状态， 则代理节点将充当有状态代理， 反之则充当无状态代理；代理节点如何判断自身充当有状态代理或无状态代理 不是本发明所解决问题， 这里仅进行举例说明。
当在该次会话中，代理节点在处理所述请求时， 不存储所述请求对应的会 话的参数和状态，或当代理节点处理所述响应时，代理节点未存储所述响应对 应的请求的会话参数或状态， 即此代理节点是无状态代理节点。无状态代理节 点在请求中增加 Via选项信息， 以向服务器发送请求。
当在该次会话中，代理节点在处理所述请求时，将存储所述请求对应的会 话的参数和状态； 或当代理节点处理所述响应时，代理节点已存储所述响应对 应的请求的会话参数或状态， 即此代理节点是有状态代理节点。有状态代理节 点存储请求中的 Via选项信息并删除请求中的 Via选项信息。
在执行 120前，首先在 CoAP协议中定义一个新的选项，路径记录 (Via)选项， 简称 Via选项 , 用于记录请求路径和响应路由。 Via选项携带的赋值称为 Via选 项信息。 Via选项由类型长度值 ( TLV, Type Length Value )字段定义如下表 1 所示
Figure imgf000008_0001
从表 1得知， Via选项信息作为字符串可以是请求所经过的 Proxy的地址，可 以是一个 URI、 IP地址或者唯一的设备编号等， Via选项信息是可路由的， 即可 以根据该赋值和对应的设备实现通信，从上得知 Via选项没有缺省值。其中 C/E 是 Via选项的属性之一， C代表 CoAP路径上的节点必须理解该选项并做相应处 理， E代表 CoAP路径上的节点可以不理解该选项， 不做相应处理。
举例来说， 当 Via选项信息中包括多个地址信息时， Via选项信息实现方 式有如下两种方式。
例如：
Via: 192.0.0.2, 190.2.1.1
在该方法中，新加入的地址信息顺序放在后面。 最前面的地址信息称为第 二 Via选项信息， 最后面的地址信息称为第一 Via选项信息。
或：
Via: 192.0.2.1
Via: 192.0.2.2
本发明实施例以第二种实现方式为例说明，新加入的地址信息顺序放置在 上面。 在该方法中， 最上面的地址信息称为第一 Via选项信息， 最下面的地址 信息称为第二 Via选项信息。
通过上述方案， 在 CoAP中， 允许有状态代理节点和无状态代理节点可以 在同一会话的传输路径上同时存在，并且通过有状态代理节点将协议报文中的 路径的路由信息提取后删除， 改为本地存储路径的路由信息， 缩短协议报文中 携带的路由信息， 由此提高代理节点资源使用的效率， 减少了代理节点繁忙或 故障时引起的通信延误或中断。
图 2是根据本发明实施例受限应用协议 CoAP中数据通信的例子 200的示意 图。
如图 2的例子 200所示， 包括：
210, 接收请求。 接收请求的代理节点可以是无状态代理节点或有状态代 理节点。
220, 当请求为直接由终端发送时， 比较第一 Via选项信息携带的地址和请 求的用户数据 4艮协议 ( UDP, User Datagram Protocol ) 4艮文源地址（简称请求 的源地址）是否一致， 如果不一致， 则执行到 230 ( 220的"否"） ； 如果一致， 则执行到 240 ( 220的"是"） 。
230, 将第一 Via选项信息携带的地址改为请求的源地址。 当代理节点确定最上面的 Via选项信息（第一 Via选项信息）携带的信息和 请求的源地址不一致时， 则将最上面的 Via选项信息（第一 Via选项信息）修改 成请求的源地址。
240, 确定本代理节点是作为有状态代理节点， 如果不是， 则到 260 ( 240 的"否"） ， 如果是， 则到 250 ( 240的"是"） 。
确定代理节点是否充当有状态代理节点或无状态代理节点的方法前面已 有描述。
250, 有状态代理节点将请求中的 Via选项信息存储到本地， 然后删除请求 中的 Via选项信息。 具体的， 有状态的代理节点可以将请求中的 Via选项信息与 请求中的令牌选项信息对应存储， 以便后期根据令牌选项信息获取存储的 Via 选项信息。
260, 增加携带本代理节点地址的 Via选项信息。
无状态代理节点在请求中增加携带本代理节点地址的 Via选项信息。
有状态代理节点可以在请求中增加携带本代理节点地址的 Via选项信息。 270, 无状态代理节点或有状态代理节点发送处理后的请求。
根据上述方案， 在 CoAP中， 允许有状态代理节点和无状态代理节点可以 在同一会话的传输路径上同时存在，并且通过有状态代理节点将协议报文中的 路径的路由信息提取后删除， 改为本地存储路径的路由信息， 使得请求的 Via 选项信息占用的负载尽可能的少， 缩短协议报文中携带的路由信息， 由此提高 代理节点资源使用的效率， 以减少对传输的消耗， 减少了代理节点繁忙或故障 时引起的通信延误或中断。
图 3是根据本发明另一实施例受限应用协议 CoAP中数据通信的例子 300的 示意图。 图 3中的实施例是图 2中实施例的另一种实现方法， 终端或代理节点不 再将自己的地址加入 Via选项信息， 由路径下一跳的代理节点来加入。
如图 3的例子 300所示， 包括：
310, 接收请求。 接收请求的代理节点可以是无状态代理节点或有状态代 理节点。
320, 确定本代理节点是否是无状态代理节点， 如果不是， 则执行到 330, 如果是， 则执行到 360。 330, 有状态代理节点按顺序存储请求中的 Via选项信息。 具体的， 有状态 的代理节点可以将请求中的 Via选项信息与请求中的令牌选项信息对应存储， 以便后期根据令牌选项信息获取存储的 Via选项信息。
340, 有状态代理节点存储 Via选项信息后， 删除请求中的 Via选项信息。 如果请求中没有 Via选项信息， 则省略 330和 340, 直接执行步骤 350。
Figure imgf000011_0001
在同一会话的传输路径上同时存在，并且通过有状态代理节点将协议报文中的 路径的路由信息提取后删除， 改为本地存储路径的路由信息， 缩短协议报文中 携带的路由信息， 由此提高代理节点资源使用的效率， 减少了代理节点繁忙或 故障时引起的通信延误或中断。 终端或代理节点不再将自己的地址加入 Via选 项信息， 由路径下一跳的代理节点来加入， 由此进一步减少对代理节点传输资 源的消耗。
上述实施例中以路径中一跳为例说明。 实际中， 路径可以有多跳， 其中代 理节点分别为无状态代理节点或有状态代理节点。多跳路径中相邻的代理节点 可以是连续的无状态代理节点、也可以是连续的有状态代理节点， 亦可以两者 交替。 本发明实施例对此没有限定。
在 CoAP中，无状态代理节点和有状态代理节点的 Via选项信息使用的地址 是统一的。 也就是说， 当无状态代理节点使用请求的源地址作为增加的 Via选 项信息时，则有状态代理节点将请求的源地址增加到所存储的 Via选项信息中， 如例子 300所示。或者当无状态代理节点使用本代理节点的地址作为 Via选项信 息时， 则有状态代理节点在删除请求中的 Via选项信息后， 使用本代理节点的 地址作为 Via选项信息， 如例子 200所示。 反之亦然。
图 4是根据本发明另一实施例受限应用协议 CoAP中数据通信的例子 400的 示意图。 图 于图 2或图 3的例子的请求， 做出响应的例子。
如图 4的例子 400所示， 包括： 410, 接收基于请求的响应。 接收响应的代理节点可以是无状态代理节点 或有状态代理节点。 响应中包括诸如令牌选项信息， 和 /或终端的地址信息。
420, 当响应中包含 Via选项信息时，删除响应中最上面的 Via选项信息（即 第一 Via选项信息） 。
430, 确定是否还包含 Via选项信息， 如果否， 则执行到 440, 如果是， 则 执行到 450。
440,根据令牌选项信息查找本地存储的与令牌选项信息对应的 Via选项信 息， 并将根据该令牌选项信息查找到的存储的 Via选项信息加入响应， 然后执 行图 4的 450。有状态代理节点执行图 4的 440。令牌选项信息用于将请求和响应 关联， 即请求和对应响应的令牌选项信息是相同的。
450 ,将删除第一 Via选项信息后的响应中剩余 Via选项信息中最上面的 Via 选项信息 （第一 Via选项信息）作为响应目的地址， 将响应发送到目的地址对 应的设备。
通过上述方案， 在 CoAP中， 允许有状态代理节点和无状态代理节点可以 在同一会话的传输路径上同时存在，并且通过有状态代理节点将协议报文中的 路径的路由信息提取后删除， 改为本地存储路径的路由信息， 缩短协议报文中 携带的路由信息， 由此提高代理节点资源使用的效率。
图 5是根据本发明另一实施例受限应用协议 CoAP中数据通信的例子 500的 示意图。 作为图 4的发明实施例的另一选择， 图 5例示了另一实施例实现方式， 服务器或代理节点在发送响应之前， 会先将报文中最上面的 Via选项信息 （第 一 Via选项信息）删除。
如图 5的例子所示 500, 包括：
510, 接收基于请求的响应。 接收响应的代理节点可以是无状态代理节点 或有状态代理节点。
520, 确定响应中是否包含 Via选项信息， 如果是， 则执行到 530, 如果否， 则执行到 540 ( 520的"是"） 。
530, 根据响应中的令牌选项信息查找本地存储的与响应中的令牌选项信 息对应的 Via选项信息，并将根据该令牌选项信息查找到的存储的 Via选项信息 增力口到响应中。 540, 将响应中 Via选项信息中最上面的 Via选项信息 （第一 Via选项信息） 作为响应目的地址。
550, 删除响应中 Via选项信息中最上面的 Via选项信息 （第一 Via选项信 息）。 删除响应中最上面的 Via选项信息（第一 Via选项信息）的代理节点可以 是无状态代理节点或有状态代理节点。
560, 将响应发送到目的地址对应的设备。
代理节点会在会话结束后删除所存储的会话参数， 包括 Via选项信息， 对 于订阅的情况，会话结束代表了订阅结束，订阅结束的判断方法可以是给订阅 加上有效期， 或者被订阅方显示的通过应答来结束订阅。
通过上述方案， 在 CoAP中， 允许有状态代理节点和无状态代理节点可以 在同一会话的传输路径上同时存在，并且通过有状态代理节点将协议报文中的 路径的路由信息提取后删除， 改为本地存储路径的路由信息， 缩短协议报文中 携带的路由信息， 由此提高代理节点资源使用的效率， 减少了代理节点繁忙或 故障时引起的通信延误或中断。 服务器或代理节点不再将自己的地址加入 Via 选项信息， 由路径下一跳的代理节点来加入。
图 6的实施例是图 4和图 5实施例中有状态代理节点实现的另一种选择。 服 务器或有状态代理节点向客服端返回响应时，会尝试跳过无状态代理节点， 只 有在跳过失败时， 才会严格按照请求经过的代理节点， 原路径返回。 此发明实 施例中， 增加表示尝试的尝试标识位， 其比特位上以 1表示已经尝试过跳过无 状态代理节点， 以 0表示准备尝试跳过无状态代理节点， 此处尝试标识位的表 示方法仅是举例说明， 也可以以其他任何方式表示。
图 6是根据本发明另一实施例受限应用协议 CoAP中数据通信的例子 600的 示意图。
如图 6的例子所示， 包括：
610, 接收到基于请求的响应后， 将已存储的与响应中的令牌选项信息对 应的 Via选项信息增加到响应中。
620, 确定响应中是否只存在一个 Via选项信息， 是则执行 680, 否则执行
630。
630, 确定响应中尝试标志位是否为 1 , 是则执行 680, 否则执行 640。 640, 删除响应中 Via选项信息只剩最下面的一个（第二 Via选项信息） , 并将尝试标识位从 0设为 1。
650 , 将只剩该第二 Via选项信息的响应发送到该第二 Via选项信息对应的 设备。
660, 确定响应是否发送成功， 如果是则执行 670, 否则执行 610。
可以通过对需要确认请求 CON的确认（ACK ) 响应来确定响应是否发送 成功；
670,删除响应中令牌选项信息对应的本次会话在本地所存储的 Via选项信 息， 只保留最下面一个（即第二 Via选项信息） 。 此时， 尝试跳过无状态代理 节点成功。
680, 将响应发送到响应中最上面的 Via选项信息 （即第一 Via选项信息） 对应的设备。 这是发送响应的正常顺序。
上述实施例中使用尝试标志位仅是尝试跳过无状态代理节点实现方式的 一种例子， 本发明不限于此。 其他实现方式例如可以通过确定有多个 Via选项 信息， 将响应直接发送到响应中最下面的一个（第二 Via选项信息）对应的设 备。
图 6中的实施例可以应用在下述场景例子中。 假设请求经过的代理节点以 及各代理节点对请求的会话状态信息保存情况为：
Client—ProxyA (未存储会话状态， 无状态代理节点)一ProxyB(已存储会话 状态，有状态代理节点)一ProxyC (未存储会话状态，无状态代理节点)一ProxyD (已存储会话状态， 有状态代理节点） --- ProxyE (未存储会话状态， 无状态代 理节点)一 Server,
则 Server在处理返回响应时， 试图跳过无状态代理节点 ProxyE , 尝试直接 发送响应到 ProxyD, 只有直接发送失败时才会发送给 ProxyE, 由 ProxyE转发 响应到 ProxyD; ProxyD同样试图跳过无状态代理节点 ProxyC直接尝试发送响 应到 ProxyB, 只有当发送响应不成功时， 才经由 ProxyC转发。
通过上述方案， 在 CoAP中， 允许有状态代理节点和无状态代理节点可以 在同一会话的传输路径上同时存在，并且通过有状态代理节点将协议报文中的 路径的路由信息提取后删除， 改为本地存储路径的路由信息， 缩短协议报文中 携带的路由信息， 由此提高代理节点资源使用的效率， 减少了代理节点繁忙或 故障时引起的通信延误或中断。
图 7是根据本发明实施例受限应用协议 CoAP中数据通信的例子的示意图。 这里只关注本发明新增加的 Via选项信息的变化， 假设 ProxyA是无状态的 代理节点， ProxyB是有状态的代理节点， Client、 ProxyA、 ProxyB、 Server的 地址分别为：
Client的 URI为： coap：〃 clientsensor.example/clientl 通讯地址为： 192.0.2.2 ProxyA的通讯地址为： 192.0.2.1
ProxyB的通讯地址为： 192.1.2.1
Server的 URI为： coap ://server. sensor. example/Server 1
如图 7的例子所示， 包括：
701 , Client发起请求时， 生成携带该 client的地址的 Via选项信息。
Via： 192.0.2.2
703 , ProxyA不存储该请求的会话的参数和状态， 它在请求中增加携带自 己地址的 Via选项信息， 放置在终端的 Via选项信息上：
Via： 192.0.2.1
Via： 192.0.2.2
705 , ProxyB是有状态代理节点， 它首先将请求中的 Via选项信息存储在本 地， 然后再在请求中删除步骤 703中的请求的 Via选项信息， 并增加自己的地址 作为新的 Via选项信息：
Via： 192.1.2.1
步骤 703中的请求的 Via选项信息：
Via： 192.0.2.1
Via： 192.0.2.2
被记录在 ProxyB上。 将携带 ProxyB的地址的请求发送到服务器。
706-710, 将服务器基于步骤 701的请求的响应发送到终端。
711 , 当请求的资源发生改变时， Server向终端发送异步通知消息。 该异步 通知消息可以是对本次请求的多次响应中的其中一次响应。
Server首先提取出获取步骤 705的请求中的 Via选项信息以及 Token选项信 息生成携带该 Via选项信息和 Token选项信息的响应：
200 OK
Via： 192.1.2.1
713 , ProxyB根据消息类型 （Type ) ： 200发现是响应消息， 根据 Token选 项信息查找到本地存储的会话信息， 从会话信息中提取出之前存储的 Via选项 信息
Via： 192.0.2.1
Via： 192.0.2.2
解析该 Via的值， 得到下一个地址 192.0.2.1 , 转发响应到该代理节点 ProxyA, 此时响应信息为：
200 OK
Via： 192.0.2.1
Via： 192.0.2.2
715 , ProxyA解析从 ProxyB转发过来的响应， 根据 Token选项信息未发现 本地有对应的会话信息， 根据从 Via选项中提取的路由信息转发响应到终端 Client, 此时的响应信息为：
200 OK
Via： 192.0.2.2
至此完成整个路由过程。
在上述实施例中， 步骤 708, 710, 712, 714以及 716为收到响应后返回的 确认消息。
图 8是根据本发明实施例受限应用协议 CoAP中数据通信的另一方法 800的 流程图。 该方法由终端完成。
如图 8的方法 800所示， 包括：
810, 生成携带 Via选项信息的请求， 其中 Via选项信息用于记录请求路径 和响应路由。
例如 , 其中 Server的 URI为： coap：〃 server.sensor.example/ServerlClient的 URI为： coap：〃 clientsensor.example/clientl 通讯地址为： 192.0.2.2, 生成携带 自己地址的 Via选项信息， Via： 192.0.2.2
820, 向代理节点发送请求， 以便于所述代理节点根据代理节点是否将存 储所述请求对应的会话的参数和状态对所述请求进行 Via选项信息的处理。 无 状态代理节点或有状态代理节点向服务器发送请求的方法参考图 1的方法。
假设请求经过的代理节点以及各代理节点对请求的会话状态信息保存情 况为：
Client—ProxyA (不存储会话状态， 无状态代理节点)一ProxyB (将存储会话 状态， 有状态代理节点） --- Server。
经过的无状态代理节点 ProxyA不存储该次请求的会话状态，它在请求中增 加携带自己地址的 Via选项信息， 放置在终端的 Via选项信息上：
Via： 192.0.2.1
Via： 192.0.2.2
经过的有状态代理节点 ProxyB首先将之前的 Via选项信息存储在本地， 然 后再在请求中删去之前的 Via选项信息并增加携带自己地址的 Via选项信息： Via： 192.1.2.1
之前的 Via选项信息：
Via： 192.0.2.1
Via： 192.0.2.2
被记录在有状态代理节点 ProxyB上。 将处理后的请求发送到服务器。 服务器接收到请求， 存储 Via选项信息。
830, 接收经代理节点的基于请求发送的响应。
服务器首先提取出有状态代理节点的 Via选项信息携带的地址以及 Token 选项信息：
200 OK
Via： 192.1.2.1
有状态代理节点 ProxyB根据消息类型 （Type ) ： 200发现是响应消息， 根 据 TokenlD查找到本地存储的会话信息， 从会话信息中提取出之前存储的 Via 选项信息
Via： 192.0.2.1 Via： 192.0.2.2
解析该 Via的值， 得到下一个地址 192.0.2.1 , 转发消息到无状态代理节点 ProxyA, 此时响应信息为：
200 OK
Via： 192.0.2.1
Via： 192.0.2.2
无状态代理节点 ProxyA解析从有状态代理节点 ProxyB转发过来的响应， 根据 TokenlD未发现本地有对应的会话信息，根据从 Via选项中提取的路由信息 转发响应到终端， 此时的响应信息为：
200 OK
Via： 192.0.2.2
至此完成整个路由过程。
通过上述方案， 在 CoAP中， 允许有状态代理节点和无状态代理节点可以 在同一会话的传输路径上同时存在，并且通过有状态代理节点将协议报文中的 路径的路由信息提取后删除， 改为本地存储路径的路由信息， 缩短协议报文中 携带的路由信息， 由此提高代理节点资源使用的效率， 减少了代理节点繁忙或 故障时引起的通信延误或中断。
图 9是根据本发明实施例受限应用协议 CoAP中数据通信的又一方法 900的 流程图。 该方法由服务器完成。
如图 9的方法 900所示， 包括：
910, 接收来自终端的经代理节点发送的请求。 无状态代理节点或有状态 代理节点向服务器发送请求的方法参考图 1的方法。
例^口, Client的 URI为： coap：〃 sensor. example/client通讯地址为： 192.0.2.2, 生成携带自己地址的 Via选项信息，
Via： 192.0.2.2
假设请求经过的代理节点以及各代理节点对请求的会话状态信息保存情 况为：
Client—ProxyA (不存储会话状态， 无状态代理节点)一ProxyB (将存储会话 状态， 有状态代理节点） --- Server。 经过的无状态代理节点 ProxyA不存储该次请求的会话状态，它在请求中增 加携带自己地址的 Via选项信息， 放置在终端的 Via选项信息下：
Via： 192.0.2.1
Via： 192.0.2.2
经过的有状态代理节点 ProxyB首先将之前的 Via选项信息存储在本地， 然 后再在请求中删除之前的 Via选项信息并增加携带自己地址的 Via选项信息： Via： 192.1.2.1
之前的 Via选项信息：
Via： 192.0.2.1
Via： 192.0.2.2
被记录在有状态代理节点 ProxyB上。 将请求发送到服务器。
服务器接收到请求， 存储 Via选项信息。
920, 基于请求， 生成携带 Via选项信息的响应， 其中 Via选项信息用于记 录请求路径和响应路由。
服务器首先提取出有状态代理节点 ProxyB的 Via选项信息携带的地址以及
Token选项信息：
200 OK
Via： 192.1.2.1
930, 向 ProxyB发送响应， 以便于代理节点根据代理节点是否已存储请求 对应的会话的参数和状态， 对该响应进行 Via选项信息的处理， 并向终端发送 经处理后的响应。
有状态代理节点 ProxyB根据消息类型 （Type ) ： 200发现是响应消息， 根 据 TokenlD查找到本地存储的会话信息， 从会话信息中提取出之前存储的 Via 选项信息
Via： 192.0.2.1
Via： 192.0.2.2
解析该 Via的值， 得到下一个地址 192.0.2.1 , 转发消息到无状态代理节点 ProxyA, 此时响应信息为：
200 OK Via： 192.0.2.1
Via： 192.0.2.2
无状态代理节点 ProxyA解析从有状态代理节点 ProxyB转发过来的响应， 根据 TokenlD未发现本地有对应的会话信息，根据从 Via选项中提取的路由信息 转发响应到终端， 此时的响应信息为：
200 OK
Via： 192.0.2.2
至此完成整个路由过程。
通过上述方案， 在 CoAP中， 允许有状态代理节点和无状态代理节点可以 在同一会话的传输路径上同时存在，并且通过有状态代理节点将协议报文中的 路径的路由信息提取后删除， 改为本地存储路径的路由信息， 缩短协议报文中 携带的路由信息， 由此提高代理节点资源使用的效率， 减少了代理节点繁忙或 故障时引起的通信延误或中断。
图 10是根据本发明实施例受限应用协议 CoAP中数据通信的装置的框图。 作为示例性的实现方式， 图 10的装置可以为 CoAP中的代理节点， 包括接 收模块 1010、 处理模块 1020和发送模块 1030。
接收模块 1010,用于接收来自终端发送的请求。请求中包括令牌选项信息， 服务器地址信息等。令牌选项信息用于将请求和响应关联， 即请求和对应响应 的令牌选项信息是相同的。
处理模块 1020,用于根据装置是否将存储所述请求对应的会话的参数和状 态对所述请求进行 Via选项信息的处理，其中 Via选项信息用于记录请求路径和 响应路由。
发送模块 1030, 用于发送经处理后的请求。
本发明实施例允许在 CoAP中， 根据装置 （代理节点）是否存储本次请求 对应的会话的状态和参数将代理节点分成无状态代理节点和有状态代理节点， 并且可以在同一会话的传输路径上同时存在。一个会话包括请求和响应。本发 明实施例中，处理一个会话的请求时将存储该会话的参数和状态的代理节点和 处理一个会话的响应时已存储该会话的参数和状态的代理节点称为该会话中 的有状态代理节点， 简称有状态代理节点； 相似的， 在处理该次会话的请求时 不存储该会话的参数和状态的代理节点以及在处理该次会话的响应时未存储 该会话的参数和状态的代理节点称为该会话中的无状态代理节点，简称无状态 代理节点。 会话的参数包括令牌选项信息， Via选项信息等， 会话的状态包括 建立中， 已建立， 结束等。 代理节点是否是有状态代理节点或无状态代理节点 是针对一个会话定义的， 对不同的会话， 代理节点可以充当不同的角色， 即同 一代理节点可以在一个订阅中充当有状态代理节点，而在另一订阅中充当无状 态代理节点， 但是一个订阅过程进行中不能更改在该订阅中的状态。
代理节点判断自己将充当有状态代理节点或无状态代理节点可以通过以 下方法判断。 例如， 在代理节点的配置文件中设置标识位， 代理节点通过识别 该标识位来确定充当有状态代理节点或无状态代理节点，可以通过人工配置改 变该标识位，从而使代理节点改变角色； 也可以通过所分配的内存空间大小来 决定，如果内存空间大小可以存储会话参数和状态， 则代理节点将充当有状态 代理，反之则充当无状态代理； 代理节点如何判断自身充当有状态代理或无状 态代理不是本发明所解决问题， 这里仅进行举例说明。
当在该次会话中无状态代理节点在请求中增加 Via选项信息， 以向服务器 发送请求。 当在该次会话中， 有状态代理节点存储请求中的 Via选项信息并删 除请求中的 Via选项信息。
也就是说，处理模块 1020具体用于当所述装置不存储所述请求对应的会话 的参数和状态时， 在所述请求中增加 Via选项信息； 所述发送模块 1030具体用 于发送增加了所述 Via选项信息的请求； 或处理模块 1020具体用于当所述装置 将存储所述请求对应的会话的参数和状态时，存储所述请求中的 Via选项信息， 并删除所述请求中的 Via选项信息； 所述发送模块 1030具体用于发送删除了所 述 Via选项信息的请求。
首先在 CoAP协议中定义一个新的选项，路径记录 (Via)选项，简称 Via选项， 用于记录请求路径和响应路由。 Via选项携带的赋值称为 Via选项信息。 Via选 项由类型长度值 ( TLV, Type Length Value )字段定义如表 1。
参见表 1得知， Via选项信息作为字符串可以是请求所经过的 Proxy的地址, 可以是一个 URI、 IP地址或者唯一的设备编号等， Via选项信息是可路由的， 即 可以根据该赋值和对应的设备实现通信， 从上得知 Via选项没有缺省值。 其中 C/E是 Via选项的属性之一 , C代表 CoAP路径上的节点必须理解该选项并做相应 处理， E代表 CoAP路径上的节点可以不理解该选项， 不做相应处理。
举例来说， 当 Via选项信息中包括多个地址信息时， Via选项信息实现方 式有如下两种方式。
例如：
Via: 192.0.0.2, 190.2.1.1
在该方法中，新加入的地址信息顺序放在后面。 最前面的地址信息称为第 二 Via选项信息， 最后面的地址信息称为第一 Via选项信息。
或：
Via: 192.0.2.1
Via: 192.0.2.2
本发明实施例以第二种实现方式为例说明，新加入的地址信息顺序放置在 上面。 在该方法中， 最上面的地址信息称为第一 Via选项信息， 最下面的地址 信息称为第二 Via选项信息。
进一步的， 当所述请求中使用请求的源地址作为 Via选项信息时， 如果所 述装置不存储所述请求对应的会话的参数和状态，所述处理模块 1020使用所述 请求的源地址作为增加的所述 Via选项信息； 或如果所述装置将存储所述请求 对应的会话的参数和状态，所述处理模块 1020将所述请求的源地址增加到所存 储的 Via选项信息中； 或
当所述请求中使用装置的地址作为 Via选项信息时， 如果所述装置不存储 所述请求对应的会话的参数和状态， 所述处理模块 102使用所述装置的地址作 为增加的所述 Via选项信息； 或如果所述装置将存储所述请求对应的会话的参 数和状态， 所述处理模块 1020在删除所述请求中的 Via选项信息后， 将所述装 置的地址增加在删除了 Via选项信息后的请求中。
通过上述方案， 在 CoAP中， 允许有状态代理节点和无状态代理节点可以 在同一会话的传输路径上同时存在，并且通过有状态代理节点将协议报文中的 路径的路由信息提取后删除， 改为本地存储路径的路由信息， 缩短协议报文中 携带的路由信息， 由此提高代理节点资源使用的效率， 减少了代理节点繁忙或 故障时引起的通信延误或中断。 图 11是根据本发明另一实施例受限应用协议 CoAP中数据通信的装置的框 图。
该装置的接收模块 1101、处理模块 1102和发送模块 1103可以执行装置 1000 的接收模块 1010、处理模块 1020和发送模块 1030的功能， 以及还可以执行更多 的功能，具体参见下文的表述，此夕卜，装置还包括确定模块 1104、查找模块 1105。
当具体的， 当接收模块 1101接收到终端的请求时（即接收到直接来自终端 的请求时）且当请求中使用请求的源地址作为 Via选项信息时， 所述装置还包 括确定模块 1104。 所述确定模块 1104用于当， 确定当第一 Via选项信息和请求 的源地址不一致时， 将第一 Via选项信息修改成请求的源地址。
进一步的，接收模块 1101用于终端进一步用于接收来自所述服务器的基于 所述请求的响应， 以便于向所述终端发送所述响应；
当所述响应携带多个 Via选项信息时， 所述发送模块 1103进一步用于当所 述装置未存储所述请求对应的会话的参数和状态时，删除所述响应中携带的第 一 Via选项信息， 并将删除了所述第一 Via选项信息的响应发送到剩余 Via选项 信息中的第一 Via选项信息对应的设备； 或当所述响应携带 Via选项信息时， 所 述发送模块 1103进一步用于当所述装置未存储所述请求对应的会话的参数和 状态时， 删除所述响应中的第一 Via选项信息， 并将删除了所述第一 Via选项信 息的响应发送到所述第一 Via选项信息对应的设备。
进一步的， 当所述响应未携带所述 Via选项信息， 且所述装置已存储所述 请求对应的会话的参数和状态时， 则所述装置还包括查找模块 1105。 所述查找 模块 1105用于根据所述响应中的令牌选项信息查找本地存储的与所述令牌选 项信息对应的 Via选项信息； 并且所述处理模块 1102进一步用于将根据所述令 牌选项信息查找到的存储的 Via选项信息加入所述响应，删除加入的 Via选项信 息中的第一 Via选项信息； 所述发送模块 1103进一步用于将删除所述第一 Via 选项信息后的响应发送到所述第一 Via选项信息对应的设备； 或
当所述响应携带一个所述 Via选项信息时， 且所述装置已存储所述请求对 应的会话的参数和状态时， 则所述装置还包括查找模块 1105。 所述查找模块 1105用于根据所述响应中携带的令牌选项信息查找存储的与所述令牌选项信 息对应的 Via选项信息； 所述处理模块 1102进一步用于删除所述响应中携带的 Via选项信息； 将根据所述令牌选项信息查找到的与所述令牌选项信息对应的 Via选项信息加入所述删除了 Via选项信息的响应；所述发送模块 1103进一步用 于将加入了查找到的与所述令牌选项信息对应的 Via选项信息后的响应发送到 所述加入的与所述令牌选项信息对应的 Via选项信息中的第一 Via选项信息对 应的设备。
进一步的，当所述处理模块 1102已存储所述请求对应的会话的参数和状态 时， 所述发送模块选择所存储的 Via选项信息的第二 Via选项信息作为响应的 Via选项信息， 并将所述响应发送到所述第二 Via选项信息对应的设备。
通过上述方案， 在 CoAP中， 允许有状态代理节点和无状态代理节点可以 在同一会话的传输路径上同时存在，并且通过有状态代理节点将协议报文中的 路径的路由信息删除， 改为本地存储路径的路由信息， 缩短协议报文中携带的 路由信息， 由此提高代理节点资源使用的效率，减少了代理节点繁忙或故障时 引起的通信延误或中断。
图 12是根据本发明另一实施例受限应用协议 CoAP中数据通信的终端的框 图。 作为示例性的实现方式， 图 12的终端执行 CoAP中的终端的功能， 该终端 包括生成模块 1210发送模块 1220和接收模块 1230。
生成模块 1210生成携带路径记录 Via选项信息的请求，其中 Via选项信息用 于记录请求路径和响应路由。
发送模块 1220经向代理节点发送请求，以便于代理节点根据代理节点是否 将存储本次请求对应的会话的参数和状态对应请求进行 Via选项信息的处理。
接收模块 1230接收经代理节点基于所述请求发送的响应。
所述终端实现了方法 800, 具体细节参考方法 800的说明， 此处不再赘述。 通过上述方案， 在 CoAP中， 允许有状态代理节点和无状态代理节点可以 在同一会话的传输路径上同时存在，并且通过有状态代理节点将协议报文中的 路径的路由信息提取后删除， 改为本地存储路径的路由信息， 缩短协议报文中 携带的路由信息， 由此提高代理节点资源使用的效率， 减少了代理节点繁忙或 故障时引起的通信延误或中断。
图 13是根据本发明实施例受限应用协议 CoAP中数据通信的服务器的框 图。 作为示例性的实现方式，服务器包括接收模块 1310、生成模块 1320和发送 模块 1330。
接收模块 1310接收来自终端的经代理节点发送的请求。
生成模块 1320基于请求， 生成携带 Via选项信息的响应， 其中 Via选项信息 用于记录请求路径和响应路由。
发送模块 1330向代理节点发送响应，以便于代理节点根据代理节点是否已 存储请求对应的会话的参数和状态， 对响应进行 Via选项信息的处理， 并向终 端发送经处理后的响应。
服务器实现了方法 900, 具体细节参考方法 900的说明， 此处不再赘述。 通过上述方案， 在 CoAP中， 允许有状态代理节点和无状态代理节点可以 在同一会话的传输路径上同时存在，并且通过有状态代理节点将协议报文中的 路径的路由信息提取后删除， 改为本地存储路径的路由信息， 缩短协议报文中 携带的路由信息， 由此提高代理节点资源使用的效率， 减少了代理节点繁忙或 故障时引起的通信延误或中断。
此外， 本发明上述实施例中的 CoAP终端可以是移动终端， 如各种手机， 笔记本， PDA等移动设备， 也可以是固定终端， 如 PC机等设备。 本发明上述 实施例中的代理节点可以是网络中的网络设备，也可以是计算机等设备。本发 明上述实施例中的服务器可以为服务器。本发明上述实施例的各功能模块都可 以为运行于上述设备的处理器中的功能模块， 本发明在此不做限定。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示 例的模块及算法步骤， 能够以电子硬件、或者计算机软件和电子硬件的结合来 实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用 所描述的功能， 但是这种实现不应认为超出本发明的范围。
所属领域的技术人员可以清楚地了解到， 为描述的方便和简洁， 上述描述 的***、装置和模块的具体工作过程，可以参考前述方法实施例中的对应过程， 在此不再赘述。
在本申请所提供的几个实施例中， 应该理解到， 所揭露的***、 装置和方 法， 可以通过其它的方式实现。 例如， 以上所描述的装置实施例仅仅是示意性 的， 例如， 所述模块的划分， 仅仅为一种逻辑功能划分， 实际实现时可以有另 外的划分方式， 例如多个模块或组件可以结合或者可以集成到另一个***， 或 一些特征可以忽略， 或不执行。 另一点， 所显示或讨论的相互之间的耦合或直 接耦合或通信连接可以是通过一些接口， 装置或模块的间接耦合或通信连接， 可以是电性， 机械或其它的形式。
所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为 模块显示的部件可以是或者也可以不是物理模块， 即可以位于一个地方，或者 也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部 模块来实现本实施例方案的目的。
另外， 在本发明各个实施例中的各功能模块可以集成在一个处理模块中， 也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块 中。
所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用 时， 可以存储在一个计算机可读取存储介质中。基于这样的理解， 本发明的技 术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以 以软件产品的形式体现出来， 该计算机软件产品存储在一个存储介质中， 包括 若干指令用以使得一台计算机设备（可以是个人计算机， 服务器， 或者网络设 备等）执行本发明各个实施例所述方法的全部或部分步骤。 而前述的存储介质 包括： U盘、 移动硬盘、 只读存储器（ROM, Read-Only Memory ) 、 随机存取 存储器（RAM, Random Access Memory ) 、 磁碟或者光盘等各种可以存储程 序代码的介质。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于 此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内， 可轻易想到 变化或替换， 都应涵盖在本发明的保护范围之内。 因此， 本发明的保护范围应 所述以权利要求的保护范围为准。

Claims

权 利 要 求
1. 一种受限应用协议 CoAP中数据通信的方法， 其特征在于， 所述方法包 括：
接收来自终端发送的请求；
根据代理节点是否将存储所述请求对应的会话的参数和状态，对所述请求 进行路径记录 Via选项信息的处理，其中所述 Via选项信息用于记录请求路径和 响应路由；
发送经处理后的请求。
2. 根据权利要求 1所述的方法， 其特征在于， 所述根据代理节点是否将存 储所述请求对应的会话的参数和状态， 对所述请求进行 Via选项信息的处理包 括：
当所述代理节点不存储与所述请求对应的会话的参数和状态时，所述代理 节点为无状态代理节点，所述无状态代理节点在所述请求中增加 Via选项信息； 并发送增加了所述 Via选项信息的请求； 或
当所述代理节点将存储所述请求对应的会话的参数和状态时，所述代理节 点为有状态代理节点， 所述有状态代理节点存储所述请求中的 Via选项信息， 删除所述请求中的 Via选项信息， 并发送删除了所述 Via选项信息的请求。
3. 根据权利要求 2 所述的方法， 其特征在于：
在所述请求中， 当使用请求的源地址作为 Via选项信息时， 所述无状态代 理节点使用所述请求的源地址作为增加的所述 Via选项信息， 或， 所述有状态 代理节点将所述请求的源地址增加到所存储的 Via选项信息中； 或
在所述请求中， 当使用代理节点的地址作为 Via选项信息时， 所述无状态 代理节点使用所述无状态代理节点的地址作为增加的所述 Via选项信息， 或， 所述有状态代理节点在删除所述请求中的 Via选项信息后， 将所述有状态代理 节点的地址增加在删除了 Via选项信息后的请求中。
4. 根据权利要求 3所述的方法， 其特征在于， 所述方法还包括：
当接收到的所述来自终端发送的请求为直接由所述终端发送的请求，并确 定第一 Via选项信息和所述请求的源地址不一致时，则将所述第一 Via选项信息 修改成所述请求的源地址。
5. 根据权利要求 1-4任一所述的方法， 其特征在于， 所述方法还包括： 接收来自所述服务器的基于所述请求的响应 ,以便于向所述终端发送所述 响应。
6. 根据权利要求 5所述的方法， 其特征在于：
当所述响应携带多个 Via选项信息时， 则所述无状态代理节点删除所述响 应中携带的第一 Via选项信息并将删除了所述第一 Via选项信息的响应发送到 剩余 Via选项信息中的第一 Via选项信息对应的设备。
7. 根据权利要求 5所述的方法， 其特征在于：
当所述响应携带 Via选项信息时， 所述无状态代理节点删除所述响应中的 第一 Via选项信息， 并将删除了第一 Via选项信息的响应发送到所述第一 Via选 项信息对应的设备。
8. 根据权利要求 5所述的方法， 其特征在于：
当所述响应未携带所述 Via选项信息时， 则所述有状态代理节点根据所述 响应中的令牌选项信息查找本地存储的与所述令牌选项信息对应的 Via选项信 息， 将根据所述令牌选项信息查找到的存储的 Via选项信息加入所述响应， 删 除加入的 Via选项信息中的第一 Via选项信息， 以及将删除所述第一 Via选项信 息后的响应发送到所述第一 Via选项信息对应的设备； 或
当所述响应携带一个所述 Via选项信息时， 则有状态代理节点删除所述响 应中携带的 Via选项信息， 根据所述响应中携带的令牌选项信息查找存储的与 所述令牌选项信息对应的 Via选项信息， 将根据所述令牌选项信息查找到的与 所述令牌选项信息对应的 Via选项信息加入所述删除了 Via选项信息的响应，并 将加入了查找到的与所述令牌选项信息对应的 Via选项信息后的响应发送到所 述加入的与所述令牌选项信息对应的 Via选项信息中的第一 Via选项信息对应 的设备。
9. 根据权利要求 8所述的方法， 其特征在于：
所述有状态代理节点选择所存储的 Via选项信息的第二 Via选项信息作为 响应的 Via选项信息，并将所述响应发送到所述第二 Via选项信息地址对应的设 备。
10. 一种受限应用协议 CoAP中数据通信的方法， 其特征在于， 所述方法 包括：
生成携带路径记录 Via选项信息的请求，所述 Via选项信息用于记录请求路 径和响应路由；
向代理节点发送所述请求 ,以便于所述代理节点根据所述代理节点是否将 存储所述请求对应的会话的参数和状态，对所述请求进行 Via选项信息的处理； 以及
接收经所述代理节点的基于所述请求发送的响应。
11. 一种受限应用协议 CoAP中数据通信的方法， 其特征在于， 所述方法 包括：
接收来自终端的经代理节点发送的请求；
基于所述请求， 生成携带路径记录 Via选项信息的响应， 其中所述 Via选项 信息用于记录请求路径和响应路由；
向所述代理节点发送所述响应，以便于所述代理节点根据所述代理节点是 否已存储所述请求对应的会话的参数和状态， 对所述响应进行 Via选项信息的 处理， 并向所述终端发送经处理后的响应。
12. 一种受限应用协议 CoAP数据通信的装置， 其特征在于， 所述装置包 括：
接收模块， 用于接收来自终端发送的请求；
处理模块，用于根据所述装置是否将存储所述请求对应的会话的参数和状 态对所述请求进行路径记录 Via选项信息的处理，其中所述 Via选项信息用于记 录请求路径和响应路由；
发送模块， 用于发送经处理后的请求。
13. 根据权利要求 12所述的装置， 其特征在于，
所述处理模块具体用于当所述装置不存储所述请求对应的会话的参数和 状态时， 在所述请求中增加 Via选项信息； 所述发送模块具体用于发送增加了 所述 Via选项信息的请求； 或
所述处理模块具体用于当所述装置将存储所述请求对应的会话的参数和 状态时， 存储所述请求中的 Via选项信息， 并删除所述请求中的 Via选项信息； 所述发送模块具体用于发送删除了所述 Via选项信息的请求。
14. 根据权利要求 13所述的装置， 其特征在于，
当所述请求中使用请求的源地址作为 Via选项信息时， 如果所述装置不存 储所述请求对应的会话的参数和状态，所述处理模块使用所述请求的源地址作 为增加的所述 Via选项信息； 或如果所述装置将存储所述请求对应的会话的参 数和状态，所述处理模块将所述请求的源地址增加到所存储的 Via选项信息中； 或
当所述请求中使用装置的地址作为 Via选项信息时， 如果所述装置不存储 所述请求对应的会话的参数和状态，所述处理模块使用所述装置的地址作为增 加的所述 Via选项信息； 或如果所述装置将存储所述请求对应的会话的参数和 状态， 所述处理模块在删除所述请求中的 Via选项信息后， 将所述装置的地址 增加在删除了 Via选项信息后的请求中。
15. 根据权利要求 14所述的装置， 其特征在于， 当所述接收模块接收到所 述终端的请求时， 所述装置还包括：
确定模块， 用于当确定第一 Via选项信息和所述请求的源地址不一致时， 将所述第一 Via选项信息修改成所述请求的源地址。
16. 根据权利要求 12-15任一所述的装置， 其特征在于，
所述接收模块， 进一步用于接收来自所述服务器的基于所述请求的响应， 以便于向所述终端发送所述响应。
17. 根据权利要求 16所述的装置， 其特征在于， 当所述响应携带多个 Via 选项信息时：
所述发送模块，进一步用于当所述装置未存储所述请求对应的会话的参数 和状态时， 删除所述响应中携带的第一 Via选项信息， 并将删除了所述第一 Via 选项信息的响应发送到剩余 Via选项信息中的第一 Via选项信息对应的设备。
18. 根据权利要求 16所述的装置， 其特征在于， 当所述响应携带 Via选项 信息时：
所述发送模块，进一步用于当所述装置未存储所述请求对应的会话的参数 和状态时， 删除所述响应中的第一 Via选项信息， 并将删除了所述第一 Via选项 信息的响应发送到所述第一 Via选项信息对应的设备。
19. 根据权利要求 16所述的装置， 其特征在于， 当所述响应未携带所述 Via选项信息， 且所述装置已存储所述请求对应的 会话的参数和状态时， 则所述装置还包括： 查找模块， 用于根据所述响应中的 令牌选项信息查找本地存储的与所述令牌选项信息对应的 Via选项信息； 并且 所述处理模块进一步用于将根据所述令牌选项信息查找到的存储的 Via选项信 息加入所述响应， 删除加入的 Via选项信息中的第一 Via选项信息； 所述发送模 块进一步用于将删除所述第一 Via选项信息后的响应发送到所述第一 Via选项 信息对应的设备； 或
当所述响应携带一个所述 Via选项信息时， 且所述装置已存储所述请求对 应的会话的参数和状态时， 则所述装置还包括： 查找模块， 用于根据所述响应 中携带的令牌选项信息查找存储的与所述令牌选项信息对应的 Via选项信息； 所述处理模块， 进一步用于删除所述响应中携带的 Via选项信息； 将根据所述 令牌选项信息查找到的与所述令牌选项信息对应的 Via选项信息加入所述删除 了 Via选项信息的响应； 所述发送模块进一步用于将加入了查找到的与所述令 牌选项信息对应的 Via选项信息后的响应发送到所述加入的与所述令牌选项信 息对应的 Via选项信息中的第一 Via选项信息对应的设备。
20. 根据权利要求 19 所述的装置， 其特征在于：
当所述处理模块已存储所述请求对应的会话的参数和状态时，所述发送模 块选择所存储的 Via选项信息的第二 Via选项信息作为响应的 Via选项信息， 并 将所述响应发送到所述第二 Via选项信息对应的设备。
21. 一种受限应用协议 CoAP中数据通信的终端， 其特征在于， 所述装置 包括：
生成模块， 用于生成携带路径记录 Via选项信息的请求， 所述 Via选项信息 用于记录请求路径和响应路由；
发送模块， 用于向代理节点发送所述请求， 以便于所述代理节点根据所述 代理节点是否将存储所述请求对应的会话的参数和状态， 对所述请求进行 Via 选项信息的处理；
接收模块， 用于接收经所述代理节点的基于所述请求发送的响应。
22. 一种受限应用协议 CoAP中数据通信的服务器， 其特征在于， 所述装 置包括： 接收模块， 用于接收来自终端的经代理节点发送的请求；
生成模块， 用于基于所述请求， 生成携带路径记录 Via选项信息的响应， 其中， 所述 Via选项信息用于记录请求路径和响应路由；
发送模块， 用于向所述代理节点发送所述响应， 以便于所述代理节点根据 所述代理节点是否已存储所述请求对应的会话的参数和状态，对所述响应进行 Via选项信息的处理， 并向所述终端发送经处理后的响应终端。
PCT/CN2012/073539 2011-07-14 2012-04-05 受限应用协议中数据通信的方法和装置 WO2012167659A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201110197032.1 2011-07-14
CN2011101970321A CN102882906A (zh) 2011-07-14 2011-07-14 受限应用协议中数据通信的方法和装置

Publications (1)

Publication Number Publication Date
WO2012167659A1 true WO2012167659A1 (zh) 2012-12-13

Family

ID=47295455

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2012/073539 WO2012167659A1 (zh) 2011-07-14 2012-04-05 受限应用协议中数据通信的方法和装置

Country Status (2)

Country Link
CN (1) CN102882906A (zh)
WO (1) WO2012167659A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110808950A (zh) * 2019-09-25 2020-02-18 西安广和通无线软件有限公司 消息处理方法、装置、计算机设备和存储介质

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105227525B (zh) * 2014-06-17 2018-07-13 阿尔卡特朗讯 用于基于信令的物联网设备的ip通信方法与设备
CN104917828B (zh) * 2015-05-28 2018-04-27 重庆邮电大学 一种基于节点休眠和路由维护的CoAP协议代理缓存方法
CN106656730A (zh) * 2015-10-30 2017-05-10 西门子公司 一种通信方法、装置和***
CN107104925A (zh) * 2016-02-22 2017-08-29 西门子公司 用于安全通信的方法、装置及***

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050259633A1 (en) * 2004-05-18 2005-11-24 Fujitsu Limited Communication path control program and communication path control device in computer network system
CN101124785A (zh) * 2005-03-04 2008-02-13 思科技术公司 用于网络可达性检测的***和方法
CN101252410A (zh) * 2008-04-10 2008-08-27 中国电子科技集团公司第三十研究所 一种减少ip路由协议带宽占用量的方法
CN102014129A (zh) * 2010-11-22 2011-04-13 华为技术有限公司 一种在CoAP网络中注册的方法及装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7746796B2 (en) * 2006-09-29 2010-06-29 Cisco Technology, Inc. Directed echo requests and reverse traceroute
CN101212418B (zh) * 2006-12-31 2010-05-12 华为技术有限公司 背靠背用户代理及其传输信息的方法
US7693060B2 (en) * 2007-10-12 2010-04-06 Cisco Technology, Inc. Method and apparatus for a reservation reflector function in routers

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050259633A1 (en) * 2004-05-18 2005-11-24 Fujitsu Limited Communication path control program and communication path control device in computer network system
CN101124785A (zh) * 2005-03-04 2008-02-13 思科技术公司 用于网络可达性检测的***和方法
CN101252410A (zh) * 2008-04-10 2008-08-27 中国电子科技集团公司第三十研究所 一种减少ip路由协议带宽占用量的方法
CN102014129A (zh) * 2010-11-22 2011-04-13 华为技术有限公司 一种在CoAP网络中注册的方法及装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110808950A (zh) * 2019-09-25 2020-02-18 西安广和通无线软件有限公司 消息处理方法、装置、计算机设备和存储介质
CN110808950B (zh) * 2019-09-25 2022-06-28 西安广和通无线软件有限公司 消息处理方法、装置、计算机设备和存储介质

Also Published As

Publication number Publication date
CN102882906A (zh) 2013-01-16

Similar Documents

Publication Publication Date Title
KR102056416B1 (ko) 무선 네트워크에서 디바이스들 간의 터널 다이렉트 링크 설정(tdls) 세션을 확립하는 방법들 및 장치들
US8261339B2 (en) Dynamic network tunnel endpoint selection
JP5847191B2 (ja) コンテンツ共有を行う中間ノード及びコンテンツリクエスト端末並びにそれらのコンテンツ共有方法
US10313402B2 (en) Single pass load balancing and session persistence in packet networks
US9247018B2 (en) Method and apparatus for cooperation between push devices
US9392081B2 (en) Method and device for sending requests
WO2021143239A1 (zh) 路由控制方法、装置、电子设备和存储介质
RU2464722C2 (ru) Способ, устройство и система для распределения сообщений
JP2022550165A (ja) ローミング・シグナリング・メッセージ送信方法、関連するデバイス、および通信システム
EP2466856A1 (en) Service realizing method and service system
WO2013044671A1 (zh) 访问互联网的方法、终端以及存储介质
WO2013107137A1 (zh) 心跳周期的获取方法及终端、服务器
WO2012167659A1 (zh) 受限应用协议中数据通信的方法和装置
WO2011160587A1 (zh) 一种双栈终端连接网络的方法及***
WO2019201072A1 (zh) Cdn业务调度处理方法及cdn服务器
WO2012034414A1 (zh) 一种处理p2p业务的方法及***
WO2022179218A1 (zh) 一种通信方法及装置
WO2012088934A1 (zh) 一种报文过滤方法和交换设备
WO2017161866A1 (zh) 网络连接方法及装置
CN114244850B (zh) 数据包处理方法、装置、计算机设备和存储介质
CN108713336B (zh) 用户设备标识与信息中心联网请求的相关性
WO2012088828A1 (zh) 表维护方法、***和接入网关路由器
JP4013920B2 (ja) 通信システム、通信装置及びその動作制御方法並びにプログラム
WO2012136094A1 (zh) 一种对等网络中控制过负荷的方法及***
WO2015135124A1 (zh) 一种信息传送方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12797250

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12797250

Country of ref document: EP

Kind code of ref document: A1