CN102291319A - Delay tolerant network system structure based on content naming - Google Patents
Delay tolerant network system structure based on content naming Download PDFInfo
- Publication number
- CN102291319A CN102291319A CN201110286993XA CN201110286993A CN102291319A CN 102291319 A CN102291319 A CN 102291319A CN 201110286993X A CN201110286993X A CN 201110286993XA CN 201110286993 A CN201110286993 A CN 201110286993A CN 102291319 A CN102291319 A CN 102291319A
- Authority
- CN
- China
- Prior art keywords
- node
- content
- response message
- request
- data
- 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
Abstract
The invention relates to a delay tolerant network system structure based on content naming, belonging to the technical field of computer network application. The network system structure specifically has the technical characteristics that: a network convergence layer comprises a request message and a response message; meanwhile, a request message list, a response message header information list and a content data buffer area are maintained in the network convergence layer; the request message and the response message have respective generating process, processing process and forwarding process; and new data are published by using a data publishing process. In the delay tolerant network system structure provided by the invention, information acquisition and distribution according to content names are supported on the basis of inheriting the inherent delay tolerant capacitance breaking characteristic of a delay tolerant network by taking contents as a center, and the contents are buffered autonomously on a network node simultaneously, so that the content usability can be effectively enhanced, and the assess time is shortened.
Description
Technical field
The present invention relates to a kind of Delay Tolerant Network (Delay Tolerant Network) architecture, be specifically related to a kind of Delay Tolerant Network architecture of content-based name, belong to applications of computer network technical field.
Background technology
Content distribution service is provided in network, can directly provides them interested data to the user.But the research of existing subscription dissemination system and design are many based on fixed network or mobility network (as self-organizing or sensor network) more stably, they do not support mobility to be in the network equipment and the deployment scenario thereof of intermittent connection status very by force or often, therefore can't directly apply to Delay Tolerant Network.
Existing research at the Delay Tolerant Network content service is also few.Wherein a kind of system is made up of mobile subscriber, information station and the server that is positioned at backbone network.The user sends subscribe request to the information station that meets in moving process, information station sends to the backbone network server by the discontinuity connection with request, server calculates the matching degree of content event and all subscribe request of information station, determine the priority of incident with this, and select the incident of high priority to be pushed to this information station at this information station.Has data dispense characteristics in another system based on periodic broadcast, carry the vehicle of event message and periodically broadcast this message, the metadata of while broadcast event in the single-hop scope is also collected the request of all neighbor nodes to this incident, to subscribe to vehicle then and be divided in different bunches, and forwards given drive towards the vehicle of subscribing to maximum bunches of nodes according to travel direction.Data become different " channel " according to its content type tissue and store on node in the third system.It is interested in which kind of information with expression that the user can subscribe to accordingly " channel ".Node carries out the download of data in the time can inserting the Internet, carry out the distribution of data when two nodes meet.Node can initiatively not send data to the other side, but takes " recipient's driving " to wait for that promptly the other side is that the mode of unit request msg is carried out exchanges data with " channel ".Above system is not all from the angle design of architecture with realize content distribution service.
The characteristics of Delay Tolerant Network are to use the hop-by-hop transmission mode of " storing-carry-transmit " to realize sending of data, and forward node data of transmitting of buffer memory possibly all are convenient to the user and are obtained data nearby in the middle of each.But the memory model in traditional Delay Tolerant Network architecture still is in the same place source, destination address and ties content, do not support the mode of the information of obtaining by name, though a considerable amount of message that this has just caused on each node all buffer memory, but content is identical and data that the address is different can not be reused, and has caused the problem that resource efficiency is low, resource consumption big, routing performance is poor, can not effectively utilize less touch opportunity.
Summary of the invention
The objective of the invention is in order to overcome the defective of prior art, the problem that causes that the resource efficiency that exists in the information exchanging process is low, resource consumption big, routing performance is poor, can not effectively utilize less touch opportunity because of existing Delay Tolerant Network defective structurally for a change, make content identical and data that the address is different can be reused, thereby propose a kind of new Delay Tolerant Network architecture.
The technical solution adopted in the present invention is as follows:
A kind of Delay Tolerant Network architecture of content-based name has following technical characterictic:
One,, comprises two kinds of message of request message and response message at Network Convergence Layer.Wherein, described request message comprises content name, source requesting node sign, " source requesting node sign " length, destination node sign, " destination node sign " length and life cycle.Described response message comprises content name, responsive node sign, " responsive node sign " length, destination node sign, " destination node sign " length, life cycle and content-data load, and the information general designation except that the content-data load is made the header information of response message.
Simultaneously, at Network Convergence Layer, maintenance has list of request messages, tabulation of response message header information and content-data buffering area.Wherein, the form of list of request messages is: the settling time of content name, source requesting node sign, " source requesting node sign " length, destination node sign, " destination node sign " length, life cycle and list item.The form of response message header information tabulation is: the settling time of content name, responsive node sign, responsive node sign length, destination node sign, destination node sign length, life cycle and list item.The form of content-data buffering area is: the requested number of times of content name, content-data, life cycle and data.
Two, request message and response message all have separately generative process, processing procedure and repeating process.
The generative process of described request message is as follows:
At first, encapsulate new request message.Wherein, the content of content name and lifetime field is provided by upper layer application, and requesting node sign in source is provided by node self with " source requesting node sign " length field content.
Then, node is searched in the content-data buffering area of this locality according to the content name in the new request message.If find, then directly data and title thereof are back to upper layer application; If do not find, then in the light of actual conditions fill the destination node identification field in following three kinds of modes, this field can have a plurality of node identifications simultaneously:
(1) should mail to which node if node is known this request, then directly the node identification of correspondence be inserted this field;
(2) if node does not know which node this request should mail to, but can learn suitable destination node, then after this process, the node identification of correspondence be inserted this field by approach such as inquire about to service node;
(3) if node can't be determined the destination node of this request, then this field is NULL, and request is propagated in network by the mode of broadcasting.
The processing procedure of request message is as follows:
At first, judge the source of request message.If the request message that receives from other nodes, then at first search local request list, if wherein have the equal identical list item of request message therewith of all fields except that lifetime field, then directly this request abandoned, otherwise proceed following judgement.If the request message that node self generates then directly joins request message in the list of request messages, otherwise proceeds following judgement.
Then, judge whether this request message is broadcast request.If this request message is not a broadcast, then directly request message is joined in the list of request messages; If broadcast, then the message searching has the destination node of its request msg content for this reason, if find, then it is inserted the destination node identification field, is the state of NULL otherwise keep the destination node identification field;
At last, request message is joined in the list of request messages.If new request message content name field and destination node identification field are identical with certain existing list item, then requesting node identification field in source in the new request message and former list item are merged, wherein, get the maximum of the two life cycle, upgrading list item settling time is current time.Otherwise in list of request messages, set up the new information item, be filled to current time the settling time of list item for it.
The repeating process of request message is as follows:
At first, when meeting, check each the bar record in the list of request messages with middle forward node.If the broadcast item, then the information of list item is encapsulated as new solicited message by the mode of field correspondence, and sends by available link with intermediate node.
If be non-broadcast item, then judge in proper order constantly according to the foundation of these list items according to concrete routing algorithm, transmit if list item is suitable, then the information of list item is encapsulated as new solicited message by the mode of field correspondence, and send, otherwise do not process by available link with intermediate node.
The header information generative process of described response message is as follows:
At first, search in local content-data buffering area according to content name field in the request message.If find, then generate the header information of response message, responsive node is designated the present node sign, and destination node is designated requesting node identification field in source in the request message that is responded, and lifetime field is the life cycle of corresponding data.If do not find, end the header information generative process of response message.
Then, the header information with the response message that generates joins in the local response message header information tabulation.If in tabulation, have content name and destination node identification field and the new identical list item of header information, then the two is merged, the life cycle of fetching data life cycle, the creation-time that upgrades list items simultaneously is a current time.Otherwise in the response message tabulation, set up the new information item, be filled to current time the settling time of list item for it.At last, in list of request messages with the content name correspondence table entry deletion of above-mentioned generation response message header information.
The repeating process of response message is as follows:
At first, when meeting with middle forward node, according to concrete routing algorithm, settling time according to each list item in the tabulation of response message header information they are judged, if list item is not suitable for transmitting, then do not process, if suitable the forwarding then generates new response message on the basis of list item information.
At this moment, earlier the responsive node identification field is replaced with the present node sign, and the other guide in the list item copied in the new response message according to corresponding field go, in the content-data buffering area of this locality, extract the data corresponding then with this contents in table name field, and it is positioned in the content-data load field, lifetime field adopts the life cycle identical with content-data, and the number of times that is requested in this data table items of content-data buffering area adds 1;
At last, response message is sent by the available link with intermediate node.
The processing procedure of response message is as follows:
When node receiving that other nodes are transmitted during the response message that comes, at first in the response message header information tabulation of this locality, search, if there are except that life cycle and content-data load field all identical list items of response message therewith of all fields, then think the repeatability response, directly it is abandoned; If do not find, then the data in the content-data load field and lifetime field are converted into the form of content-data buffering area and add wherein, other fields are joined during the response message header information tabulates as new list item.
Three, use the issuing process issue new data of data.Specific as follows:
When the upper strata had new data to generate, content name and the life cycle of utilizing the upper strata to provide, the form that is converted into the content-data buffering area also added wherein;
Then, in local solicited message tabulation, search whether satiable list item is arranged,, then operate according to response message header information generative process if find according to new content name.
Beneficial effect
The Delay Tolerant Network architecture of content-based name proposed by the invention, with the content is the center, on the basis of inheriting the disconnected feature of the intrinsic Rong Chirong of Delay Tolerant Network, support is obtained and distributing information by content name, content cushions on network node autonomously simultaneously, can effectively improve the availability of content, reduce the time of visit.
Embodiment
Below in conjunction with embodiment the present invention is described in further details.
Relevant noun terminological interpretation is as follows:
Middle forward node: for different message.According to the network design situation, it can be can receive the node of this message except that the source node of message and the destination node any one, also can be the node that a class is responsible for pass-along message between node specially in the network.
Network Convergence Layer: for multiple different technology or the agreement under the Network Convergence Layer.Network Convergence Layer can be realized the upper strata is hidden these differences, and the function of consistency service is provided.
Embodiment
A kind of Delay Tolerant Network architecture of content-based name, the process of its Data transmission is as follows:
The generative process of request message is as described below:
At first, need ask name to be called the data of "/weather/China/Beijing/20110801 " upper layer application, offered convergence-level the life cycle " 1:00:00 " of this title and user's setting, and convergence-level will be pressed table 1 form in conjunction with " source requesting node sign " and " ' source requesting node sign ' length " content that node self provides and be generated request message:
Table 1
Then, node is searched in local buffer according to content name "/weather/China/Beijing/20110801 ", supposed that node A local buffer is as shown in table 2, then can find corresponding data, directly these data and title thereof are returned to upper layer application;
Table 2
If do not find, then in the light of actual conditions fill " destination node sign " field in three kinds of modes, this field can have a plurality of node identifications simultaneously:
(1) if node knows by modes such as local historical informations which node this request should mail to, then directly the node identification of correspondence is inserted this field, example is as shown in table 3:
Table 3
(2) if node and do not know which node this request should mail to, but can learn the appropriate purpose node by approach such as inquire about to service node or database, then after this process, the node identification of correspondence is inserted this field, example is as shown in table 4:
Table 4
(3) if node can't be determined the destination node of this request, then this field is NULL, and request is propagated in network by the mode of broadcasting earlier, and example is as shown in table 5:
Table 5
The processing procedure of request message is as follows:
With the Node B is example, if the request message that himself produces then directly joins request message in the list of request messages; If from other nodes, node A for example, the request message that receives is then at first searched local request list, suppose that Node B this locality request list is as shown in table 6:
Table 6
If have all identical list item of all fields except that " life cycle " field, then directly this request abandoned, otherwise carry out following judgement with the request message that receives.For example the message shown in the table 7 is the request message that should abandon in these cases:
Table 7
If this request message is not a broadcast, then directly request message is joined in the list of request messages; If broadcast, then attempt for this reason message and seek and have the destination node of its request msg content,, then it is inserted " destination node sign " field if find, otherwise maintenance " destination node sign " field is the state of NULL;
At last, request message is joined in the list of request messages, if new request message " content name " field and " destination node sign " field are identical with certain existing list item, then " source requesting node sign " field and former list item in the new request message can be merged, upgrading life cycle is the maximum of the two, and upgrading list item settling time simultaneously is current time; If as shown in table 8 from the request message that node A receives:
Table 8
The local request list of Node B after then merging is as shown in table 9:
Table 9
Otherwise, in list of request messages, set up the new information item for it, be current time the settling time of list item, supposes that the request message that receives from node A is as shown in table 10:
Table 10
The local request list of Node B after then it being added is as shown in table 11:
Table 11
The request message repeating process is as follows:
When meeting with middle forward node, check each the bar record in the list of request messages, if the broadcast item, then the information of list item is encapsulated as new solicited message by the mode of field correspondence, and sends by available link with intermediate node.With the Node B is example, supposes that its current request messaging list is as shown in table 12:
Table 12
If be non-broadcast item, need to judge in proper order constantly according to the foundation of these list items according to concrete routing algorithm, if list item is not suitable for transmitting, then do not deal with; Transmit if list item is suitable, then the information of list item is encapsulated as new solicited message by the mode of field correspondence, and sends by available link with intermediate node.Newly-generated request message example is as shown in table 13:
Table 13
Response message header information generative process is as follows:
At first, search in local content-data buffering area according to " content name " field in the request message, if find, then generate the header information of response message, " responsive node sign " is the present node sign, " destination node sign " is " source requesting node sign " field in the quilt request message that responds, and " life cycle " field is the life cycle of corresponding data.If do not find, then end corresponding message header information generative process.With the Node B is example, if it is as shown in table 14 from the request message that node A receives:
Table 14
And the current local content buffering area of Node B is as shown in Table 15:
Table 15
| Content name | Content-data | Life cycle | The requested number of times of data |
| / train number/T31/20110801 | Beijing is to Nanchang, 15:01～next day 8:18... | 12:26 | 7 |
| / weather/China/Beijing/20110801 | Cloudy cloudy with occasional showers 20～28 ℃ of daytime tomorrow ... | 50:03 | 2 |
| / stock/the Shanghai composite index/20110731 | 2820.17，+0.35％ | 29:37 | 16 |
| ... | ... | ... | ... |
Then the new response message header information of Sheng Chenging is shown in table 16:
Table 16
Then, the header information of the response message that generates is joined in the local response message header information tabulation, if in tabulation, have " content name " and " destination node sign " field and the new identical list item of header information, then the two can be merged, the life cycle of fetching data life cycle, the creation-time that upgrades list items simultaneously is a current time; If the new response message header information that generates is shown in table 17:
Table 17
Response information node B header information tabulation after then merging is shown in table 18:
Table 18
Otherwise, in the response message tabulation, set up the new information item for it, be current time the settling time of list item.Suppose that the new response message header information that generates is shown in table 16, then the tabulation of the response message header information of Node B is shown in table 19:
Table 19
At last, in list of request messages with " content name " correspondence table entry deletion of above-mentioned generation response message header information; If the new response message header information that generates is shown in table 20:
Table 20
Shown in table 21 before the deletion of Node B list of request messages:
Table 21
Node B list of request messages deletion back is shown in table 22:
Table 22
The response message repeating process is as follows:
When meeting,,,, then do not deal with if list item is not suitable for transmitting according to the settling time of each list item in the tabulation of response message header information they being judged according to concrete routing algorithm with middle forward node; Transmit if list item is suitable, then on the basis of list item information, generate new response message, at first " responsive node sign " field is replaced with the present node sign, and the other guide in the list item copied in the new response message according to corresponding field go, in the content-data buffering area of this locality, extract then and the corresponding data of this list item " content name " field, and it is positioned in " content-data load " field, " life cycle " field adopts the life cycle identical with content-data, and the number of times that is requested in the content-data buffering area in this data table items adds 1; With the Node B is example, supposes that its current content data buffering area is shown in table 23:
Table 23
| Content name | Content-data | Life cycle | The requested number of times of data |
| / train number/T31/20110801 | Beijing is to Nanchang, 15:01～next day 8:18... | 12:26 | 7 |
| / weather/China/Beijing/20110801 | Cloudy cloudy with occasional showers 20～28 ℃ of daytime tomorrow ... | 50:03 | 3 |
| / stock/the Shanghai composite index/20110731 | 2820.17，+0.35％ | 29:37 | 16 |
| ... | ... | ... | ... |
The tabulation of response message header information is shown in table 24:
Table 24
Then the new response message of Sheng Chenging is as shown in Table 25:
Table 25
At last, response message is sent by the available link with intermediate node.
The processing procedure of response message is as follows:
When node receiving that other nodes are transmitted during the response message that comes, at first in the response message header information tabulation of this locality, search, if there are except that " life cycle " and " content-data load " field all identical list items of response message therewith of all fields, then think the repeatability response, directly it is abandoned; With the Node B is example, if current its response message tabulation is shown in table 26:
Table 26
Then the response message that should abandon is shown in table 27:
Table 27
If do not find, then the data in " content-data load " field and " life cycle " field are converted into the form of content-data buffering area and add wherein, other fields are joined in the response message header list as new list item; If shown in table 28 from the response message that node N receives:
Table 28
Then the tabulation of the response message header information of Node B is shown in table 29:
Table 29
The content-data buffering area of Node B is shown in table 30:
Table 30
| Content name | Content-data | Life cycle | The requested number of times of data |
| / train number/T31/20110801 | Beijing is to Nanchang, 15:01～next day 8:18... | 12:26 | 7 |
| / weather/China/Beijing/20110801 | Cloudy cloudy with occasional showers 20～28 ℃ of daytime tomorrow ... | 50:03 | 3 |
| / stock/the Shanghai composite index/20110731 | 2820.17，+0.35％ | 29:37 | 16 |
| / stock/China Mobile/20110801 | 72.15(+0.30，％0.42) | 49:08 | 0 |
| ... | ... | ... | ... |
The issuing process of data is as follows:
When the upper strata had new data to generate, content name and the life cycle of utilizing the upper strata to provide, the form that is converted into the content-data buffering area also added wherein, and the request number of times initial value is 0; If the information that gets access to from the upper strata is shown in table 31:
Table 31
Then the data content buffering area of node this locality is shown in table 32:
Table 32
Then, in local solicited message tabulation, search whether satiable list item is arranged,, then carry out response message header information generative process if find according to new " content name ".
Claims (1)
1. the Delay Tolerant Network architecture of a content-based name is characterized in that having following technical characterictic:
At Network Convergence Layer, comprise two kinds of message of request message and response message: request message comprises content name, source requesting node sign, " source requesting node sign " length, destination node sign, " destination node sign " length and life cycle; Response message comprises content name, responsive node sign, " responsive node sign " length, destination node sign, " destination node sign " length, life cycle and content-data load, wherein, the general designation of the information except that the content-data load is made the header information of response message;
Simultaneously, at Network Convergence Layer, maintenance has list of request messages, tabulation of response message header information and content-data buffering area; Wherein, the form of list of request messages is: the settling time of content name, source requesting node sign, " source requesting node sign " length, destination node sign, " destination node sign " length, life cycle and list item; The form of response message header information tabulation is: the settling time of content name, responsive node sign, responsive node sign length, destination node sign, destination node sign length, life cycle and list item; The form of content-data buffering area is: the requested number of times of content name, content-data, life cycle and data;
Request message and response message have generative process, processing procedure and repeating process separately;
The generative process of described request message is as follows:
At first, encapsulate new request message; Wherein, the content of content name and lifetime field is provided by upper layer application, and requesting node sign in source is provided by node self with " source requesting node sign " length field content;
Then, node is searched in the content-data buffering area of this locality according to the content name in the new request message; If find, then directly data and title thereof are back to upper layer application; If do not find, then in the light of actual conditions fill the destination node identification field in following three kinds of modes, this field can have a plurality of node identifications simultaneously:
(1) should mail to which node if node is known this request, then directly the node identification of correspondence be inserted this field;
(2) if node does not know which node this request should mail to, but can learn suitable destination node, then after this process, the node identification of correspondence be inserted this field by approach such as inquire about to service node;
(3) if node can't be determined the destination node of this request, then this field is NULL, and request is propagated in network by the mode of broadcasting;
The processing procedure of request message is as follows:
At first, judge the source of request message; If the request message that receives from other nodes, then at first search local request list, if wherein have the equal identical list item of request message therewith of all fields except that lifetime field, then directly this request abandoned, otherwise proceed following judgement; If the request message that node self generates then directly joins request message in the list of request messages, otherwise proceeds following judgement;
Then, judge whether this request message is broadcast request; If this request message is not a broadcast, then directly request message is joined in the list of request messages; If broadcast, then the message searching has the destination node of its request msg content for this reason, if find, then it is inserted the destination node identification field, is the state of NULL otherwise keep the destination node identification field;
At last, request message is joined in the list of request messages; If new request message content name field and destination node identification field are identical with certain existing list item, then requesting node identification field in source in the new request message and former list item are merged, wherein, get the maximum of the two life cycle, upgrading list item settling time is current time; Otherwise in list of request messages, set up the new information item, be filled to current time the settling time of list item for it;
The repeating process of request message is as follows:
At first, when meeting, check each the bar record in the list of request messages with middle forward node; If the broadcast item, then the information of list item is encapsulated as new solicited message by the mode of field correspondence, and sends by available link with intermediate node;
If be non-broadcast item, then judge in proper order constantly according to the foundation of these list items according to concrete routing algorithm, transmit if list item is suitable, then the information of list item is encapsulated as new solicited message by the mode of field correspondence, and send, otherwise do not process by available link with intermediate node;
The header information generative process of described response message is as follows:
At first, search in local content-data buffering area according to content name field in the request message; If find, then generate the header information of response message, responsive node is designated the present node sign, and destination node is designated requesting node identification field in source in the request message that is responded, and lifetime field is the life cycle of corresponding data; If do not find, end the header information generative process of response message;
Then, the header information with the response message that generates joins in the local response message header information tabulation; If in tabulation, have content name and destination node identification field and the new identical list item of header information, then the two is merged, the life cycle of fetching data life cycle, the creation-time that upgrades list items simultaneously is a current time; Otherwise in the response message tabulation, set up the new information item, be filled to current time the settling time of list item for it; At last, in list of request messages with the content name correspondence table entry deletion of above-mentioned generation response message header information;
The repeating process of response message is as follows:
At first, when meeting with middle forward node, according to concrete routing algorithm, settling time according to each list item in the tabulation of response message header information they are judged, if list item is not suitable for transmitting, then do not process, if suitable the forwarding then generates new response message on the basis of list item information;
At this moment, earlier the responsive node identification field is replaced with the present node sign, and the other guide in the list item copied in the new response message according to corresponding field go, in the content-data buffering area of this locality, extract the data corresponding then with this contents in table name field, and it is positioned in the content-data load field, lifetime field adopts the life cycle identical with content-data, and the number of times that is requested in this data table items of content-data buffering area adds 1;
At last, response message is sent by the available link with intermediate node;
The processing procedure of response message is as follows:
When node receiving that other nodes are transmitted during the response message that comes, at first in the response message header information tabulation of this locality, search, if there are except that life cycle and content-data load field all identical list items of response message therewith of all fields, then think the repeatability response, directly it is abandoned; If do not find, then the data in the content-data load field and lifetime field are converted into the form of content-data buffering area and add wherein, other fields are joined during the response message header information tabulates as new list item;
In present network architecture, use the issuing process issue new data of data, specific as follows:
When the upper strata had new data to generate, content name and the life cycle of utilizing the upper strata to provide, the form that is converted into the content-data buffering area also added wherein;
Then, in local solicited message tabulation, search whether satiable list item is arranged,, then operate according to response message header information generative process if find according to new content name.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201110286993XA CN102291319B (en) | 2011-09-25 | 2011-09-25 | Design method of delay tolerant network system structure based on content naming |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201110286993XA CN102291319B (en) | 2011-09-25 | 2011-09-25 | Design method of delay tolerant network system structure based on content naming |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN102291319A true CN102291319A (en) | 2011-12-21 |
| CN102291319B CN102291319B (en) | 2013-11-06 |
Family
ID=45337437
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201110286993XA Expired - Fee Related CN102291319B (en) | 2011-09-25 | 2011-09-25 | Design method of delay tolerant network system structure based on content naming |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102291319B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104301237A (en) * | 2014-10-13 | 2015-01-21 | 湖北交通职业技术学院 | Data subscription and distribution method applicable to delay-tolerant and disconnection-tolerant network |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101414965A (en) * | 2008-12-04 | 2009-04-22 | 天津大学 | Method for saving node energy of delay-tolerant network and intermittently-connected network |
| CN101414964A (en) * | 2008-12-04 | 2009-04-22 | 天津大学 | Method for reducing redundant message of delay-tolerant network and intermittently-connected network |
| US20090129316A1 (en) * | 2007-08-20 | 2009-05-21 | Bbn Technologies Corp. | Systems and methods for adaptive routing in mobile ad-hoc networks and disruption tolerant networks |
-
2011
- 2011-09-25 CN CN201110286993XA patent/CN102291319B/en not_active Expired - Fee Related
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090129316A1 (en) * | 2007-08-20 | 2009-05-21 | Bbn Technologies Corp. | Systems and methods for adaptive routing in mobile ad-hoc networks and disruption tolerant networks |
| CN101414965A (en) * | 2008-12-04 | 2009-04-22 | 天津大学 | Method for saving node energy of delay-tolerant network and intermittently-connected network |
| CN101414964A (en) * | 2008-12-04 | 2009-04-22 | 天津大学 | Method for reducing redundant message of delay-tolerant network and intermittently-connected network |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104301237A (en) * | 2014-10-13 | 2015-01-21 | 湖北交通职业技术学院 | Data subscription and distribution method applicable to delay-tolerant and disconnection-tolerant network |
| CN104301237B (en) * | 2014-10-13 | 2017-05-10 | 湖北交通职业技术学院 | Data subscription and distribution method applicable to delay-tolerant and disconnection-tolerant network |
Also Published As
| Publication number | Publication date |
|---|---|
| CN102291319B (en) | 2013-11-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Chen et al. | Leveraging social networks for P2P content-based file sharing in disconnected MANETs | |
| CN101355468B (en) | Method for publishing P2P stream medium information | |
| CN102868936B (en) | Method and system for storing video logs | |
| CN104284201A (en) | Video content processing method and device | |
| CN101447937A (en) | Rapid data positioning method based on path division and multi-distributed-directory | |
| CN101237429A (en) | Stream media living broadcasting system, method and device based on content distribution network | |
| CN102843420A (en) | Fuzzy division based social network data distribution system | |
| CN104901860A (en) | System and method for interconnection and intercommunication of NDN and CDN | |
| CN103107944B (en) | A kind of content positioning method and routing device | |
| CN108124168A (en) | A kind of video sharing method perceived under mobile radio network based on user interest | |
| CN108881444A (en) | A kind of content popularit is distributed the asynchronous code cache method of inconsistent mist wireless access network | |
| Bok et al. | A resource discovery with data dissemination over unstructured mobile P2P networks | |
| Li et al. | SCOM: A scalable content centric network architecture with mobility support | |
| CN102891797A (en) | Publishing and subscription method capable of supporting message duration | |
| Shi et al. | Tinymq: A content-based publish/subscribe middleware for wireless sensor networks | |
| CN102075974B (en) | Method for searching high contiguity resources in wireless sensor network | |
| CN103825916A (en) | Resource downloading method and resource downloading system | |
| Wang et al. | Social-aware video delivery: Challenges, approaches, and directions | |
| CN102291319B (en) | Design method of delay tolerant network system structure based on content naming | |
| CN101895550B (en) | Cache accelerating method for compatibility of dynamic and static contents of internet website | |
| CN103888517A (en) | Caching method for publishing and subscription system to achieve historical event subscription | |
| CN102075584A (en) | Distributed file system and access method thereof | |
| Xiong et al. | Effective data transmission based on cluster user communications in opportunistic complexity social networks | |
| CN103475948A (en) | P2P live video based intelligent resource matching system | |
| CN105447188A (en) | Knowledge learning based peer-to-peer social network document retrieval method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20131106 Termination date: 20170925 |