CN102685204A - Method and equipment for transmitting data resource - Google Patents
Method and equipment for transmitting data resource Download PDFInfo
- Publication number
- CN102685204A CN102685204A CN2012100564560A CN201210056456A CN102685204A CN 102685204 A CN102685204 A CN 102685204A CN 2012100564560 A CN2012100564560 A CN 2012100564560A CN 201210056456 A CN201210056456 A CN 201210056456A CN 102685204 A CN102685204 A CN 102685204A
- Authority
- CN
- China
- Prior art keywords
- response
- message
- option
- time
- 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
Links
Images
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
- 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/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/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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
The embodiment of the invention relates to a method for transmitting a data resource and equipment for transmitting the data resource. The method for transmitting the data resource in an internet of things system based on a node of a lightweight application layer protocol comprises the steps of: sending a request message with a response mode option to a server, wherein the response mode option shows one of the following response modes: once immediate response, delayed once response, delayed multi-response, and cancelling of delayed multi-response; and receiving the response message transmitted by the server and produced according to the response mode option. According to the method and the equipment for transmitting data resource, the response mode option can be specified in the message interaction process; the client can specify the response as required, thereby improving the message interaction efficiency of CoAP.
Description
Technical field
The embodiment of the invention relates to network communication field, and relates more specifically to the method and apparatus of data resource transmission.
Background technology
Lightweight application layer protocol (Constrained Application Protocol; Be called for short " CoAP ") mainly be to be used for Internet of Things (Machine to Machine; Abbreviation " M2M ") in the scene, such as: tame chamber controller, building automatic, intelligent energy, sensor network etc.In such environment, the function of these machines is fairly simple, and general processor has only 8, and memory space is little, does not support complicated host-host protocol, and message transmission rate is also lower.CoAP provides a kind of interactive mode of request, supports embedded resource discovering, comprises crucial webpage notion, such as unified resource sign (URI) and content type.CoAP can translate hypertext link agreement (HTTP) at an easy rate, is used for being integrated into network.Based on the accurate capacity of calculated data resource not in the traditional scheme of CoAP transmission data, can't assess the exact number of subpackage, therefore can't concurrently obtain data resource, cause efficiency of transmission low.
In addition because a lot of device processes ability of CoAP of using is lower; Peak transfer rate is also low; So when activating a plurality of connections or handling a plurality of request simultaneously, CoAP equipment just is easy to face congestion problems, causes in time handling follow-up de novo task.Congested in order to solve; Stipulated a kind of message retransmission controlling mechanism in the existing CoAP agreement; (Confirmable) message that the needs that send to server apparatus when the CoAP client device are confirmed and when not meeting with a response for a long time (congested etc. problem cause); Client device can be retransmitted this message and repeated several times at Tn after second, limit and abandon attempting up to receiving the response message that server apparatus is beamed back or reaching maximum number of retransmissions; If the acquiescence retransmission interval be x second and current be the n time the repeating transmission, then Tn=x+random (0~2
n), wherein random (0~2
n) be 0 to 2
nBetween arbitrary random integers, so this method also is called as the exponential back algorithm, each time interval of retransmitting gives server apparatus the looser response time with exponential increase.But the algorithm that prior art is used is based on time slot, and the congested control of message level can not effectively solve other congestion problems of node level; When server reaches bottleneck because of the resource disposal ability; Perhaps take place unusual the time, exponential back has just seemed an utterly inadequate amount, and because be the random algorithm of client end; Do not consider the concrete state of server fully, further aggravate congestion in the time of serious yet.
Summary of the invention
The embodiment of the invention provides a kind of method and apparatus of data resource transmission, can be supported in and improve efficiency of transmission among the CoAP.
In embodiments of the present invention; Provide a kind of in Internet of things system the data resource transmission method based on the node of lightweight application layer protocol; Comprise: send the request message that carries the response mode option to server, wherein said response mode option is represented wherein one of following response mode: a plurality of responses that a plurality of responses of the disposable disposable response that makes an immediate response, postpones, postponement and cancellation are postponed; Receive the response message that said server sends according to said response mode option generation
In embodiments of the present invention; Provide a kind of in Internet of things system the data resource transmission method based on the node of lightweight application layer protocol; Comprise: receive the request message that carries the response mode option that client is sent, wherein said response mode option is represented wherein one of following response mode: a plurality of responses that a plurality of responses of the disposable disposable response that makes an immediate response, postpones, postponement and cancellation are postponed; Send the response message that generates according to said response mode option to client.
In embodiments of the present invention; Provide a kind of in Internet of things system the client based on the data resource of lightweight application layer protocol transmission node; Comprise: sending module; Be used for sending the request message that carries the response mode option to server, wherein said response mode option is represented wherein one of following response mode: a plurality of responses that a plurality of responses of the disposable disposable response that makes an immediate response, postpones, postponement and cancellation are postponed; Receiver module is used to receive the response message that generates according to the response mode option.
In embodiments of the present invention; Provide a kind of in Internet of things system the server apparatus based on the data resource of lightweight application layer protocol transmission node; Comprise: receiver module; Be used to receive the request message that carries the response mode option that client is sent, wherein said response mode option is represented wherein one of following response mode: a plurality of responses that a plurality of responses of the disposable disposable response that makes an immediate response, postpones, postponement and cancellation are postponed; Sending module sends the response message that generates according to said response mode option to said client.
According to the embodiment of the invention, through specified response mode option in message interaction process, client can be specified required response, has improved the interacting message efficient of CoAP.
According to the embodiment of the invention, can indicate response mode, and receive response message according to indicated response mode; Be convenient to the requesting party like this and carry out the session processing; With the raising efficiency of transmission, such as: under the situation of indication lag response time, avoid requesting party's wait-for-response message always; Can cross after date, end session in advance in the time of delay of indication; When requesting party's indication makes an immediate response,, also can shift to an earlier date end session if in the self-defining time-out time of requesting party, can not receive response message; When the repeatedly response of indication lag, the requesting party can preserve the information of resource subscription, so that receive the response of a plurality of postponements.
Description of drawings
In order to be illustrated more clearly in the technical scheme of the embodiment of the invention; To do to introduce simply to the accompanying drawing of required use in embodiment or the description of the Prior Art below; Obviously, the accompanying drawing in describing below only is some embodiments of the present invention, for those of ordinary skills; Under the prerequisite of not paying creative work property, can also obtain other accompanying drawing according to these accompanying drawings.In the accompanying drawings:
Fig. 1 is the flow chart of method of the transmission data of an embodiment of the present invention;
Fig. 2 is the gateway of an embodiment of the present invention obtains the concrete implementation procedure of data resource from transducer a flow chart;
Fig. 3 is the structure chart of improved burst option in an embodiment of the present invention;
Fig. 4 is the gateway of a kind of alternate embodiment of the present invention obtains the concrete implementation procedure of data resource from transducer a flow chart;
Fig. 5 is the structure chart of improved burst option in a kind of alternate embodiment of the present invention;
Fig. 6 is the gateway of a kind of alternate embodiment of the present invention obtains the concrete implementation procedure of data resource from transducer a flow chart;
Fig. 7 is the structure chart of improved burst option in a kind of alternate embodiment of the present invention;
Fig. 8 is that the gateway of an embodiment of the present invention sends the flow chart of the concrete implementation procedure of data resource to transducer;
Fig. 9 is the block diagram of the client device of an embodiment of the present invention;
Figure 10 is the block diagram of the server apparatus of an embodiment of the present invention;
Figure 11 is the flow chart of method of the transmission data of an embodiment of the present invention;
Figure 12 is the flow chart of method of the transmission data of an embodiment of the present invention;
Figure 13 is the interacting message figure of an embodiment of the present invention;
Figure 14 is the interacting message figure of an embodiment of the present invention;
Figure 15 is the interacting message figure of an embodiment of the present invention;
Figure 16 is the structure chart of client of the transmission data of an embodiment of the present invention;
Figure 17 is the structure chart of server of the transmission data of an embodiment of the present invention.
Embodiment
To combine the accompanying drawing in the embodiment of the invention below, the technical scheme in the embodiment of the invention is carried out clear, intactly description, obviously, described embodiment is the present invention's part embodiment, rather than whole embodiment.Based on the embodiment among the present invention, those of ordinary skills are not making the every other embodiment that is obtained under the creative work prerequisite, all belong to the scope of the present invention's protection.
CoAP is based on UDP (User Datagram Protocol is called for short " UDP ") and transmits, and is based on connectionless Message Processing pattern.Its interactive mode can be synchronous response, also can be asynchronous response.Type of message can be: the message (Confirmable), the message (Non-confirmable) that need not confirm, acknowledge message (Acknowledgement), the replacement message (Reset) that need affirmation.Message identifier (Message ID) be can pass through and related a pair of request and response come.
The method that CoAP supports has four: obtain resource (Get), more new resources (Put), establishing resource (Post) and delete resource (Delete).Resource shifts (Representational State Transfer is called for short " REST ") URI through the statement sexual state and discerns.We claim that usually the side of having of resource is node or server, include but not limited to transducer, controller, end points (End-point) etc., and request resource side is a client, includes but not limited to gateway (Proxy), network equipment.
The CoAP agreement is supported different options (Option); In order to explain the semanteme of data in the CoAP message body; Such as Block (burst), Location (position), Token (token) option etc.; Different options is supported different functions, and can expand new function through defining new Option.
CoAP supports burst option (Block Option), is mainly used in bigger resource is carried out slicing transmission, to be adapted to the application scenarios of low bandwidth transmission.The Block option can be chosen according to the needed length of the capacity of burst number for 1 byte, 2 bytes or 3 bytes.
The accurate capacity of calculated data resource not in the traditional scheme can't be assessed the exact number of subpackage, therefore can't concurrently obtain.Do not know that in addition resource is static state or dynamic yet.
In the following description, claim that usually the side of having of resource is server, with transducer as an example, request resource side is a client, with gateway as an example.But, need not the oppose restriction of server or client of transducer or gateway.
Owing to do not know the accurate capacity of target resource, when gateway uses Block Option in < Get>order, can only obtain in order, i.e. Block 0 is obtained in choosing, when waiting Block 0 to return, obtains Block1 again, until last Block.Can not send < Get>request concomitantly.
The field structure of Block option generally comprises the NUM field, M field and SZX field, wherein
NUM representes the order sequence number of burst, can be 4~20 unsigned int numeral.0 first burst of expression.
M: represent with a bit whether current burst back also has other bursts, its value is that 1 expression back also has burst, is that 0 expression back does not have burst, is last burst.
SZX: be used to characterize the burst capacity, its computing formula is: burst capacity=2^ (SZX+4), i.e. (SZX+4) power of 2.Because SZX representes that by 3 bits its value can be 0~7, thus the span of burst capacity: 2^4~2^11, promptly 16~2048.
Operation instruction for the Block option is following:
In < Get>request, the NUM field of Block option provides the sequence number of the burst of current request, and when the burst sequence number was 0, SZX provided the capacity of each burst of gateway suggestion.In < Get>response or in < Put >/< Post>request, the sequence number of the burst of the current transmission of NUM field description of Block option, M field show whether the back also has follow-up burst.
In < Put >/< Post>response, the NUM field of Block option shows the burst sequence number of current response.
When gateway uses < Get>method to obtain first burst (Block); NUM is set to 0, and carries the burst capacity (being SZX) of suggestion, and sensor node can select to agree the burst capacity of advising; Or select one than the little burst of suggestion burst; And in response, return, simultaneously, in response, return the data of first burst.
The present invention considers that gateway knows the accurate capacity of target resource in advance; Then gateway can select whether to send with Block Option the request of resource acquisition, also can realize concurrent request, promptly in request Block0; Also can ask Block 1, and needn't wait for.On the order of request Block, also can handle flexibly.
In the simple design, Block Option has three selections, can be a byte, can be 2 bytes, also can be three bytes, and different according to the capacity of resource, the quantity capacity of burst (Block) is different, and needed length is also different.The agreement regulation, except last burst, the capacity of burst must be identical, but in each transmission, still all need carry M position (showing whether the back also has burst) and SZX (capacity of burst) at every turn.
In request and response, M position and SZX position all need to transmit at every turn, and in fact, except last burst, the value of M position and SZX all is identical at every turn, the transmission waste transfer resource of repetition.The purpose supposition both sides that repeat to send SZX do not preserve the SZX after the negotiation, and that carry in the response for the first time is the SZX after consulting, and gateway obtains and in request, sends once more from response, thereby gateway and transducer do not need preservation state.In request response rounds once, waste a byte altogether, if when the burst number is a lot, just it is enough for the byte of waste, and for M2M equipment, transfer resource is limited, and the waste of this transfer resource is very considerable.Suppose that the data that will transmit are 64M, the load of each Block (payload) capacity is that the block entry number that 1024byte then sends is: 65536.The number that the Block option that then sends divides according to byte is:
(1) byte: 16
(2) two bytes: 4080
(3) three bytes: 61440
If M and SZX can not send, then request adds that the data that response can be saved are 65536 bytes (byte), i.e. 64K data.In addition, if these two fields are not, then the NUM field can be used full all positions (bit), and the number of the packet that then need send changes to:
(1) byte: 256
(2) two bytes: 65280
Need not send the structure of 3 bytes this moment, therefore can also save data is 61440*2bytes, i.e. the 60K data.Then save data bit 124K altogether, save data transfer rate 0.189%.It is (16+4080*2+61440*3-256-65280*2)/(16+4080*2+61440*3)=61680/192496=32% that header field is saved percentage.
Save the formula of data volume:
T is total Block quantity, and S is burst capacity (Block Size), the percentage of the flow of saving (only comparing header field):
T<16 o'clock: do not have and save; The both is a byte;
16<T<256 o'clock: 1-T*1/ (16*1+ (T-16) * 2), simple design needs 2 bytes, and preferred version only needs a byte;
256<T<4096 o'clock: 1-(256*1+ (T-256) * 2))/(16*1+ (T-16) * 2), simple design needs 2 bytes, and preferred version needs 2 bytes;
4096<T<65256 o'clock: 1-(256*1+ (4096-256) * 2+ (T-4096) * 3))/(256*1+ (T-256) * 2), simple design needs 3 bytes, and preferred version needs 2 bytes.
T>65256 o'clock do not have and save, and preferred version embodiment of the present invention and simple design all need 3 bytes.
In the simple design, when using the Put/Post order, the burst capabilities negotiation lacks efficient.In the Put/Post request; For first burst; Need to send the data of first burst and the burst capacity of recommendation; If sensor node is selected different burst capacity, gateway need resend according to the burst capacity of transducer, and the fragment data that then sent last time has been wasted.And gateway in advance can't sensor resource capacity information when using the Put/Post request to send resource capacious based on the burst option; In transmission course, the transducer edge joint is received, the resource that the limit buffer memory is received; If transducer is found insufficient memory, and resource is not transmitted when accomplishing, and can only send it back one 413 error status code; The expression requested resource is too big, finishes transmission this time.The part resource of transmission is then useless before this, and transfer resource has been wasted.If gateway can be in first fragmental messages sensor the capacity information of the resource that will transmit; Transducer then can compare resource capacity information and memory capacity; If off-capacity; Return the conditional code of 413 " requested resource is too big " in advance, come the ending resource transmission, reach the purpose of saving transfer resource with this.
Breakpoint transmission on the Internet just will begin from the place that file has been downloaded to continue to download.Gateway will be added the scope (Range) that an information representes to ask data download in the transducer request msg, shows wherefrom to begin.
Such as, gateway transmits solicited message with browser and gives the Web transducer, requires since 2000070 bytes:
GET/down.zip?HTTP/1.0
User-Agent:NetFox
Range:bytes=2000070-
Accept:text/html,image/gif,image/jpeg,*;q=.2,*/*;q=.2
Wherein, RANGE:bytes=2000070-, the meaning of this delegation is exactly to tell transducer down.zip that this file passes since 2000070 bytes, and the byte of front need not pass.
The shortcoming of this scheme is, do not have burst mechanism, do not support the negotiation of burst capacity, also do not support the negotiation of burst sum.The embodiment of the invention has been considered in the slicing transmission process, carries out the negotiation of burst capacity and/or burst sum.The invention provides a kind of method of data fragmentation transmission for this reason, can obtain the accurate capacity of target data resource, carry out the negotiation of burst capacity, obtain the burst sum, and carry out the data resource transmission according to the burst sum.
The following flow process that specifies an embodiment of the present invention with reference to Fig. 1.Fig. 1 is the flow chart of an embodiment of the present invention.
In the S110 process, obtain the capacity information of the data resource of node.If gateway obtains data from transducer, then the data resource capacity information of node is kept on the transducer.Gateway can pass through request message, obtains the capacity information of the data resource of node to transducer.If gateway sends data to transducer, then gateway local has been known the capacity information of the data resource of node.Obtaining the data resource capacity information of node, is to prepare for next step negotiation and definite burst sum that carries out the burst capacity.
Then, in the process of S120, gateway sends the request message that carries the first burst option to transducer, and the wherein said first burst option comprises the burst capacity of recommendation.After the request message that transducer sends,, confirm employed burst capacity in this data resource transmission course according to self-ability in receiving S120, and the burst capacity recommended smaller or equal to gateway of the burst capacity confirmed of transducer.
At S130, gateway receives the response message carry the second burst option, and the wherein said second burst option comprises definite burst capacity, and said definite burst capacity is smaller or equal to the burst capacity of said recommendation.Gateway is after receiving definite burst capacity, and according to the data resource capacity information of the node of grasping, the burst of the data resource of definite node that will transmit is total.
Then, at S140, according to the said definite burst capacity and the data resource capacity information of said node, the said data resource of slicing transmission.
According to the embodiment of the invention, can know the capacity information of the data resource that needs transmission, and the burst capacity that uses when confirming the transmission data through the burst capabilities negotiation, can realize that thus error rate reduces in the transmission course, and can transmit data concomitantly.
The concrete implementation procedure of embodiment as shown in Figure 1 is described below in conjunction with Fig. 2.Fig. 2 representes, and to be gateway obtain the illustrated examples of data from transducer, is merely explanation design of the present invention, and not as limitation of the present invention.
Data resource acquisition process shown in Figure 2 specifically describes as follows:
ES210: gateway sends the resource discovering request to transducer, promptly obtains the Resources list on the transducer through Get./wellknown/core.
ES220: transducer returns the Resources list to gateway, and resource indication information; Resource indication information mainly comprises addressing information (being URI), resource name, resource description information, content type of resource etc.The present invention expands resource indication information, and the resource indication information of expansion comprises: resource is the dynamic resource or the indication information of static resource.
ES230: the Resources list that gateway returns according to transducer, according to the indication information of resource, select target resource therefrom, and, obtain target resource according to identification marking (information that can unique recognition resource is such as resource name, URI etc.).
ES240: transducer is judged the target resource capacity, gives gateway if resource capacity, then directly returns resource content less than the capacity of a transport level messages; If resource capacity surpasses the capacity of a transport level messages, then return resource capacity information.Alternatively, transducer can use the burst option, and the burst capacity according to self confirming directly returns first burst.Subsequent client and transducer use the following burst of burst option transmission according to this burst capacity of confirming.
In a kind of alternate embodiment of the present invention, if the target data resource is the dynamic data resource, returns the dynamic data resource simultaneously and indicate, and use the Block option to obtain resource with the conditional code indication gateway of 413 " request resource is too big " to gateway.
If data resource is a dynamic resource, what then the resource capacity in the indication information was represented is the capacity information of current resource snapshot (Snapshot), and transducer needs this snapshot data of buffer memory; If static resource, then the resource capacity information in the indication information is accurate capacity information.It should be appreciated by those skilled in the art that then transducer can send the check code of resource snapshot if data resource is a dynamic resource, the data that gateway is fresher if desired, the new acquisition request conforms of can follow-uply redispatching.
ES250: gateway is according to the data resource capacity information, and judgement needs to use the burst option, and sends the request message that carries the burst option, carries out the burst capabilities negotiation with the transducer device, the burst capacity that indication is recommended.
ES260: transducer is confirmed the burst capacity according to self-ability, and it is returned to gateway.Alternatively, transducer returns the burst sum simultaneously.Certainly, because gateway has obtained the data resource capacity information, the burst sum also can be confirmed by gateway.Need to prove that the burst capacity that transducer is confirmed can only be less than or equal to the burst capacity that gateway is recommended.
ES270: gateway until burst is total, sends request, the fragment data of the data resource that acquisition request is corresponding with the burst sequence number to transducer from 1 successively.
ES280: transducer returns the fragment data that this burst sequence number reaches the data resource corresponding with this burst sequence number, up to complete end of transmission according to the burst capacity of confirming.
According to a kind of preferred embodiment of the present invention, can realize parallel processing among the ES270, i.e. gateway a plurality of fragmental messages of acquisition request simultaneously, and need not wait for that transducer returns the response message to previous burst request message.
The code of ES210 to ES240 for example is:
REQ:GET/.well-known/core---transmit a request to the URI of acquiescence, and promptly root obtains the Resources list;
RES:200OK--response identification obtains success, and has carried 2 groups of resource indication information;
</sensors/temp>Ct=41; N=" TemperatureC ",--the temperature resource, content type 41, name is called TemperatureC;
</sensors/light>Ct=41; N=" LightLux " '--light resource, content type 41, name is called LightLux;
</sensors/firmware>Ct=52; N=" firmware "; The snapshot=0--firmware resource, content type 52, name is called firmware, non-dynamic resource;
</sensors/log>Ct=52; N=" log "; The snapshot=1--firmware resource, content type 52, name is called log, dynamic resource, current data is snapshot snapshot;
REQ:GET/sensors/firmware-asks firmware resource
RES:413 " Request Entity Too Large " Size:88000.413 conditional code shows that requested resource is too big, and its accurate capacity is 88000 bytes.
If data resource is a dynamic resource, promptly data resource for example can adopt following two kinds of scheme implementations to handle in the process meeting dynamic change of transmission:
(1) when beginning to transmit data resource, this resource is set up snapshot (Snapshot), i.e. the buffer memory capacity information of this data resource this moment, and transmit this capacity information, no matter follow-up variation; Corresponding such scheme.
(2) if data resource is modified in transmission course, transducer can return error code in the response message of any one request message that obtains data resource, and the designation data resource is changed, and gateway need obtain again.
Alternatively, gateway and transducer increase authentication information in interacting message.The key information (Digest) that can comprise identify label (ID) in the authentication information, calculate based on identify label and password (Password).Identify label and password can be pre-configured give gateway and transducer both sides.Layoutprocedure:
For example, the algorithm of key can be Digest=MD5 (ID:Password), and the character string of promptly ID and Password being formed uses the MD5 algorithm to carry out Hash (Hash), and the value of Hash is Digest.Transmit leg sends ID and Digest, and the recipient draws Digest according to the Password that receives ID and store in advance according to same algorithm, and the Digest that sends with transmit leg compares, if consistent, then authentication is passed through.
When gateway obtains data resource from transducer, as shown in Figure 2, need know the data resource capacity information.According to an embodiment of the present invention, the data resource capacity information that gateway can adopt following scheme to obtain to be stored in transducer.
(1) expansion link form (Link-format) keyword
In Link-format, expand a keyword ,-sn, or-snapshot, be used for obtaining the data resource request responding, show whether resource data is snapshot data.If this parameter does not exist, or its value is 0, shows it is static resource, if the value of this parameter is 1, then shows it is that current data is a dynamic resource, and the data of obtaining are current snapshots.Static resource is meant metastable resource in a period of time, and promptly resource content can frequently not changed.Concrete implication can define in standard.In the present invention, the immovable situation of value that mainly refers to resource.
Etendue critical word :-asz also shows the information of the accurate capacity of resource.
Message instance:
Gateway sends the request of resource discovering to transducer:
REQ:GET/.well-known/core---transmit a request to the URI of acquiescence, and promptly root obtains the Resources list
Transducer sends the response of resource to gateway:
RES:200OK--response identification obtains success, and has carried 2 groups of resource indication information
</sensors/temp>Ct=41; N=" TemperatureC ",--the temperature resource, content type 41, name is called TemperatureC
</sensors/light>Ct=41; N=" LightLux " '--light resource, content type 41, name is called LightLux
</sensors/firmware>Ct=52; N=" firmware "; Asz=65000; The snapshot=0--firmware resource, content type 52, name is called firmware, non-dynamic resource, accurately capacity is 65000 bytes;
</sensors/log>Ct=52; N=" log "; Asz=88000; The snapshot=1--firmware resource, content type 52, name is called log, dynamic resource, current data is snapshot snapshot, its accurate capacity is 88000 bytes;
This response message is to be encapsulated in the message body of CoAP message, and recipient's (being gateway) resolves according to the regulation in the Link-format standard.
(2) increase conditional code
When the data resource of receiving gateway obtained request, if resource is too big, a bag did not transmit, and transducer comes notification gateway with conditional code, is used to show, resource is too big, need ask with Block Option.
Such as, can specified states sign indicating number 413, be used to show that the current data resource capacity is excessive, the indication gateway is used the Block option in request.Can stipulate other conditional code as required,, be used for other purpose to be used to representing other implications.
Message instance:
Gateway sends the request of resource acquisition to transducer:
GET/sensordata
Transducer sends the response of carrier state sign indicating number to gateway:
ACK 413 (conditional code shows that the data resource capacity is too big)
(3) in the field (Header) of CoAP, increase an option (Option) that shows capacity (Size)
Gateway can use capacity option (Size Option) to come indication sensor in request, lets the capacity of transducer return data resource; Transducer indicates the capacity of data resource with Size Option in response.
Or, even gateway does not have the indication of Size Option, transducer also in response with under the bigger situation of Size Option specified resource capacity, especially resource, transducer should be indicated.
If resource is less, transducer directly returns resource data in message body (Body), and then gateway should be as the criterion with the actual capacity of resource data, and the resource capacity that shows among the Size Option can be used to check.
If resource is bigger, transducer does not return resource data, only with the capacity of Size Option return data, indicates to gateway with conditional code simultaneously, lets gateway initiate new request, asks with Block Option.
The code of Size Option can be 16, and data type is an integer, and data length is 1~4 byte, and data unit is a byte.Size Option is mainly used in the response of < Get>method, in the request of < Put >/< Post>method, is used to represent the capacity of resource; If in the request of < Get>method, its value does not have practical meaning, recommends to be changed to 0.
Message instance:
Gateway sends the request of resource acquisition to transducer:
GET/sensordata
Transducer sends the response of carrier state sign indicating number to gateway:
ACK+413+Size 51200 (50K byte)
The concrete implementation procedure of embodiment as shown in Figure 1 is described below in conjunction with Fig. 3.What Fig. 3 represented is the illustrated examples of gateway to transducer transmission data, is merely explanation design of the present invention, and not as limitation of the present invention.
When gateway uses < Get>method to obtain first burst (Block) data; The NUM field is set to 0, and carries the burst capacity (being SZX) of recommendation, and transducer can select to agree the burst capacity recommended; Or select a burst capacity smaller or equal to the burst capacity of recommending; And in response, return, simultaneously, in response, return the fragment data of first burst.Therefore, be 0 o'clock in the NUM field, < Get>request has dual semanteme, and the one, obtain first fragment data, the 2nd, carry out the negotiation of burst capacity.Bring the ambiguity of agreement on handling like this, and can't carry information such as data capacity.
The embodiment of the invention is improved this; In an embodiment of the present invention, when gateway uses Block Option in the request of < Get>method, if the NUM field is set to 0; The expression both sides only carry out the negotiation of burst capacity, and the negotiation of burst sum.Be transducer in response, use the NUM field to return the burst sum, the burst capacity that uses SZX field Returning sensor to confirm.The M field can be removed, and saves a Bit, is used for the NUM field.Because the requesting party, for example gateway is known the burst sum, so just can know from the NUM field of burst whether this burst is last burst, therefore just need not re-use the M field.In this case, if the fragment data of first burst of acquisition request, then NUM is set to 1, and the like.
Need to prove; When if gateway sends first request; Do not know the capacity of data resource, so Block Option can use a byte, if the data resource of transducer is bigger; The burst number is bigger, and then transducer can use two bytes or three bytes to return the burst sum in response.
When Block Option was 2 bytes, it was designed to SZX fields account last three with second byte, expression burst capacity; First byte of NUM fields account usefulness adds preceding 5 of second byte, representes current burst sequence number; If in NUM is 0 request corresponding response message, then represent the burst sum.It will be appreciated by those skilled in the art that and can use message identifier (Message ID) to come association request and response, promptly ask and respond in all carry unique Transaction Identifier, just to understand this response message be to be used to return the burst sum to transducer like this.
Below illustrate burst capabilities negotiation process, message instance is:
Gateway sends the request of resource acquisition to transducer:
GET 00,000 101 (NUM is 0, and SZX is 101, promptly 5, and expression burst capacity is 29 powers, promptly 512)
The response that transducer sends to gateway:
ACK 10,000 100 (NUM is: 10000, and promptly total burst number is 32, SZX is 100, promptly 4, expression burst capacity is 28 powers, promptly 256)
This design has saved a bit (Bit), has promptly been saved the M position, and technical advantage is to have saved data traffic and little to the change of existing design.In this execution mode, burst capacity (SZX) field still will be sent at every turn.
In the prior art; Burst capacity (being the SZX field) all will send at every turn; No matter be in request message or in the response message, the burst capacity possibility of in first burst and last burst, using was different, other burst capacity was the same all.Repeat to transmit identical NUM field mutually and wasted transfer resource.
In embodiments of the present invention, when gateway used Block Option in the request of < Get>method, if NUM is set to 0, the expression both sides only carried out the negotiation of burst capacity, and the negotiation of burst sum.Be transducer in response, use the NUM field to return total burst number, the burst capacity that uses SZX field Returning sensor to confirm.And gateway and transducer both sides store determined burst capacity, the fragment data message transfer after being used for.Except last fragment data.Gateway is in the request of follow-up < Get>method; Only send the current burst sequence number of being asked; And do not send the burst capacity of confirming and remaining unchanged; And transducer also only sends current burst sequence number and the fragment data corresponding with this burst sequence number, the burst capacity of not redispatching in response message.In this case, NUM is 1 o'clock, the fragment data of first burst of expression request, and the like.
To adopt < GET>order to obtain data resource from transducer is example, and the foregoing description is described,
As shown in Figure 3, the design of new Block Option is following:
Wherein to be used for NUM be 0 situation to structure (1):
In < Get>request, NUM is 0, and SZX is second byte, expression burst capacity, and Total Number representes the burst sum, when request, does not use, and need not carry; In < Get>response, NUM is 0, and SZX representes the burst capacity that transducer is confirmed, Total Number representes the burst sum.
In the prior art, the interval of burst capacity is bigger, such as 2048,1024,512, and underaction.And in fact, 512 for a Block, smaller, preferably just can be put in the UDP bag, i.e. 1472 bytes.The present invention improves this, in one embodiment, for SZX, can take new formula, such as: (SZX+1) * 8, then its scope can for: 8~2048, but successively decrease and be spaced apart 8.
It is not 0 situation that structure among Fig. 3 (2) and structure (3) are used for < Get>request NUM, the situation when promptly obtaining fragment data:
When NUM less than 256 the time, represent the burst sequence number with a byte, i.e. structure (2); When NUM greater than 28 powers (promptly 256), during 16 powers less than 2 (promptly 65536), use two bytes to represent the burst sequence number, i.e. structure (3).
Because the NUM in the structure (2) must be greater than 0, the previous byte of the NUM field in the structure (3) therefore can distinguish with structure (1) also greater than 0, for < Get>response, the value of NUM field with ask in the same, also can distinguish.
Below illustrate, message instance is:
Gateway sends the request of resource acquisition to transducer:
GET 00,000,000 00000101 (NUM is 0, and SZX is 101, promptly 5, and expression burst capacity is 29 powers, promptly 512)
The response that transducer sends to gateway:
ACK 00,000,000 00,000,100 00,000,000 00010000 (NUM is 0, and Total Number is 10000, and promptly burst adds up to 32, and SZX is 100, promptly 4, and expression burst capacity is 28 powers, promptly 256).
Through Block Option is designed again; Can in each request or response, reduce at least and send 4 bits, under the more situation of burst, can greatly improve efficiency of transmission; Save transfer resource, also improved gateway and transducer both sides' treatment effeciency simultaneously.
Fig. 4 shows a kind of alternate embodiment of the present invention.In the embodiment shown in fig. 4, ES410 to ES420 is identical with ES210 to ES240 embodiment illustrated in fig. 2, no longer is repeated in this description.
In the embodiment shown in fig. 4, at ES450, gateway sends < GET>request to transducer, uses the burst option to carry out the burst capabilities negotiation, the burst capacity that the indication gateway is recommended.In ES460, transducer is selected and is confirmed suitable burst capacity, is used for resource is carried out burst, and gives gateway with all fragment data active push, and do not need gateway to send out < GET>request again.
Obtain in the data resource process at Fig. 4 embodiment, the design of burst option is as shown in Figure 5, wherein:
Structure (1) is used for gateway and sends < GET>request to transducer; The SZX field is represented the burst capacity that gateway is recommended; The burst capacity that the final burst capacity of selecting and confirming of transducer is recommended smaller or equal to gateway; NUM is the complete resource of 0 expression gateway requests, and NUM is not concrete NUM the fragment data of 0 expression gateway requests, and NUM is not that 0 o'clock transducer can only use the indicated burst capacity of SZX field.
Structure (2) and structure (3) are used for transducer returns burst response message from complete resource to gateway; If to replying of certain concrete fragment data request; Need not carry the burst option, the M field in structure (2) and (3) representes whether be last burst, if the M field is 0 last burst of expression; Be that 1 expression is not last burst, which burst what the NUM field represented that transducer returns is.
Below illustrate.Message instance is:
Gateway sends the request that data resource obtains to transducer:
CON GET 00,000,000 00000101 (NUM is 0, and SZX is 101, promptly 5, and expression burst capacity is 29 powers, promptly 512)
The response that transducer sends to gateway:
ACK 200 00000011 (NUM is 1, and M is 1, first burst that expression is sent, and be not last burst, the burst capacity is the capacity of SZX field appointment);
Transducer continues to send the CoAP response to gateway:
CON 200 00000101 (NUM is 2, and M is 1, second burst that expression is sent, and be not last burst, the burst capacity is the capacity of SZX field appointment);
Gateway returns the ACK to CON;
Transducer sends last burst to gateway:
CON 200 00000110 (NUM is 3, and M is 0, the 3rd burst that expression is sent, and be last burst, concrete burst capacity is calculated by actual sense data).
According to embodiment shown in Figure 4, when transducer obtains complete data resource, only need accomplish the negotiation of burst capacity at gateway, obtain request and need not send a large amount of fragment datas, saved data transfer throughput greatly.
Fig. 6 shows another kind of alternate embodiment of the present invention.In the embodiment shown in fig. 6, ES610 to ES640 is identical with ES210 to ES240 embodiment illustrated in fig. 2, therefore no longer is repeated in this description.
Fig. 6 and difference embodiment illustrated in fig. 2 are that at ES650, gateway sends < GET>request to transducer; The acquisition request resource is used the burst option, the burst capacity that the indication gateway is recommended; The value that this moment, the NUM field was filled is 0, last burst of expression acquisition request; At ES660, the sequence number of definite burst capacity and last burst and corresponding with it fragment data are returned in the request of transducer response gateway.Because the corresponding burst sum of last burst sequence number is so at ES670, gateway just can perhaps concurrent successively request of obtaining other fragment datas.At ES680, transducer returns the sequence number and the corresponding fragment data of this burst according to the burst capacity of confirming.ES670 and ES680 can repeatedly carry out alternately, until the fragment data end of transmission.
The burst option that adopts among Fig. 6 embodiment is as shown in Figure 7, for example adopts the burst option of two bytes, only comprises NUM field and SZX field.
Illustrate below in conjunction with Fig. 6 and Fig. 7, message instance is:
Gateway sends the request of resource acquisition to transducer:
CON GET 00,000,000 00000101 (NUM is 0, and expression requires to obtain last burst, and SZX is 101, promptly 5, and the burst capacity that expression is recommended is 29 powers, promptly 512).
The response that transducer sends to gateway:
ACK 00,000,000 01000101 (NUM 1000 is 8, and what expression was returned is the 8th burst, and SZX is 101 promptly 5, and the burst capacity that expression is confirmed is 29 powers, promptly 512);
According to primary return information, gateway has known that one has 8 bursts, and has obtained the data of the 8th burst, and gateway continues to send the CoAP request to transducer, can obtain successively also and can concurrently obtain remaining fragment data.Following message instance is the fragment data of first burst of acquisition request:
CON GET 00,000,000 00001101 (NUM is 1, and expression requires to obtain first burst, and SZX is 101, promptly 5, and expression burst capacity is 29 powers, promptly 512);
Transducer returns the ACK to CON, i.e. the data of first burst;
Gateway can be successively or all residue bursts of concurrent request, up to having obtained all data.
According to embodiment shown in Figure 6, can in the burst capabilities negotiation, obtain the fragment data of last burst; In follow-up fragment data acquisition process, employed burst capacity is all identical, therefore can combine the description of aforementioned preferred embodiments; Gateway can be when the request of fragment data be obtained in transmission, the SZX field of not redispatching, and only send the NUM field; Can save data traffic thus, improve efficiency of transmission.
Fig. 8 shows and uses the burst option to send data to transducer, the embodiment when for example using asset creation (Post) or upgrading (Put) request.Specifically describe below in conjunction with Fig. 8.
Detailed process description shown in Figure 8 is following:
ES810: gateway sends asset creation (Post) or upgrades (Put) request message to transducer; Utilize the Size option to send the capacity information of resource; The burst capacity and the burst sum that utilize the indication of burst option to recommend; Burst sum described herein is based on that the volumeter of burst capacity and the data resource to be sent of recommendation calculates, and does not carry concrete resource data in the request message body.
ES820: if transducer is ready to receive these data, then the return state sign indicating number for example is 100 (promptly indicating client to continue to send), returns definite burst capacity to gateway simultaneously, and said definite burst capacity can only be less than or equal to the burst capacity that gateway is recommended; If transducer is unwilling to receive these data, then returns error code indication client and do not continue to send data.Such as, the lack of memory capacity of transducer then returns the return code of 413 " Request Entity Too Large " to store the data of indicated resource capacity.
ES830: gateway is according to the burst capacity of confirming that transducer returns, and judges whether identically with the burst capacity of recommending, if identical, then jumps to ES360; If the burst capacity information of confirming inequality, as then to return, and, recomputate the burst sum according to the data resource capacity according to transducer.
ES840: gateway sends burst capacity of confirming and the burst that recomputates sum to transducer again.
ES850: transducer returns definite burst capacity.
ES860: gateway from according to the burst sequence number from 1 until burst sum, send the fragment data of the data resource corresponding successively to transducer, up to complete end of transmission with the burst sequence number.
ES870: transducer returns the message of confirming reception, wherein comprises the burst sequence number that receives.
According to a kind of preferred embodiment of the present invention, can carry out parallel processing among the ES860, promptly gateway can send a plurality of fragment datas to transducer simultaneously, and need not wait for that transducer returns the response message to previous fragmental messages.Alternatively, according to a kind of preferred embodiment of the present invention, gateway and transducer increase authentication information in interacting message.The configuration of authentication message and interactive mode can adopt the described same way as with reference to Fig. 2.
In order to improve efficiency of transmission; Save data traffic, the another kind of preferred embodiment according to the present invention is as the front is directed against the said ground of < GET>method; In the request of using < Put >/< Post>method; When NUM 0 is, no longer be to send first fragment data, but the capacity of the burst that sensor is recommended is total with burst.Transducer can return response and inform whether gateway continues to send data.Transducer uses the NUM field to return total burst number in response, the burst capacity that uses SZX field Returning sensor to confirm.And gateway and transducer both sides store determined burst capacity, the fragment data message transfer after being used for.Except last fragment data.Gateway is in the request of follow-up < Put >/< Post>method; Only send the current burst sequence number of being asked; And do not send the burst capacity of confirming and remaining unchanged; And transducer also only sends current burst sequence number and the fragment data corresponding with this burst sequence number, the burst capacity of not redispatching in response message.In this case, NUM is 1 o'clock, the fragment data of first burst of expression request, and the like.
In the case, the design of burst option and occupation mode all are similar to shown in Figure 3, below explain with reference to Fig. 3.In < Put >/< Post>request, the NUM field is 0, and the SZX field is second byte, and the burst capacity that expression is recommended, Total Number are represented burst sum number to be sent; In < Put >/< Post>response, the NUM field is 0, and the SZX field is represented the burst capacity that transducer is confirmed, Total Number is useless, need not carry; If SZX field that gateway receives and transmission is inconsistent, need send < Put >/< Post>request with new SZX once more, and carry the burst sum that recomputates, transducer is beamed back response again.After in < Put >/< Post>request and the response, no longer carry the SZX field.
Through the burst option is designed again; Can in each request or response, reduce at least and send 4 bits, under the more situation of burst, can greatly improve efficiency of transmission; Save transfer resource, also improved gateway and transducer both sides' treatment effeciency simultaneously.
In addition, prior art all need be carried the unified resource sign (URI of institute's request resource in the request of each slicing transmission; Unified Resource Identifier), URI will account for tens to tens bytes usually, and the transmission of repetition can be wasted transfer resource; The present invention designs and uses Token (token) to come a plurality of requests of related slicing transmission; Only in first fragmental messages, transmit URI, in follow-up slicing transmission request, only need carry Token and get final product; Because Token is 1~8 byte normally, therefore can save certain flow.
Fig. 9 is a kind of embodiment that passes through the client device of slicing transmission data resource of the present invention.Client device 900 shown in Figure 9 comprises: acquiring unit 910 is used to obtain the data resource capacity information; Transmitting element 920 is used to send the request message that carries the burst option, and wherein said burst option comprises the burst capacity of recommendation, and receiving element 930 receives the response message that carries the burst option, and wherein said burst option comprises definite burst capacity; With transmission unit 940, be used for according to said definite burst capacity and said data resource capacity information, the said data resource of slicing transmission.
According to a kind of preferred embodiment of the present invention, said client device may further include memory cell 950, is used to preserve said definite burst capacity.So that in the data resource transmission course, do not need all to send the SZX field at every turn.
According to another kind of preferred embodiment of the present invention, said client device may further include authentication ' unit 960, is used for sending and receiving authentication information.
Figure 10 is a kind of embodiment that passes through the server apparatus of slicing transmission data resource of the present invention.Server apparatus 1000 shown in Figure 10 comprises: receiving element 1010, be used to receive the request message that carries the burst option, and wherein said burst option comprises the burst capacity of recommendation; Transmitting element 1020 is used to send the response message that carries the burst option, and wherein said burst option comprises definite burst capacity; With transmission unit 1030, be used for according to said definite burst capacity, the said data resource of slicing transmission.
According to an embodiment of the present invention, transmitting element 1020 also is used to send the message of carrying the data resource capacity information, so that transmission unit 1030 is according to said definite burst capacity and said data resource capacity information, the said data resource of slicing transmission.
According to an embodiment of the present invention, when receiving one-time request, transmission unit 1030 is the slicing transmission data on one's own initiative, do not ask and do not need client device to be directed against each fragment data.
A kind of preferred embodiment according to the present invention, said server apparatus may further include memory cell 1040, is used to preserve said definite burst capacity.So that in the data resource transmission course, do not need all to send the SZX field at every turn.
According to another kind of preferred embodiment of the present invention, said server apparatus may further include authentication ' unit 1050, is used for sending and receiving authentication information.
According to the embodiment of the invention; Gateway can be known the capacity information of target resource, is used to make a strategic decision whether obtain resource with the mode of burst, has avoided the possibility of makeing mistakes like this; Also can realize asking concomitantly burst; Improve the efficient of request of data, and learn that the capacity of resource also is convenient to the memory allocated space, calculate the quantity of burst.
Through the burst option is designed again, can in each request or response, send 4 bits at least less, under the more situation of burst, can greatly improve efficiency of transmission, save transfer resource, also improved both sides' treatment effeciency simultaneously.
In the prior art, after receiving the request that comes from client, server can be beamed back response immediately; Also can beam back an Ack (Acknowledgement) response message earlier; Show to have received request message that present is after follow-up grade is handled; The response message of redispatching, the response of promptly postponing.In addition, client can be subscribed to the change of a resource, and server in case resource information changes, is just beamed back notification message to client after accepting the subscription of client to certain resource.
Prior art can not satisfy following demand:
1, client is indicated server in request, oneself needs the response of which kind of mode;
2, client requires server in certain official hour, to beam back response;
3, in the transport process of notification message, because network capacity is unstable, the notification message that possible server sends earlier, than the message of sending behind the server, the time that arrives client is wanted evening.Like this, the resource information of receiving after the client is actually outmoded information, and client needs the order that a kind of mechanism can be surveyed a plurality of notification messages.
Figure 11 is the flow chart of an embodiment of the present invention.In the embodiment shown in fig. 11; At S1110; User end to server sends a request message, and this request message carries the response mode option, and said response mode option can be delaying response (Deferred Response) option or token (Token) option; Be used for indicating server, whether client receives the response of postponement.For example, said response mode option is represented: a plurality of responses that a plurality of responses of the disposable disposable response that makes an immediate response, postpones, postponement and cancellation are postponed.If the response mode option does not carry, be defaulted as disposable response, server can confirm to adopt disposable making an immediate response or the disposable response of postponing.Then, at S1120, the response message that generates according to the response mode option that client can reception server be sent.
In the prior art, after receiving the request that comes from client, server can be beamed back response immediately, also can beam back an Ack earlier, show to have received request message, and present, after follow-up grade is handled, the response message of redispatching, the response of promptly postponing.In addition, client can be subscribed to the change of a resource, and server in case resource information changes, is just beamed back notification message to client after accepting the subscription of client to certain resource.
In an embodiment of the present invention, for example can adopt delay (Deferred) option of a byte to indicate response mode, wherein, can use preceding two bits (Bit) to represent, represent with C:
C=00: represent disposable making an immediate response;
C=01: the disposable response that expression is postponed;
C=10: a plurality of responses that expression is postponed, promptly subscribe to;
C=11: a plurality of responses that the expression cancellation is postponed promptly cancel subscriptions.
Subscription for the client initiation about certain resource; Can cancel subscriptions by client; Also can cancel subscriptions by server, send back to the response message that needs of client are confirmed such as server, client fails to confirm in preset time; Then server can think that client loses connection, thereby cancels subscriptions.
Because a byte is 8 bits, unnecessary back 6 bits (supposing that its value is T) can be used to represent the retardation time of the disposable response postponed or the deadline of a plurality of responses of postponing, promptly above after this time, cancel subscriptions automatically.When C is 01, the retardation time of the disposable response that T representes to postpone; When C is 10, the deadline of a plurality of responses that T representes to postpone; When T was 00 or 11, T was nonsensical, was changed to 0.
For these 6 bits, can represent the numerical value between 0~63, be assumed to be T, can use 2 T power, show this time span, with the second unit, promptly can represent 1~2^63 second.Such as:
0:2^0=1 second;
1:2^1=2 second;
2:2^2=4 second;
3:2^3=8 second
4:2^4=16 second;
...
63:2^63 second.
In the prior art, the Max_Age field is used to maximum time of showing that certain response can be buffered, promptly shows the freshness of response.The present invention expands the implication of this field, can be in request representes the restriction in the time interval between a plurality of responses with the Max_Age field, must not be higher than this time interval such as a plurality of notification messages, or must not be lower than this time interval.
For the order of a plurality of responses, can use message identifier (Message ID) to distinguish.Such as, the regulation message identifier must come incrementally to generate according to the order of logical response, and the recipient judges the sequencing of response according to the size of message identifier.
According to another kind of embodiment of the present invention, can use Token (token) option to indicate response mode, if the Token value is 0, represent response immediately, if the Token value is not 0, then represent the response that can accept to postpone.
According to another kind of embodiment of the present invention, can be alternatively or increase timestamp (Timestamp) option in addition, and postpone option separately or indicate response mode in combination.Specifically, client can be carried the timestamp option in request, and said timestamp option comprises the value of a deadline, and requiring server to echo at the time of appointment internal return should; Server carries the timestamp option in response message, show the time that response message generates, and like this, client can be judged the order of response message based on the timestamp option.
In an embodiment of the present invention, the design of said timestamp option can be represented with 1~6 byte, if the time of expression is short, then uses a byte, if the time is long, then uses 3 bytes or 6 bytes.For example following two kinds of concrete method for expressing:
(1) with year, the moon, day, the time, branch, second represent first byte representation year, second byte representation moon, the 3rd byte representation day, the 4th byte representation hour; The 5th byte representation minute, for the time, for example can be the basis with 2000 at the 6th byte representation second; Its value shows which year after 2000, such as being, shows it is 2000 at 0 o'clock; Be 1 o'clock, show it is calendar year 2001, can represent 2063 at most.
(2) three bytes approximately are 136 years all with representing that maximum can be represented 2^24-1 second second.
Thus, client can be known the order of the response message that returns, the mistake of avoiding data transfer delay to cause.
Corresponding with embodiment shown in Figure 11, Figure 12 is from server side, the flow chart of the method for the embodiment of the invention.The method of the embodiment of the invention comprises:
S1210: receive the request message that carries the response mode option that client is sent;
S1220: send the response message that generates according to said response mode option to client.
Further set forth the scheme of the embodiment of the invention below in conjunction with concrete embodiment.
Embodiment 1:
In the described request message of in step S1110, sending, disposable response or disposable make an immediate response of said response mode option for postponing, and described request message also carry the type of message indication information and time of delay option.The type of message indication information indication described request message here is the multicast request; And time of delay, option was used to indicate a plurality of servers at said time of delay of option in indicated time; Select a time to send response message arbitrarily to client; Give client to avoid a plurality of servers to beam back response simultaneously, cause network congestion, and client has little time also to handle.For example, at said time of delay of option in indicated time, after a plurality of servers pass through random delay separately, send response message to client again.
For example; A plurality of electric controllers (server) that certain building keeper utilizes control desk (multicast gateway) to send to whole building send the instruction (multicast request) of turning on light; Whether require each electric controller in 5 seconds, to beam back response turns on light to show; After then each electric controller passes through random delay respectively in 5 seconds, beam back response, show whether turn on light to control desk.
For announcement server described request message is the multicast request, type of message indication information described here for example can be the socket port of presetting that is used to send the multicast request; The perhaps preset procotol IP address that is used to send said multicast request; The perhaps preset port numbers that is used to send the multicast request; Perhaps the type of message in the described request message is indicated option.For example,
1) server is opened a specific socket (Socket) port; And be set to procotol (Internet Protocol; Be called for short IP) the multicast reception, then client is sent described request message through this specific Socket port to server, is the multicast request with expression described request message;
2) client is carried preset IP address, for example FF00: in described request message: the prefix of/8 IPv6, after server receives request message; Inspection receives the IP address of bag; If this IP address is represented that then this request message is the multicast request, otherwise is unitcast request for preset IP address;
3) the client port numbers of sending the multicast request through preset being used to is sent described request message; For example: coap: // be used for unitcast request; Coapm: // be used for the multicast request, then server can confirm that described request message is unitcast request or multicast request according to the port numbers of the request message that receives.
4) client shows that with type of message indication Option Field this request is unitcast request or multicast request in request message, and server is judged according to this field.
According to the embodiment of the invention, said process is applicable to that also described request message is the scene of unitcast request.
The behavior of server is different under clean culture and multicast scene, and the main distinction is, for unitcast request, overtime after, server is abandoned beaming back response and is given client; For the multicast request, overtime after, server can be beamed back response and give client, though response timeout, but because not every server is all overtime, so can not cause congestion problems.
According to the embodiment of the invention, described request message also comprises option deadline, echoes at the indicated time internal return of this option deadline with the indication server and answers message.Thus, before client is can be in the time of said deadline of option indication overtime, the response message that reception server sends.
Embodiment 2:
In the request message that in step S1110, sends, client subscription (Observe) data in server is promptly represented in a plurality of responses of response mode option for postponing.In this case, server sends push-notification-answer message to client.According to the embodiment of the invention, push-notification-answer message carry live forever most continuous time (Max-Age) option with stay time time (Patience) option, wherein the Max-Age option is used to show the longest effective time of the value of resource; Said Patience option is used to indicate server to cross after date at Max-Age, responds in indicated time at said Patience option.Value in resource does not have under the situation of change, and server can be used this Patience option, comes the transmission of delayed response message.In this case, client can be judged with this, crosses after date at Max-Age, and server will send push-notification-answer and give client as far as possible before the Patience time expire.Therefore, client can be crossed after date at Max-Age, continues the subscribing relationship of maintenance and said server, and the retention time is the said indicated time of Patience option.Can avoid client to cross after date like this, send a request message to server again at Max-Age.
Embodiment 3:
In the described request message of in step S1110, sending, a plurality of responses of said response mode option for postponing, expression client subscription (Observe) data in server.In this case, comprise retention time (Keep Alive) option in the described request message that user end to server sends.Client can according to circumstances be provided with the value of Keep Alive option, such as being set to 1000 seconds in this example.After server is received this request message, reply affirmation (Acknowledgement is called for short ACK) message to client; Wherein carry the up-to-date value of current subscription resource; Obtain Keep Alive option simultaneously, and open a timer at this moment, the value that its value is provided with for KeepAlive.
In the time of the said indication of Keep Alive option; If the resource of client subscription changes on server; Then server sends the 3rd notice response to client; Be the 3rd notice response that the client reception server sends, this said the 3rd notice response is for need not affirmation type message.
After the time of pressing the Keep-Alive indication was overtime, server sent four-way to client and knows response, i.e. the four-way of client reception server transmission is known response, and wherein said four-way knows that response is needs affirmation type message.Server wait client is returned ACK message then.After server is received the ACK message from client, explain that then the client operation is normal.Can repeat top process then, server is the opening timing device again, through need affirmation type message not sending response message to client.
If server is not received the ACK message of client within a certain period of time, then server will resend above-mentioned four-way knowledge response.If when the repeating transmission number of times arrived preset frequency threshold value, server was not still received the ACK message of returning of client, then server stops to retransmit, and also stops the subscribing relationship with client simultaneously.
Figure 13 is the interacting message figure of the implementation procedure of embodiment 3.Each message among Figure 13 is following:
ES1310: user end to server sends subscribe request, wherein carries the KeepAlive option;
ES1320: server is replied ACK message to client, wherein carries the up-to-date value of current subscription resource, the opening timing device;
ES1330: when the resource of subscribing on the server changed, this server sent push-notification-answer to client, and this push-notification-answer is for need not affirmation type message;
ES1340: behind timer expiry, the server employing needs affirmation type message to send push-notification-answer, and waits for the ACK message that client is returned;
ES1350: client-server returns an ACK message;
ES1360: server is received the ACK message from client, opening timing device again;
ES1370: when the resource of subscribing on the server changed, this server sent push-notification-answer to client, and this push-notification-answer is for need not affirmation type message;
ES1380: behind timer expiry, the server employing needs affirmation type message to send push-notification-answer, and waits for the ACK message that client is returned;
ES1390: server is not received the ACK message of client within a certain period of time; Server will resend above-mentioned push-notification-answer, arrive maximum when retransmitting number of times, and server is not still received the ACK message of client; Then server stops to retransmit, and also stops the subscribing relationship with client simultaneously.
The code of ES1310 to ES1390 for example is:
REQ:GET/resource-URI/observe=0/keep-alive=1000---transmit a request to the URI of the resource that needs subscription, carries to subscribe to indicate observe option and Keep Alive option;
RES:ACK/payload---reply ACK earlier, in payload, carry the up-to-date data of resource;
RES:NON/payload---when resource had renewal, server adopted the message of non-affirmation to reply push-notification-answer;
RES:CON/payload---crossed the timer that Keep Alive option is provided with after, server employings needs affirmation type message answer push-notification-answer;
REQ:ACK/---client is replied ACK message
RES:NON/payload---when resource had renewal, server adopted the message of non-affirmation to reply push-notification-answer;
RES:CON/payload---crossed the timer that Keep Alive option is provided with after, server adopts the message of confirming to reply push-notification-answer;
RES:CON/payload---do not receive the ACK message of client within a certain period of time, resend above-mentioned message;
According to the embodiment of the invention, the KeepAlive option can be defined as selectable option, if promptly the CoAP server is not supported this option, can ignore this option, handles the request of receiving by this option not.
According to the embodiment of the invention, the value of this Keep Alive option is an integer type, and size can be elongated.According to concrete needs, its size can be 4bit (bit), or 8 bit, or 12bit, even bigger, and the embodiment of the invention does not limit its concrete span.
Embodiment 4:
In practical application; Server is because congested etc. former thereby when causing high load capacity; According to the collocation strategy of server apparatus, cause server apparatus thoroughly to be paralysed in order to prevent operations such as follow-up signaling process, server apparatus is put at this moment to go up and is opened congested control; Promptly in ensuing certain hour, no longer handle any new request message of receiving.
Consider the application of the embodiment of the invention in this scene.For example; In step S1110; User end to server sends a request message, disposable response or disposable make an immediate response of wherein said response mode option for postponing, and described request message also comprise the type of message indication information and deadline option; Wherein said type of message indication information indication described request message is unitcast request, and described request message is needs affirmation type message.It will be understood by those skilled in the art that if server receives is need affirmation type request message, then directly message is ignored, do not reply any response.If server takes place congested and has opened congested control at this moment; Then in step S1120; Server sends specific ACK message to said client; Wherein said specific affirmation message is carried response code and is postponed option turn-on time, and wherein said response code for example is 5.03 " service unavailable " (serving unavailable) response codes, be used to represent server said deadline option can't return response in indicated time to described request message.Perhaps server can send ACK message to said client earlier; Then send response message to said client; Wherein said response message carries response code and postpones option turn-on time, wherein said response code represent said server said deadline option can't return response in indicated time to described request message.
The value that postpones option turn-on time has been represented the concrete time that postpones access, and unit for example is second, and maximum for example is 2
NSecond, surpass this peaked value for example by server according to default value 2
MHandle second.If when perhaps this option did not appear in the response message when this option value was zero, then client need not to carry out operation bidirectional, can attempt at any time sending request once more to server.According to the embodiment of the invention, delay option turn-on time is optional type, can directly be left in the basket in the time of promptly can't being discerned by the CoAP client.
Figure 14 is the interacting message figure of embodiment 4.It is as shown in the figure,
E1400: server is opened congested control;
E1402: client needs affirmation type request message to said server transmission;
E1404: server sends ACK message to client, and this ACK message comprises and postpones to insert option (newly), response code and empty load
E1404: client is removed the wait of buffer memory other request messages to said server transmission immediately.
E1406:, send a request message to server postponing the turn-on time option in indicated time;
E1408: server is ignored this request message;
E1410: the time that latency delays option turn-on time is indicated;
E1412: server load recovers normal;
E1414: user end to server resends described request message;
E1416: server returns normal ACK message.
Because the version of CoAP agreement is different, the not upgrading in time of the actual CoAP client that comes into operation inserts option to such an extent as to can't discern said delay.Even therefore at E1404; Have the ACK that postpones option turn-on time and sent to client; Because can't discerning more always, client release postpones option turn-on time; This client device will be ignored this option (also might be that other abnormal conditions cause), and possibly attempt once more sending a request message to meeting with congested server apparatus at E1406 in ensuing random time.Server apparatus can be according to configured strategy; Ignore this request message; Or send the response message that has new delay option turn-on time once more, the value of delay option turn-on time that this is new can be less than the value of delay option turn-on time that has before sent.
Need to prove, explain for ease in the present embodiment that all used the response message of Piggy-backed (subsidiary formula), promptly each option is entrained in directly transmission in the ACK message.According to the embodiment of the invention, also can use the response of separate type, promptly acknowledge message and response message send at twice, postpone to insert the part that option always belongs to response message.
Embodiment 5:
Take place congested similarly with server side, client also possibly cause high load capacity because certain reason takes place congested.When client because congested etc. former thereby when causing high load capacity; Collocation strategy according to client; In order to prevent that operations such as follow-up signaling process from causing client thoroughly to be paralysed; Client is put at this moment to go up and is opened congested control, promptly in ensuing certain hour, no longer handles any new request message of receiving.
Consider the application of the embodiment of the invention in this scene.For example, in step S1110, user end to server sends described request message, a plurality of responses of wherein said response mode option for postponing, i.e. resource information on the client subscription server.Then, in step S1120, client is received the response message that server sends, and for example under the situation that ordered resource has taken place on the server to change, server needs affirmation type response message to the client transmission, wherein carries up-to-date resource information.If this moment, client was opened congested control; Then can send specific ACK message to server; Said specific affirmation message is carried response code and is postponed option turn-on time, and wherein said response code representes that said client can't return the affirmation to said response message at said delay option turn-on time in indicated time.Perhaps client can be sent ACK message to said server earlier; Then send specific response message to said client; Wherein said specific response message carries response code and postpones option turn-on time, and wherein said response code representes that said client can't return to the said affirmation that needs affirmation type response message in indicated time at said delay option turn-on time.Opening in client under the situation of congested control, is need affirmation type response message if client receives in step S1120, and then client is directly ignored this message, does not reply any acknowledge message.
As stated, the value that postpones option turn-on time has been represented the concrete time that postpones access, and unit for example is second, and maximum for example is 2
NSecond, surpass this peaked value for example by client according to default value 2
MHandle second.If when perhaps this option did not appear in the response message when this option value was zero, then server need not to carry out operation bidirectional, can attempt at any time sending once more to client need affirmation shape response message.According to the embodiment of the invention, delay option turn-on time is optional type, can directly be left in the basket in the time of promptly can't being discerned by the CoAP server.
After server was received above-mentioned specific ACK message, if delay option turn-on time in can identification message, the subscription that then suspends between all and the said client pushed, and begins to wait for, waited for that promptly said client recovers normal.
After postponing the indicated effluxion of option turn-on time; It is normal that client is recovered; The wait timing of server also finishes, so response message that need to confirm to the client device repeating transmission of server, and the normal client of load restoration can be replied a normal acknowledge message this moment.
Figure 15 is the interacting message figure among the embodiment 5.It is shown in figure 16,
ES1500: user end to server sends subscribe request;
ES1502: server needs the response message of affirmation to the client transmission;
ES1504: user end to server sends ACK message;
ES1506: client is opened congested control;
ES1508: server needs the response message of affirmation to the client transmission;
ES1510: user end to server sends and carries respective code and the specific ACK message that postpones option turn-on time;
ES1512: server suspends the resource of subscribing to server push;
ES1514: the time that server latency delays option turn-on time is indicated;
ES1516: the client load restoration is normal;
ES1518: server resends the response message that needs affirmation to client;
ES1520: user end to server sends ACK message.
What be worth explanation is; Under the normal condition; After client device is received the request message of the needs affirmation that server apparatus pushes; What all reply is the ACK acknowledge message, has only the mode that need when server notification postpone to insert, just use piggybacked when client to carry concrete response contents or separately transmit ACK and response.
According to the embodiment of the invention, through specified response mode option in message interaction process, client can be specified required response, has improved the interacting message efficient of CoAP.
Embodiment 6:
Present embodiment has been described the server and client side and has been carried out mutual flow process:
1, overtime option is wherein carried in the user end to server request of sending, and to indicate this request be unitcast request or multicast request, is resource subscription request or disposable request;
2, server is judged according to the request that receives, if this request is disposable request, then server continues to judge to be unitcast request or multicast request:
If A. this request is the disposable request of clean culture; Server is prejudged whether oneself can accomplish client in the time of overtime option appointment request; If the prediction can not accomplish, then beam back a conditional code (such as 5.04, Timeout; Overtime) give client, show the request that can not accomplish client in the given time; Alternatively, the time that server prediction self is idle, or self can accomplish the time of the request of client, and in response, send back to client to this predicted time, the indication client is sent request once more after the predicted time of appointment; If server can be accomplished request in the time-out time of appointment, then before time-out time is expired, beam back response.
If B. this request is the disposable request of multicast, server is selected a time arbitrarily in the time of appointment, return response and give client.
If 3 servers judge that the request of client is a subscribe request, server continues to judge that the time-out time that carries in this request is the Patience option, or the Keep-alive option:
If what A. carry in the request is the Patience option, then shows in the server needs at the appointed time and beam back first notification message; Server carries the information of resource in notification message, and Max-Age option and Patience time option, requires the subscription status of at the appointed time interior maintenance of client and server resource.
If what B. carry in the request is Keep-alive time option, server in the time, uses the mode of Non-confirmable message at Keep-alive, sends a notification message to client; Pass after date in the Keep-alive time, use the mode of Confirmable message, send a notification message to client.
Figure 16 is that wherein said client device 1600 comprises: sending module 1610 is used to send the request message that carries the response mode option according to the block diagram of the embodiment of a kind of client device that transmits data resource of the present invention; With receiver module 1620, be used to receive the response message that generates according to said response mode option.
All be applicable to client device shown in Figure 16 with reference to described process of the described embodiments of the invention of Figure 11 and characteristic.Specifically; For example; The response mode option that carries in the request message that sending module 1610 sends can be to postpone option, for example can be a plurality of responses that a plurality of responses of the disposable disposable response that makes an immediate response, postpones, postponement and cancellation are postponed.
According to a kind of embodiment, the deadline of the retardation time of the disposable response that the response mode option that carries in the request message that sending module 1610 sends can be represented to postpone or a plurality of responses of postponing.
According to a kind of embodiment, sending module 1610 sends the request message that carries the timestamp option, and this timestamp representes to receive the deadline of response; Receiver module 1620 receives the response message that carries the timestamp option, and this timestamp is represented the rise time of response message.Receiver module 1620 is confirmed the order of response message according to the represented time of timestamp in the response message that receives.
According to the embodiment of the invention, in described request message, disposable response or disposable make an immediate response of said response mode option for postponing,
Described request message also carry the type of message indication information and time of delay option, wherein said type of message indication information indication described request message is multicast request or unitcast request;
Said receiver module 1620 was used in the time of said option indication time of delay, the response message that reception server sends.
According to the embodiment of the invention, described request message also comprises option deadline,
Said receiver module 1620 be used in the time of said deadline of option indication overtime before, the response message that reception server sends.
According to the embodiment of the invention, in described request message, a plurality of responses of said response mode option for postponing,
Said receiver module 1620 is used to receive the push-notification-answer message that said server sends, and wherein said push-notification-answer message is carried and lived forever continuous time option most and stay time time option, and the wherein said time time option that stays is used for indication,
In the said continuous indicated time of time option of living forever most overtime after, said client keeps the subscribing relationship with said server, the retention time is the said indicated time of candidate item of staying.
According to the embodiment of the invention; In described request message; The a plurality of responses of said response mode option for postponing, described request message also comprises the retention time option, said receiver module 1620 was used in the time of said retention time option indication; First push-notification-answer that reception server sends, wherein said first push-notification-answer is for need not affirmation type message; In the time of said retention time option indication overtime after; Said receiver module 1620 is used to receive second push-notification-answer that said server sends; Wherein said second push-notification-answer is needs affirmation type message, and said sending module 1610 is used for sending affirmation ACK message to said server.
According to the embodiment of the invention; In described request message; Disposable response or disposable make an immediate response of said response mode option for postponing; Described request message also comprise the type of message indication information and deadline option, wherein said type of message indication information indication described request message is unitcast request, described request message is needs affirmation type message;
Said receiver module 1620 is used to receive the specific affirmation message that said server sends; Wherein said specific affirmation message is carried response code and is postponed option turn-on time, wherein said response code represent said server said deadline option can't return response in indicated time to described request message;
Perhaps
Said receiver module 1620 is used to receive the affirmation message that said server sends;
And be used to receive the specific response message that said server sends; Wherein said specific response message carries response code and postpones option turn-on time, wherein said response code represent said server said deadline option can't return response in indicated time to described request message.
According to the embodiment of the invention, said receiver module 1620 also is used to remove the wait of buffer memory other request messages to said server transmission.
According to the embodiment of the invention, after indicated time, said sending module 1610 also is used for sending described request message to said server again at said delay option turn-on time.
According to the embodiment of the invention, in described request message, a plurality of responses of said response mode option for postponing, the response message that generates according to said response mode option that said reception server sends is a needs affirmation type message,
Said sending module 1610 also is used for sending specific affirmation message to said server; Wherein said specific affirmation message is carried response code and is postponed option turn-on time, and wherein said response code representes that client can't return the affirmation to said response message at said delay option turn-on time in indicated time;
Perhaps
Said sending module 1610 is used for sending acknowledge message to said server;
And be used for sending specific response message to said server; Wherein said specific response message carries response code and postpones option turn-on time, and wherein said response code representes that said client can't return the affirmation to said response message at said delay option turn-on time in indicated time.
According to the embodiment of the invention, said response message comprises the response message rise time, and said receiver module 1220 also is used for confirming according to the said response message rise time order of response message.
Figure 17 is that wherein said server apparatus 1700 comprises according to a kind of embodiment that transmits the server apparatus of data resource of the present invention: receiver module 1710 is used to receive the request message that carries the response mode option that client is sent; With sending module 1720, send the response message that generates according to said response mode option to client.
All be applicable to server apparatus shown in Figure 17 with reference to described process of the described embodiments of the invention of Figure 12 and characteristic.Specifically; For example; The response mode option that carries in the request message that receiver module 1710 receives can be to postpone option, for example can be a plurality of responses that a plurality of responses of the disposable disposable response that makes an immediate response, postpones, postponement and cancellation are postponed.
According to the embodiment of the invention; In described request message; Disposable response or disposable make an immediate response of said response mode option for postponing; Described request message also comprise the type of message indication information and time of delay option, wherein said type of message indication information indication described request message is multicast request or unitcast request; Said sending module 1720 is used in the time of said option indication time of delay, through after the random delay, sending response message to said client.
According to the embodiment of the invention, described request message also comprises option deadline, said sending module 1720 be used in the time of said deadline of option indication overtime before, send response message to said client.
According to the embodiment of the invention, in described request message, a plurality of responses of said response mode option for postponing,
Said sending module 1720 is used for sending push-notification-answer to said client, and wherein said push-notification-answer carries and lives forever continuous time option most and stay time time option, and the wherein said time time option that stays is used for indication,
In the said indicated time of continuous time option of living forever most overtime after, said server will respond in the indicated time at the said time time option that stays.
According to the embodiment of the invention; In described request message; The a plurality of responses of said response mode option for postponing, described request message also comprises the retention time option, said sending module 1720 was used in the time of said retention time option indication; Send the 3rd notice response to said client, wherein said the 3rd notice response is for need not affirmation type message; Said sending module 1720 also be used in the time of said retention time option indication overtime after, send four-way to said client and know response, wherein said four-way knows that response is needs affirmation type message; Said receiver module 1710 is used to receive the ACK message that said client is sent.
According to the embodiment of the invention; In described request message; Disposable response or disposable make an immediate response of said response mode option for postponing; Described request message also comprise the type of message indication information and deadline option, wherein said type of message indication information indication described request message is unitcast request, described request message is needs affirmation type message;
Said sending module 1720 is used for sending specific affirmation message to client; Wherein said specific affirmation message is carried response code and is postponed option turn-on time, wherein said response code represent said server said deadline option can't return response in indicated time to described request message;
Perhaps
Said sending module 1720 is used for sending acknowledge message to client;
And be used for sending specific response message to client; Wherein said specific response message carries response code and postpones option turn-on time, wherein said response code represent said server said deadline option can't return response in indicated time to described request message.
According to the embodiment of the invention, after indicated time, said receiver module 1710 is used to receive the described request message that said client resends at said delay option turn-on time.
According to the embodiment of the invention; In described request message; The a plurality of responses of said response mode option for postponing; The said response message that generates according to said response mode option that sends to client is a needs affirmation type message; Said receiver module 1710 is used to receive the specific affirmation message that said client is sent, and wherein said specific affirmation message is carried response code and postponed option turn-on time, and wherein said response code representes that said client can't return the affirmation to said response message at said delay option turn-on time in indicated time;
Perhaps
Said receiver module 1710 is used to receive the affirmation message that said client is sent;
And be used to receive said client and send specific response message; Wherein said specific response message carries response code and postpones option turn-on time, and wherein said response code representes that said client can't return the affirmation to said response message at said delay option turn-on time in indicated time.
According to the embodiment of the invention, in the indicated time of said delay option turn-on time overtime after, said sending module 1720 is used for resending the said affirmation type response message that needs to said client.
According to another kind of embodiment of the present invention; Can carry the timestamp option in the request message that receiver module 1710 receives; This timestamp option representes to receive the deadline of response; And also can carry the timestamp option in the response message that sending module 1320 sends, said timestamp option is represented the rise time of response message.
Those of ordinary skills can recognize; The unit and the algorithm steps of each example of describing in conjunction with embodiment disclosed herein; Can realize with electronic hardware, computer software or the combination of the two; For the interchangeability of hardware and software clearly is described, the composition and the step of each example described prevailingly according to function in above-mentioned explanation.These functions still are that software mode is carried out with hardware actually, depend on the application-specific and the design constraint of technical scheme.The professional and technical personnel can use distinct methods to realize described function to each certain applications, but this realization should not thought and exceeds scope of the present invention.
The software module that the method for describing in conjunction with embodiment disclosed herein or the step of algorithm can use hardware, processor to carry out, perhaps the combination of the two is implemented.Software module can place the storage medium of any other form known in random asccess memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable ROM, register, hard disk, moveable magnetic disc, CD-ROM or the technical field.
Although illustrated and described some embodiments of the present invention, it will be understood by those skilled in the art that under the situation that does not break away from principle of the present invention and spirit can carry out various modifications to these embodiment, such modification should fall in the scope of the present invention.
Claims (26)
- One kind in Internet of things system based on the data resource transmission method of the node of lightweight application layer protocol, it is characterized in that,Send the request message that carries the response mode option to server, wherein said response mode option is represented wherein one of following response mode: a plurality of responses that a plurality of responses of the disposable disposable response that makes an immediate response, postpones, postponement and cancellation are postponed;Receive the response message that said server sends according to said response mode option generation.
- 2. the method for claim 1 is characterized in that,In described request message, disposable response or disposable make an immediate response of said response mode option for postponing,Described request message also carry the type of message indication information and time of delay option, wherein said type of message indication information indication described request message is multicast request or unitcast request;Reception comprises according to the response message that said response mode option generates:In the time of said option indication time of delay, the response message that reception server sends.
- 3. method as claimed in claim 2 is characterized in that,Described request message also comprises option deadline,Reception comprises according to the response message that said response mode option generates:In the time of said deadline of option indication overtime before, the response message that reception server sends.
- 4. like claim 2 or 3 described methods, it is characterized in that,Said type of message indication information is following wherein one:The preset socket port that is used to send the multicast request;The preset procotol IP address that is used to send the multicast request;The preset port numbers that is used to send the multicast request;Type of message indication option in the described request message.
- 5. the method for claim 1 is characterized in that,In described request message, a plurality of responses of said response mode option for postponing,The response message according to said response mode option generation that said reception server sends comprises:Receive the push-notification-answer message that said server sends; Wherein said push-notification-answer message is carried and is lived forever continuous time option most and stay time time option; The wherein said time time option that stays is used for indication; In the said continuous indicated time of time option of living forever most overtime after, client keeps the subscribing relationship with said server, the retention time is the said indicated time of candidate item of staying.
- 6. the method for claim 1 is characterized in that,In described request message, a plurality of responses of said response mode option for postponing,Described request message also comprises the retention time option,The response message according to said response mode option generation that said reception server sends comprises:In the time of said retention time option indication, first push-notification-answer that reception server sends, wherein said first push-notification-answer is for need not affirmation type message;In the time of said retention time option indication overtime after, receive second push-notification-answer that said server sends, wherein said second push-notification-answer is needs affirmation type message.Send affirmation ACK message to said server.
- 7. the method for claim 1 is characterized in that,In described request message, disposable response or disposable make an immediate response of said response mode option for postponing,Described request message also comprise the type of message indication information and deadline option, wherein said type of message indication information indication described request message is unitcast request, described request message is needs affirmation type message;The response message according to said response mode option generation that reception server sends comprises:Receive the specific affirmation message that said server sends; Wherein said specific affirmation message is carried response code and is postponed option turn-on time, wherein said response code represent said server said deadline option can't return response in indicated time to described request message;PerhapsReceive the affirmation message that said server sends;Receive the specific response message that said server sends; Wherein said specific response message carries response code and postpones option turn-on time, wherein said response code represent said server said deadline option can't return response in indicated time to described request message.
- 8. method as claimed in claim 7 is characterized in that,Remove the wait of buffer memory other request messages to said server transmission.
- 9. method as claimed in claim 7 is characterized in that,After indicated time, send described request message to said server at said delay option turn-on time again.
- 10. the method for claim 1 is characterized in that,In described request message, a plurality of responses of said response mode option for postponing,The response message that generates according to said response mode option that said reception server sends is a needs affirmation type message,Said method further comprises:Send specific affirmation message to said server; Wherein said specific affirmation message is carried response code and is postponed option turn-on time, and wherein said response code representes that client can't return the affirmation to said response message at said delay option turn-on time in indicated time;PerhapsSend acknowledge message to said server;Send specific response message to said server; Wherein said specific response message carries response code and postpones option turn-on time, and wherein said response code representes that said client can't return the affirmation to said response message at said delay option turn-on time in indicated time.
- 11. the method for claim 1 is characterized in that,Said response message comprises the response message rise time,Said method also comprises:Confirm the order of response message according to the said response message rise time.
- 12. one kind in Internet of things system based on the data resource transmission method of the node of lightweight application layer protocol, it is characterized in that,Receive the request message that carries the response mode option that client is sent, wherein said response mode option is represented wherein one of following response mode: a plurality of responses that a plurality of responses of the disposable disposable response that makes an immediate response, postpones, postponement and cancellation are postponed;Send the response message that generates according to said response mode option to client.
- 13. method as claimed in claim 12 is characterized in that,In described request message, disposable response or disposable make an immediate response of said response mode option for postponing,Described request message also comprise the type of message indication information and time of delay option, wherein said type of message indication information indication described request message is multicast request or unitcast request;Said to the response message of client transmission according to said response mode option generation, comprising:In the time of said option indication time of delay,, send response message to said client through after the random delay.
- 14. method as claimed in claim 13 is characterized in that,Described request message also comprises option deadline,Said to the response message of client transmission according to said response mode option generation, comprising:In the time of said deadline of option indication overtime before, send response message to said client.
- 15. like claim 13 or 14 described methods, it is characterized in that,Said type of message indication information is following wherein one:The preset socket port that is used to send the multicast request;The preset procotol IP address that is used to send the multicast request;The preset port numbers that is used to send the multicast request;Type of message indication option in the described request message.
- 16. method as claimed in claim 12 is characterized in that,In described request message, a plurality of responses of said response mode option for postponing,Said to the response message of client transmission according to said response mode option generation, comprising:Send push-notification-answer to said client; Wherein said first push-notification-answer carries and lives forever continuous time option most and stay time time option; The wherein said time time option that stays is used for indication; In the said indicated time of continuous time option of living forever most overtime after, server will respond in the indicated time at the said time time option that stays.
- 17. method as claimed in claim 12 is characterized in that,In described request message, a plurality of responses of said response mode option for postponing,Described request message also comprises the retention time option,Said to the response message of client transmission according to said response mode option generation, comprising:In the time of said retention time option indication, send the 3rd notice response to said client, wherein said the 3rd notice response is for need not affirmation type message;In the time of said retention time option indication overtime after, send four-way to said client and know response, wherein said four-way knows that response is needs affirmation type message;Receive the affirmation ACK message that said client is sent.
- 18. method as claimed in claim 12 is characterized in that,In described request message, disposable response or disposable make an immediate response of said response mode option for postponing,Described request message also comprise the type of message indication information and deadline option, wherein said type of message indication information indication described request message is unitcast request, described request message is needs affirmation type message;The said response message according to said response mode option generation that sends to client comprises:Send specific affirmation message to client; Wherein said specific acknowledge message is carried response code and is postponed option turn-on time, wherein said response code represent said server said deadline option can't return response in indicated time to described request message;PerhapsSend acknowledge message to client;Send specific response message to client; Wherein said specific response message carries response code and postpones option turn-on time, wherein said response code represent said server said deadline option can't return response in indicated time to described request message.
- 19. method as claimed in claim 18 is characterized in that,After indicated time, receive the described request message that said client resends at said delay option turn-on time.
- 20. method as claimed in claim 12 is characterized in that,In described request message, a plurality of responses of said response mode option for postponing,The said response message that generates according to said response mode option that sends to client is a needs affirmation type message,Said method further comprises:Receive the specific affirmation message that said client is sent; Wherein said specific affirmation message is carried response code and is postponed option turn-on time, and wherein said response code representes that said client can't return the affirmation to said response message at said delay option turn-on time in indicated time;PerhapsReceive the affirmation message that said client is sent;Receive said client and send specific response message; Wherein said specific response message carries response code and postpones option turn-on time, and wherein said response code representes that said client can't return the affirmation to said response message at said delay option turn-on time in indicated time.
- 21. method as claimed in claim 20 is characterized in that,In the indicated time of said delay option turn-on time overtime after, the said affirmation type response message that needs that resends to said client;Receive the affirmation message that said client is sent.
- 22. method as claimed in claim 12 is characterized in that,Said response message comprises the response message rise time.
- 23. one kind in Internet of things system based on the client of the data resource of lightweight application layer protocol transmission node, it is characterized in that, comprising:Sending module; Be used for sending the request message that carries the response mode option to server, wherein said response mode option is represented wherein one of following response mode: a plurality of responses that a plurality of responses of the disposable disposable response that makes an immediate response, postpones, postponement and cancellation are postponed;Receiver module is used to receive the response message that said server generates according to said response mode option.
- 24. client as claimed in claim 23 is characterized in that,In described request message, disposable response or disposable make an immediate response of said response mode option for postponing,Described request message also carry the type of message indication information and time of delay option, wherein said type of message indication information indication described request message is multicast request or unitcast request;Said receiver module was used in the time of said option indication time of delay, the response message that reception server sends.Described request message also comprises option deadline,Said receiver module be used in the time of said deadline of option indication overtime before, the response message that reception server sends.
- 25. one kind in Internet of things system based on the server of the data resource of lightweight application layer protocol transmission node, it is characterized in that, comprising:Receiver module; Be used to receive the request message that carries the response mode option that client is sent, wherein said response mode option is represented wherein one of following response mode: a plurality of responses that a plurality of responses of the disposable disposable response that makes an immediate response, postpones, postponement and cancellation are postponed;Sending module sends the response message that generates according to said response mode option to said client.
- 26. server as claimed in claim 25 is characterized in that,In described request message; Disposable response or disposable make an immediate response of said response mode option for postponing; Described request message also comprise the type of message indication information and time of delay option, wherein said type of message indication information indication described request message is multicast request or unitcast request;Said sending module is used in the time of said option indication time of delay, through after the random delay, sending response message to said client.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710131415.6A CN106878442B (en) | 2011-03-17 | 2012-03-06 | Method and device for transmitting data resources |
CN201210056456.0A CN102685204B (en) | 2011-03-17 | 2012-03-06 | Method and equipment for transmitting data resource |
CN201710132014.2A CN107071826B (en) | 2011-03-17 | 2012-03-06 | Method and device for transmitting data resources |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110064549.3 | 2011-03-17 | ||
CN2011100645493 | 2011-03-17 | ||
CN2011100645493A CN102130954A (en) | 2011-03-17 | 2011-03-17 | Method and device for transmitting data resources |
CN201210056456.0A CN102685204B (en) | 2011-03-17 | 2012-03-06 | Method and equipment for transmitting data resource |
Related Child Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710132014.2A Division CN107071826B (en) | 2011-03-17 | 2012-03-06 | Method and device for transmitting data resources |
CN201710131415.6A Division CN106878442B (en) | 2011-03-17 | 2012-03-06 | Method and device for transmitting data resources |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102685204A true CN102685204A (en) | 2012-09-19 |
CN102685204B CN102685204B (en) | 2017-04-26 |
Family
ID=44268843
Family Applications (7)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2011100645493A Pending CN102130954A (en) | 2011-03-17 | 2011-03-17 | Method and device for transmitting data resources |
CN201710132013.8A Active CN106850841B (en) | 2011-03-17 | 2012-03-02 | Method and device for transmitting data resources |
CN201710131638.2A Active CN107070990B (en) | 2011-03-17 | 2012-03-02 | Method and device for transmitting data resources |
CN201210054892.4A Active CN102685203B (en) | 2011-03-17 | 2012-03-02 | The method and apparatus of transmitting data resources |
CN201210056456.0A Active CN102685204B (en) | 2011-03-17 | 2012-03-06 | Method and equipment for transmitting data resource |
CN201710131415.6A Active CN106878442B (en) | 2011-03-17 | 2012-03-06 | Method and device for transmitting data resources |
CN201710132014.2A Active CN107071826B (en) | 2011-03-17 | 2012-03-06 | Method and device for transmitting data resources |
Family Applications Before (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2011100645493A Pending CN102130954A (en) | 2011-03-17 | 2011-03-17 | Method and device for transmitting data resources |
CN201710132013.8A Active CN106850841B (en) | 2011-03-17 | 2012-03-02 | Method and device for transmitting data resources |
CN201710131638.2A Active CN107070990B (en) | 2011-03-17 | 2012-03-02 | Method and device for transmitting data resources |
CN201210054892.4A Active CN102685203B (en) | 2011-03-17 | 2012-03-02 | The method and apparatus of transmitting data resources |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710131415.6A Active CN106878442B (en) | 2011-03-17 | 2012-03-06 | Method and device for transmitting data resources |
CN201710132014.2A Active CN107071826B (en) | 2011-03-17 | 2012-03-06 | Method and device for transmitting data resources |
Country Status (1)
Country | Link |
---|---|
CN (7) | CN102130954A (en) |
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103428273A (en) * | 2013-07-18 | 2013-12-04 | 北京百度网讯科技有限公司 | Method and device for responsive inquiry in asynchronous interaction |
CN104468594A (en) * | 2014-12-15 | 2015-03-25 | 北京奇虎科技有限公司 | Data request method, device and system |
WO2015070441A1 (en) * | 2013-11-15 | 2015-05-21 | 华为技术有限公司 | M2m network and application, common services entity, and information reply method |
CN105868029A (en) * | 2015-12-11 | 2016-08-17 | 鼎点视讯科技有限公司 | Consistency fault-tolerance processing method and system |
CN106303059A (en) * | 2016-08-24 | 2017-01-04 | 努比亚技术有限公司 | Electronic equipment and information processing method |
WO2017071118A1 (en) * | 2015-10-28 | 2017-05-04 | 西安中兴新软件有限责任公司 | Monitoring resource management method and apparatus, cse and storage medium |
CN106790603A (en) * | 2016-12-29 | 2017-05-31 | 东软集团股份有限公司 | The method of interacting message, apparatus and system |
CN106817314A (en) * | 2015-12-02 | 2017-06-09 | 中国电信股份有限公司 | Big data acquisition method, device and system |
CN107105035A (en) * | 2017-04-24 | 2017-08-29 | 常州信息职业技术学院 | A kind of smart home supervising device and monitoring system |
CN107960151A (en) * | 2015-05-04 | 2018-04-24 | 瑞典爱立信有限公司 | Delay response to request unit |
CN108809858A (en) * | 2017-04-28 | 2018-11-13 | 华为技术有限公司 | Method for controlling network congestion, equipment and system |
CN109586855A (en) * | 2017-09-29 | 2019-04-05 | 西安中兴新软件有限责任公司 | A kind of mobile unit data transmission method and device |
CN109936588A (en) * | 2017-12-15 | 2019-06-25 | 华为技术有限公司 | A kind of internet of things data transmission method, equipment and system |
CN112367387A (en) * | 2020-10-30 | 2021-02-12 | 湖北亿咖通科技有限公司 | Internet of vehicles communication method and system |
CN114125746A (en) * | 2021-11-19 | 2022-03-01 | 山东华科信息技术有限公司 | Dynamic CoAP mode selection method and device based on UCB |
CN114363831A (en) * | 2021-12-02 | 2022-04-15 | 北京万集科技股份有限公司 | Method, apparatus and computer-readable storage medium for transmitting V2X message |
Families Citing this family (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103227803A (en) * | 2012-01-30 | 2013-07-31 | 华为技术有限公司 | Internet of thing resource obtaining method, client and internet of thing resource devices |
CN103780483A (en) * | 2012-10-26 | 2014-05-07 | 中兴通讯股份有限公司 | Method, system and device for obtaining resource information of terminal device of Internet of Thingss |
CN104580396B (en) * | 2014-12-19 | 2018-07-20 | 华为技术有限公司 | A kind of method for scheduling task, node and system |
CN107222450A (en) * | 2016-03-21 | 2017-09-29 | 中兴通讯股份有限公司 | A kind of network node and realize the method and apparatus communicated between network node |
CN106331117B (en) * | 2016-08-26 | 2019-05-03 | 中国科学技术大学 | A kind of data transmission method |
US10191825B2 (en) * | 2017-03-01 | 2019-01-29 | Wipro Limited | System and method for testing a device using a light weight device validation protocol |
CN109729039B (en) * | 2017-10-27 | 2022-05-13 | 中兴通讯股份有限公司 | Negotiation fragmentation method and device of link management protocol |
CN107864135A (en) * | 2017-11-07 | 2018-03-30 | 山东网智物联网科技有限公司 | The realization device of Internet of Things communication means, device and Internet of Things Network Communication |
CN108599904B (en) * | 2018-03-21 | 2021-09-28 | 中兴通讯股份有限公司 | Data transmission method and device |
CN108834110B (en) * | 2018-05-30 | 2021-05-25 | 上海顺舟智能科技股份有限公司 | Data transmission control method and system of zigbee network |
CN108900370B (en) * | 2018-06-08 | 2021-12-17 | 努比亚技术有限公司 | Long connection multiple timeout judging method, device and computer readable storage medium |
CN110636551B (en) | 2018-06-25 | 2022-05-17 | 上海华为技术有限公司 | Method and device for avoiding message fragmentation |
CN110875952A (en) * | 2018-09-04 | 2020-03-10 | 中国移动通信有限公司研究院 | Data response processing method and equipment based on Internet of things and storage medium |
CN110881021B (en) * | 2018-09-06 | 2022-06-03 | 中国移动通信有限公司研究院 | MSRP fragment processing method and device, network equipment and storage medium |
CN109787884B (en) * | 2019-01-02 | 2021-03-12 | 中国联合网络通信集团有限公司 | Message pushing method and device |
KR102622252B1 (en) * | 2019-05-27 | 2024-01-08 | 삼성에스디에스 주식회사 | Apparatus and method for transmitting contents |
WO2021126024A1 (en) * | 2019-12-17 | 2021-06-24 | Telefonaktiebolaget Lm Ericsson (Publ) | Observation of resources by a coap client |
CN111083161A (en) * | 2019-12-27 | 2020-04-28 | 中消云(北京)物联网科技研究院有限公司 | Data transmission processing method and device and Internet of things equipment |
CN111259371B (en) * | 2020-01-13 | 2023-08-18 | 平安科技(深圳)有限公司 | Internet of things equipment authentication method, electronic device and storage medium |
CN112187931A (en) * | 2020-09-29 | 2021-01-05 | 中国平安财产保险股份有限公司 | Session management method, device, computer equipment and storage medium |
CN112541788B (en) * | 2020-12-11 | 2023-11-17 | 江西蔚乐科技有限公司 | Advertisement request method based on COAP protocol |
CN114884913A (en) * | 2022-01-10 | 2022-08-09 | 中国移动通信有限公司研究院 | Message interaction method and device, electronic equipment, message server and storage medium |
CN115103005B (en) * | 2022-06-14 | 2024-08-16 | 北京京东乾石科技有限公司 | Request response method, request response device, electronic equipment and storage medium |
CN118283833A (en) * | 2022-12-29 | 2024-07-02 | 维沃移动通信有限公司 | Resource determination method and device |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030202487A1 (en) * | 2002-04-26 | 2003-10-30 | Harris John M. | Method and apparatus for reducing call setup time |
CN101102282A (en) * | 2007-08-08 | 2008-01-09 | 中兴通讯股份有限公司 | A transmission and receiving method for data broadcast service |
CN101335742A (en) * | 2007-06-25 | 2008-12-31 | 中兴通讯股份有限公司 | Directory access system and method under lightweight directory access protocol |
CN101635744A (en) * | 2009-08-26 | 2010-01-27 | 华为技术有限公司 | Method and system for transmitting data and relative equipment |
Family Cites Families (27)
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 |
US6680921B1 (en) * | 1999-06-18 | 2004-01-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Estimation of time stamps in real-time packet communications |
US7239648B1 (en) * | 2001-11-27 | 2007-07-03 | Marvell International Ltd. | Extension mode for wireless lans complying with short interframe space requirement |
US9886309B2 (en) * | 2002-06-28 | 2018-02-06 | Microsoft Technology Licensing, Llc | Identity-based distributed computing for device resources |
KR20040087161A (en) * | 2003-04-04 | 2004-10-13 | 엘지전자 주식회사 | File content management method for mobile communication terminal |
WO2006020934A2 (en) * | 2004-08-13 | 2006-02-23 | Conexant Systems, Inc. | Systems and methods for decreasing latency in a digital transmission system |
CN100349088C (en) * | 2005-07-26 | 2007-11-14 | 华为技术有限公司 | Digital information controlling method |
CN1905518B (en) * | 2005-07-29 | 2010-12-01 | 北京航空航天大学 | Method for ensuring reliable transmission of data exchange |
ES2726017T3 (en) * | 2005-10-28 | 2019-10-01 | Viasat Inc | Adaptive coding and modulation for broadband data transmission |
CN100461673C (en) * | 2005-12-02 | 2009-02-11 | 华为技术有限公司 | Data-bag interacting method and personal field network communication apparatus |
CN100490380C (en) * | 2005-12-26 | 2009-05-20 | 北大方正集团有限公司 | Light distributed file storage system file uploading method |
CN101155054A (en) * | 2006-09-28 | 2008-04-02 | 华为技术有限公司 | Method and device for automatic detection and calculation of PCE path between autonomous system domains |
JP2008271312A (en) * | 2007-04-23 | 2008-11-06 | Matsushita Electric Ind Co Ltd | Radio packet communication apparatus |
US20080275808A1 (en) * | 2007-05-01 | 2008-11-06 | Instinet Europe Limited | Anonymous block trade matching system |
CN101374020B (en) * | 2007-08-20 | 2012-11-14 | 中兴通讯股份有限公司 | Centralized bandwidth distribution method for relay network |
CN101150506B (en) * | 2007-08-24 | 2011-07-06 | 华为技术有限公司 | Content acquisition method, device and content transmission system |
CN101471992B (en) * | 2007-12-24 | 2012-05-09 | 联想(北京)有限公司 | Mobile terminal and method for receiving or sending business information, and push-pull server |
CN101217402B (en) * | 2008-01-15 | 2012-01-04 | 杭州华三通信技术有限公司 | A method to enhance the reliability of the cluster and a high reliability communication node |
CN101222395B (en) * | 2008-02-03 | 2010-10-27 | 华为技术有限公司 | Method, system and device for implementing selection of network guiding configuration information |
CN101635703A (en) * | 2008-07-24 | 2010-01-27 | 北京启明星辰信息技术股份有限公司 | Method for detecting WEB service abnormality |
CN101729593A (en) * | 2008-11-03 | 2010-06-09 | 北大方正集团有限公司 | Method, system and device for uploading and receiving file |
CN101741701B (en) * | 2008-11-12 | 2012-01-11 | 中兴通讯股份有限公司 | Synchronous dispatching method and synchronous dispatching device |
CN101867882B (en) * | 2009-04-14 | 2015-10-21 | 中兴通讯股份有限公司 | Message sends and message feedback preprocess method |
US8582524B2 (en) * | 2009-05-25 | 2013-11-12 | Lg Electronics Inc. | Method for performing a bandwidth request procedure, and terminal apparatus for same |
CN101945427B (en) * | 2009-07-03 | 2012-11-14 | 深圳市融创天下科技股份有限公司 | Efficient streaming media transmission method |
CN101789958B (en) * | 2009-12-30 | 2013-06-05 | 中兴通讯股份有限公司 | Method, system and equipment of data synchronization based on equipment management service |
US10448390B2 (en) * | 2014-12-19 | 2019-10-15 | Qualcomm Incorporated | Transmission techniques for enabling an immediate response |
-
2011
- 2011-03-17 CN CN2011100645493A patent/CN102130954A/en active Pending
-
2012
- 2012-03-02 CN CN201710132013.8A patent/CN106850841B/en active Active
- 2012-03-02 CN CN201710131638.2A patent/CN107070990B/en active Active
- 2012-03-02 CN CN201210054892.4A patent/CN102685203B/en active Active
- 2012-03-06 CN CN201210056456.0A patent/CN102685204B/en active Active
- 2012-03-06 CN CN201710131415.6A patent/CN106878442B/en active Active
- 2012-03-06 CN CN201710132014.2A patent/CN107071826B/en active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030202487A1 (en) * | 2002-04-26 | 2003-10-30 | Harris John M. | Method and apparatus for reducing call setup time |
CN101335742A (en) * | 2007-06-25 | 2008-12-31 | 中兴通讯股份有限公司 | Directory access system and method under lightweight directory access protocol |
CN101102282A (en) * | 2007-08-08 | 2008-01-09 | 中兴通讯股份有限公司 | A transmission and receiving method for data broadcast service |
CN101635744A (en) * | 2009-08-26 | 2010-01-27 | 华为技术有限公司 | Method and system for transmitting data and relative equipment |
Cited By (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103428273B (en) * | 2013-07-18 | 2016-12-28 | 北京百度网讯科技有限公司 | The method and apparatus of response inquiry is carried out in asynchronous system is mutual |
CN103428273A (en) * | 2013-07-18 | 2013-12-04 | 北京百度网讯科技有限公司 | Method and device for responsive inquiry in asynchronous interaction |
WO2015070441A1 (en) * | 2013-11-15 | 2015-05-21 | 华为技术有限公司 | M2m network and application, common services entity, and information reply method |
CN104468594A (en) * | 2014-12-15 | 2015-03-25 | 北京奇虎科技有限公司 | Data request method, device and system |
CN104468594B (en) * | 2014-12-15 | 2018-04-27 | 北京奇安信科技有限公司 | The method, apparatus and system of a kind of request of data |
CN107960151A (en) * | 2015-05-04 | 2018-04-24 | 瑞典爱立信有限公司 | Delay response to request unit |
WO2017071118A1 (en) * | 2015-10-28 | 2017-05-04 | 西安中兴新软件有限责任公司 | Monitoring resource management method and apparatus, cse and storage medium |
CN106817314A (en) * | 2015-12-02 | 2017-06-09 | 中国电信股份有限公司 | Big data acquisition method, device and system |
CN105868029A (en) * | 2015-12-11 | 2016-08-17 | 鼎点视讯科技有限公司 | Consistency fault-tolerance processing method and system |
CN106303059A (en) * | 2016-08-24 | 2017-01-04 | 努比亚技术有限公司 | Electronic equipment and information processing method |
CN106790603A (en) * | 2016-12-29 | 2017-05-31 | 东软集团股份有限公司 | The method of interacting message, apparatus and system |
CN107105035A (en) * | 2017-04-24 | 2017-08-29 | 常州信息职业技术学院 | A kind of smart home supervising device and monitoring system |
CN108809858A (en) * | 2017-04-28 | 2018-11-13 | 华为技术有限公司 | Method for controlling network congestion, equipment and system |
CN108809858B (en) * | 2017-04-28 | 2020-11-10 | 华为技术有限公司 | Network congestion control method, equipment and system |
CN109586855A (en) * | 2017-09-29 | 2019-04-05 | 西安中兴新软件有限责任公司 | A kind of mobile unit data transmission method and device |
CN109936588A (en) * | 2017-12-15 | 2019-06-25 | 华为技术有限公司 | A kind of internet of things data transmission method, equipment and system |
CN109936588B (en) * | 2017-12-15 | 2021-08-31 | 华为技术有限公司 | Internet of things data transmission method, equipment and system |
US11146362B2 (en) | 2017-12-15 | 2021-10-12 | Huawei Technologies Co., Ltd. | Internet of things data transmission method, device and system |
CN112367387A (en) * | 2020-10-30 | 2021-02-12 | 湖北亿咖通科技有限公司 | Internet of vehicles communication method and system |
CN114125746A (en) * | 2021-11-19 | 2022-03-01 | 山东华科信息技术有限公司 | Dynamic CoAP mode selection method and device based on UCB |
CN114125746B (en) * | 2021-11-19 | 2022-08-16 | 山东华科信息技术有限公司 | Dynamic CoAP mode selection method and device based on UCB |
CN114363831A (en) * | 2021-12-02 | 2022-04-15 | 北京万集科技股份有限公司 | Method, apparatus and computer-readable storage medium for transmitting V2X message |
Also Published As
Publication number | Publication date |
---|---|
CN107071826B (en) | 2020-07-07 |
CN106850841B (en) | 2020-11-17 |
CN106878442B (en) | 2020-12-04 |
CN102685203A (en) | 2012-09-19 |
CN107070990B (en) | 2021-04-09 |
CN106850841A (en) | 2017-06-13 |
CN102685203B (en) | 2017-07-07 |
CN102685204B (en) | 2017-04-26 |
CN107070990A (en) | 2017-08-18 |
CN107071826A (en) | 2017-08-18 |
CN102130954A (en) | 2011-07-20 |
CN106878442A (en) | 2017-06-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102685204A (en) | Method and equipment for transmitting data resource | |
KR100781911B1 (en) | Downloading web pages | |
Lindgren et al. | Probabilistic routing protocol for intermittently connected networks | |
US20170373804A1 (en) | Methods for enabling delay-awareness in the constrained application protocol (coap) | |
CN105323205A (en) | Message pushing processing method, message pushing processing device, pushing server and application server | |
JP2011072004A (en) | Process control system and method of communicating application information | |
EP3360374B1 (en) | Network node, wireless device and methods performed thereby for the network node to provide information to the wireless device | |
CN107567107B (en) | Data transmission method and device | |
CN112217649B (en) | Terminal equipment management method, server and terminal equipment | |
US11057158B2 (en) | Delegation of management of acknowledgements and of transmission of frames | |
WO2020118633A1 (en) | Subscription message processing method and apparatus, and computer device and storage medium | |
CN110944323A (en) | Method for managing handover roaming | |
JP6403556B2 (en) | Gateway device, smart meter and wireless mesh network | |
CN113992307A (en) | Data message transmission method and device, electronic equipment and computer storage medium | |
CN104159289B (en) | The certification register method and device of home terminal | |
CN107786607B (en) | Message retransmission method, message retransmission server and user equipment | |
CN113055193A (en) | Data multicast transmission method, device, equipment and storage medium | |
US7701873B2 (en) | Method for the discovery of devices connected to an IP network and device to carry out said method | |
CN114051030B (en) | Communication method, communication device, intelligent community system and storage medium | |
JP2002169738A (en) | File distributing method | |
Gómez Montenegro et al. | Constrained Application Protocol (CoAP) over Bundle Protocol (BP) | |
WO2004071027A1 (en) | Methods and systems for non-disruptive physical address resolution | |
KR100921491B1 (en) | Message transmission method without loss in ring-type communication network | |
CN116346293A (en) | Message retransmission method, device, equipment and medium in cluster communication | |
CN116016396A (en) | Processing method, processing device, processing equipment and medium for resending message |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |