Patent Application
20150019755
The present application relates to and claims priority from Japanese Patent Application No. 2012-590 filed on Jan. 5, 2012 and Japanese Patent Application No. 2012-160104 filed on Jul. 19, 2012. The entirety of the contents and subject matters of all of the above applications is incorporated herein by reference.
The present invention relates to a data-centric communications system, a node, and, a data forwarding method.
The IP (Internet Protocol) network identifies a location of a node performing communications using an IP address that is an identifier indicating a location in a network. As a clue to identify the IP address, for example, a host ID (Host Name) extracted from URI (Uniform Resource Identifier) of desired data is defined.
DNS (Domain Name System) is a name resolution service for identifying the location ID indicated by the host ID using the host ID as a search key. Thus, a terminal device communicates with a destination node using the IP address notified by the DNS.
Data-centric network (DCN) is a network for performing routing of a data request for the desired object using a data ID (object ID).
Here, an object means any data that can be accessed via a network, including from a file of multimedia format such as video data, music data, to text data represented by a Web page, and further, data for Machine-to-Machine (M2M) communications such as sensor data and device-status monitoring data. A data ID (Object ID) means an identifier indicating the object.
Although the conventional IP network performs routing using the IP address that is the identifier indicating the location on the network as described above, the data-centric network performs routing using the data ID. Although the IP address changes each time the location of the object changes, the data ID does not change even though the location of the object changes.
The IP network performs routing after identifying the IP address from the URI or the host ID by using the name resolution services such as DNS. In contrast, the data-centric network performs routing to an appropriate object (or its replication) only by specifying the data ID. Therefore, the data-centric network can perform communications more efficiently than the IP network in the case in which the object moves or replications of the object are dispersed in the network.
NPL 1 below describes a method of accessing a service for mapping the object ID to the location ID (GNRS; Global Name Resolution Service).
NPL 2 below describes a method of converting the host ID to the location ID by the hierarchical DHT (Distributed Hash Table).
Another method is proposed, which performs communications by regarding the data ID itself as the location ID without name resolution. PTL 1 below describes network architecture of retrieving the desired object through a routing function of the network using the data ID without using the location ID.
There are many cases in which a terminal storing data or data itself moves. For example, some sensors and devices may be connected to a network via wireless access and send various information, which some other terminals that are connected to the network can retrieve and utilize. In addition, a host device accessed by terminal devices, such as a Web server, may be allowed to move to a remote location by an art such as server virtualization technology.
In this way, even if key information for name resolution, such as host ID or data ID, is left unchanged, a location ID obtained by an one-time name resolution at a certain point of time is able to be used only in a shorter time when the location ID that is a result of the name resolution is updated as the time elapses.
However, no method has been proposed, for performing efficient data communications under situations in which data locations continues to be updated with time.
In a method that provides name resolution services as proposed by NPL 1 and NPL 2, since data communications starts after name resolution is completed, the name resolution is needed to be performed as preparation prior to each data communication. Therefore, the data communications is delayed to start until the name resolution is completed under the situation in which the location ID keeps being updated.
In another method that regards a data ID itself as a location ID as described in PTL 1, it is sure that no preparation of name resolution is required and that the start time of the data communications is advanced, but, it is necessary for each node located on a route from the source to the destination to prepare a respective entry of a forwarding table that indicates the next hop for directing to the destination for each data ID. Therefore, the number of entries in the forwarding table becomes enormous, and search time and update time of the forwarding table become bottlenecks to cause to degradation of data communications performance.
Therefore, the primary purpose of the present invention is to solve the problems described above and to enable an efficient data communications under the situations in which the data locations continue to be updated with time.
In order to solve the above problems, the present invention provides a data-centric communications system comprising a plurality of nodes and a network, wherein
the plurality of nodes are coupled by the network;
a first one of the plurality of nodes receives a request message from a terminal to retrieve an object;
each node from the first node to a second one of the plurality of nodes performs routing of the request message using an object ID and routing information, the object ID is hierarchized and an object identifier, and the second node performs name resolution;
the second node converts the object ID of the request message to a location ID of a third one of the plurality of nodes by referring to name resolution information, and the third node retains the object;
each node from the second node to the third node performs routing of the request message using the location ID converted, and
the third node itself retrieves the object;
each node from the third node to the first node performs routing of a return message including the object retrieved, thereby the terminal retrieves from the first node the object that the terminal requests using the request message.
The other solutions are described below.
According to the present invention, data communications can be performed efficiently under a situation in which a location of data continues to be updated with time.
Hereinafter, detailed description is made of an embodiment of the present invention with reference to the drawings.
Here, oid is a separate ID space and separate data from the other id (for example, nid indicating a node ID, and lid indicating a location ID). Hierarchical representation of oid is described below.
In the claims, Node 1a is represented as a first node, Node 1f as a second node, and Node 1g as a third node.
Each device in the data-centric communications system is configured as a computer each including a CPU (Central Processing Unit), memory, a hard disk (storage unit), and a network interface, and the computer operates the respective processing units by the CPU's execution of a program read into the memory thereby.
The data-centric communications system comprises each node 1, a terminal 2a included in Node 1a, and a terminal 2b included in Node 1g, which are coupled by a network. Each terminal 2 (2a, 2b) instructs Node 1 to access an object 9. There lists the following three types of messages for instructing the access to the object 9:
Each node 1 is given the node ID (nid). Hereinafter, the end character of the reference sign of Node 1 is used for a node ID of the same node in the present embodiment (for example, the node ID of Node 1a is “a”, which is derived from “a” of the end character of the reference sign “Node 1a”).
Here, nid is a separate ID space and separate data from the other ids such as oid and lid.
Each node 1 is coupled with each other in a hierarchical topology having a Node 1d as a vertex. In
To reflect the hierarchical configuration of the nodes 1 into the data-centric communications system, forwarding tables described below with reference to
Node 1 handles an object request message from Terminal 2a in the order of Step 1 to 3 as follows:
Step 1: Each node 1 (1a→1b→1c→1d→1e→1f) forwards the object request message to a node 1 that is the next hop using an object ID specified as a destination in the object request message. Such a forwarding using the object ID is referred to as “oid forwarding”, and
Step 2: Node 1f performing name resolution converts the object ID (=a.b.c) to a location ID (hereinafter, abbreviated as “lid”) of Node 1g having the object (=d.e.f.g).
Here, lid is a separate ID space and separate data from the other id (for example, nid or oid).
lid includes an existing ID such as an IP address and a unique ID that is different from the IP address and specific to the data-centric network. An example of a hierarchical representation of the lid specific to the data-centric network is described below.
Then, Node 1f forwards the object request message to Node 1g that is the next hop, using the location ID (=d.e.f.g) that is the destination of the object request message. Such a forwarding using the location ID is referred to as “lid forwarding”, and
Each node 1 handles an object return message to Terminal 2a in the order of Step 4 to Step 6 as follows:
Step 4: Node 1g generates an object return message containing the object 9 that is specified in the object request message. The destination of the object return message is Terminal 2a of the source of the object request message. Then, Node 1g forwards the object return message to Node 1f that is the next hop by using the location ID of Terminal 2a that is the destination of the object return message.
Step 5: Each node 1 (1f→1e→1c→1b→1a) forwards the object return message to the node 1 that is the next hop using the location ID of Terminal 2a that is the destination of the object return message received. At the same time, along with the forwarding process of the object return message, each node 1 stores a forwarding destination of the object ID (=a.b.c) in the object request message (for example, Node 1b is a forwarding destination as viewed from Node 1a) into an forwarding table thereof.
Step 6: The terminal 2a retrieves the object 9 specified by the object request message issued in Step 1 by receiving the object return message from Node 1a.
The configuration of the message header 601 is as follows.
“message_type” on the line 1 contains a message type, which includes any one of “retrieve” indicating an object request message, “return” indicating an object return message, and “register” indicating an object registration message.
The lines 2 and 3 beginning with “req” indicate a request party (destination) of a message. “req_oid” indicates the object ID of the destination, and “req_lid” indicates the location ID of the destination.
Here, “null (no value)” in the “req_lid” indicates a state before the name resolution is completed by Node 1f, therefore oid forwarding using “req_oid” as a search key is performed by each node 1. On the other hand, a case in which a value is substituted into “req_lid” indicates a state after the name resolution is completed, lid forwarding using “req_lid” as a search key is performed by each node 1.
The lines 4 and 5 beginning with “src” indicate sources of a message.
“route_info_nid” in the line 6 indicates the order of the nodes 1 thorough which a message itself has passed. In
Node 1 or terminal 2 that generates a message fills the lines 1, 2, 4, and 5 of the message header 601. Node 1f that performs name resolution fills line 3 of the message header 601. Each node 1 fills line 6 of the message header 601 with a node ID thereof.
Here is explained a hierarchical representation of the oid and the lid. In oid (for example, =a.b.c) and lid (for example, =d.e.f.g), a plurality of elements (for example, a, b, c in oid) are connected using “.” for a delimiter sequentially from the head. In such a hierarchical representation using “.” for a delimiter, the more front (the more left) indicates the higher layer, and the more tail (the more right) indicates the lower layer. The match determining process of entries in the hierarchical representation results in any one of the followings.
A case of mismatch: the search key “a.b.c” and the search key “d.e.f” do not match at the topmost characters “a” and “d”. Therefore, since there is no matching portion between the search key and the search object, the match determining process results in “mismatch (no hit)”.
A case of partial match: the search key “a.b.c” has a matching portion “a.b” with the search object “a.b” from the beginning, but, at the tail portion “c” does not match. Thus, the case in which a portion extracted from the beginning of the search key “a.b.c” (“a.b”) matches the search object “a.b” is represented as “partial match (hit)”. Additionally, a portion extracted from the beginning of the hierarchical representation of the “a.b.c” (“a.b”) is referred to as “prefix”.
A case of exact match: the search key “a.b.c” matches the search object “a.b.c” from the top to the tail. Such a case is referred to as “exact match (hit).”
Note that when a first search object “a”, a second search object “a.b”, and a third search object “a.b.c” exist in the same forwarding table for the search key “a.b.c”, the object matching the search key “a.b.c” at the most point is regarded as hit on a priority basis (so-called “longest match rule”). In this example, the search results of the search key “a.b.c” are the exact match of the third search object on the highest priority, a partial match of the second search object on the second priority, a partial match of the first search object on the lowest priority.
The control data storing unit 10 includes an object-ID forwarding table 11, a name-resolution table 12, and a location-ID forwarding table 13, and a stored-data table 14. Each of the above tables is detailed below with reference to
The data forwarding unit 20 includes a data sender-receiver 21. The data sender-receiver 21 controls send and receive of each message.
The data storing unit 30 includes a data storage 31. The data storage 31 contains the object 9. For example, in
The communications IF 40 is an interface for interconnecting each component of Node 1 and the network 50 for connecting to the other device.
The control processing unit 60 includes a node management unit 61, an object-ID forwarding table generation unit 62, an object-ID forwarding table search unit 63, a location-ID forwarding table generation unit 64, a location-ID forwarding table search unit 65, a name-resolution table generation unit 66, a name-resolution table search unit 67, and a stored-data table search unit 68.
The object-ID forwarding table generation unit 62 and the object-ID forwarding table search unit 63 perform generation and search of the object-ID forwarding table 11.
The location-ID forwarding table generation unit 64 and the location-ID forwarding table search unit 65 perform generation and search of the location-ID forwarding table 13.
The name-resolution table generation unit 66 and the name-resolution table search unit 67 perform generation and search of the name-resolution table 12.
The stored-data table search unit 68 identifies a store destination of the object 9 in the data storage 31 by searching the stored-data table 14.
In S101, the node management unit 61 of Terminal 2a determines to request an object “oid=a.b.c”. This determination is caused by a user operation, a timer of the terminal, a trigger due to an external factor, or the like.
In S102, the node management unit 61 of Terminal 2a sends an object request message (for name resolution) to Node 1a via the data sender-receiver 21 thereof. Node 1a receives the object request message via the data sender-receiver 21 thereof.
In S103, the object-ID forwarding table search unit 63 of Node 1a sets the object ID in the object request message received as a search key to search the object-ID forwarding table 11. As the result of the search, if the object ID does not hit anything, the next higher level node that is set as a “default” is specified as the next hop (in this case, Node 1b).
In S104, Node 1a sends the object request message (for name resolution) to Node 1b. In S105 to 109 as well, each node 1 also repeats the process of searching the object-ID forwarding table 11 and forwarding the object request message to the higher level node.
In S111, as the result of the search in S109, the prefix of the object ID (“a” at the top of “a.b.c”) hits (partial match), thus the object-ID forwarding table search unit 63 of Node 1d obtains the ID of the next hop (nid=e). And Node 1d sends the object request message (for name resolution) to Node 1e.
In S112 and S113, similarly to S111, the prefix “a” partially matches. As the result of the search, Node 1e obtains the ID of the next hop (nid=f) and forwards the object request message to Node 1f.
In S114, the object-ID forwarding table search unit 63 of Node 1f searches the object-ID forwarding table 11, and as the result, finds that the object ID hits in the exact match. Such node as Node 1f in which the object ID hits in the exact match is responsible for name resolution.
In S115, the name-resolution table search unit 67 of Node 1f sets the object ID as a search key to search the name-resolution table 12 and obtains the location ID (lid=d.e.f.g) as the search result.
In S116, the location-ID forwarding table search unit 65 of Node 1f sets the location ID obtained in S115 (lid=d.e.f.g) as a search key to search the location-ID forwarding table 13 and obtains an ID of the next hop (nid=g).
In S117, Node 1f sends the object request message (for object retrieve) generated from the object request message (for name resolution) to Node 1g that is the next hop obtained at S116.
This means that Terminal 2a does not need to send two messages for name resolution and for object retrieve, and that the nodes 1 of the data-centric communications system converts the message for name resolution to the message for object retrieve. This results in shortening the preparation period to wait for the response to the message for name resolution.
In S118, the stored-data table search unit 68 of Node 1g sets as a search key “oid=a.b.c” in the object request message received to search the stored-data table 14, and obtains the stored data ID (in
Then, the data sender-receiver 21 stores the read objects 9 into the payload 602 and replaces the IDs of the source (lines beginning with “src”) and the destination (lines beginning with “req”) of the message header 601 with each other, in order to generate an object return message.
In S181, the object-ID forwarding table search unit 63 searches the object-ID forwarding table 11 for the object ID that is set as a search key.
In S182, the object-ID forwarding table search unit 63 proceeds to S183 if there is a prefix hit by the search of S181 (nid=d, e, f, in
In S183, the object-ID forwarding table search unit 63 proceeds to S184 if the hit in the search of S181 is the exact match (nid=f in
In S184, the name-resolution table search unit 67 searches the name-resolution table 12 for the object ID that is set as a search key to obtain the location ID for the object ID.
In S185, the location-ID forwarding table search unit 65 searches the location-ID forwarding table 13 for the location ID obtained in S184 that is set as a search key and obtains the ID of the next hop.
In S186, the data sender-receiver unit 21 sends the object request message to the next hop ID obtained in S185 as an address.
In S187, the data sender-receiver unit 21 sends the object request message to the upper level node that has been described as “default” in the object-ID forwarding table 11.
In S188, the data sender-receiver unit 21 sends the object request message to the next hop corresponding to the entry hit in partial match.
The object-ID forwarding table 11 has oid711 that is a search object column of the search key (e.g., 711a), and nexthop_nid712 that indicates the next hop that is the search result (e.g., 712a) recorded in association with each other.
Now, description is made of the difference of the present embodiment from the communications disclosed by PTL 1 that regards a data ID itself as a location ID. It may be common between the ID forwarding table 11 of the present embodiment and a forwarding table of the PTL 1 that the search key is the data ID itself (i.e., object ID).
However, the meaning of the next hop indicated by nexthop_nid712 of the present embodiment differs from that of the next hop of PTL 1. The result of searching the object-ID forwarding table 11 of the present embodiment is a next hop directing toward the node 1 performing name resolution of the object ID; but the result of searching the forwarding table of PTL 1 is a next hop directing toward a node storing the object ID that is the search key.
Therefore, under a situation in which the location of the object 9 is frequently changed, since PTL 1 may need to keep updating the latest location of each of many objects frequently in forwarding tables thereof, a storage capacity for the forwarding table and the processing load may increase. In contrast, even under the above situation, in the object-ID forwarding table 11 of the present embodiment, the location of the node 1 performing name resolution is rarely changed, therefore, the storage capacity for the forwarding table and the processing load can be reduced.
The name-resolution table 12 records oid721 that is a column to be searched for the search key and lid722 indicating a result of the name resolution that is a result of the search, in association with each other.
The location-ID forwarding table 13 records lid 731 that is a column to be searched for the search key and nexthop_nid732 indicating the next hop that is the search result, in association with each other.
The stored-data table 14 records oid741 that is a column to be searched for the search key and store_id 742 indicating the record location in the data storing unit 30, in association with each other.
Note that “default” is an entry that indicates a predetermined (default) forwarding destination for the case when the search key does not hit any target of the search and corresponds to the upper one of the nodes 1 described regarding
Here, the solid arrow in
In S103, “default” is referenced in the object-ID forwarding table 11 of Node 1a.
In S107, “default” is referenced in the object-ID forwarding table 11 of Node 1c.
In S109, “a” is referenced in the object-ID forwarding table 11 of Node 1a.
In S115, “a.b.c” is referenced in the name-resolution table 11 of Node 1f.
In S116, “d.e.f.g” is referenced in the location-ID forwarding table 13 of Node 1f.
In S118, “a.b.c” is referenced in the stored-data table 14 of Node 1g.
It should be appreciated that each forwarding table generation unit (the object-ID forwarding table generation unit 62, and the location-ID forwarding table generation unit 64) may consolidate a plurality of entries into a single entry for an entry in each forwarding tables to be generated, in order to reduce the number of entries. The plurality of entries that may be consolidated are, for example, those satisfying both the following two conditions.
Condition 1: the plurality of entries that have the same prefix.
Condition 2: the plurality of entries that have the same next hop.
In S201, Node 1g sends the object return message (generated in S118) to Node 1f.
In S202, the object-ID forwarding table generation unit 62 of Node 1f updates the object-ID forwarding table 11 thereof.
The content of oid711 in the updated entry is the object ID in the object return message (oid of the object 9 contained in the payload 602).
The content of nexthop_nid712 of the updated entry is the ID of the receiving node of the object request message that is a node 1 adjacent as the next hop (i.e., nid=g).
When oid711 equal to the update content already exists in the object-ID forwarding table 11, only nexthop_nid712 of the entry is updated by override; and when the oid711 does not exist, a new entry for the update content is generated and added to the object-ID forwarding table 11.
Thereby, when the same object 9 is requested again, the entry for the object is present in the object-ID forwarding table 11 and a route that allows proper forwarding of the object request message is established.
In S203, the location-ID forwarding table search unit 65 of Node 1f sets the location ID of the object return message as a search key to search the location-ID forwarding table 13, and obtains the ID of the next hop (nid=e) as the search result.
In S204, Node 1f sends the object return message to Node 1e that is the next hop of which the ID is obtained in S203.
In S205 to S209, and S211 to S220 in
In S221, Terminal 2a retrieves the object 9 from Node 1a.
Note that the content for the nexthop_nid712 of the updated entry described in S202 may be a Node 1 on a shortcut route instead of the receiving node.
The shortcut route is a route that can reduce the number of hops among the candidate routes toward the same destination. For example, in
The following explains how to obtain a Node 1 on the shortcut route.
In S212, the object-ID forwarding table generation unit 62 of Node 1c reads “route_info_nid” on the sixth line of the message header 601. The “route_info_nid” indicates an order list of nodes 1 that have been passed through <a, b, c, d, e, and f> (refer to
When Node 1c finds a node that locates beyond the receiving node and that is adjacent thereto, i.e. “nid=e” (directly connected to Node 1c in
In S281, as described in S202, the object-ID forwarding table generation unit 62 updates the object-ID forwarding table 11 thereof on the basis of the entries of the object ID of the object return message.
In S282, the location-ID forwarding table search unit 65 sets the location ID of the object return message as a search key to search the location-ID forwarding table 13 and obtains the ID of the next hop.
In S283, the object return message is sent to the ID of the next hop obtained in S282 as an address.
As described in S202, the entry of which oid711 is set as “a.b.c” is newly added into each of the object-ID forwarding table 11 (in
In addition, the entry of which oid711 is set as “a.b” is also added in the object-ID forwarding table 11 of Node 1c, but this entry is for adopting Node 1 on the shortcut route and associated with “a.b” that is the prefix of the object ID “a.b.c.”
The object registration message is forwarded up to Node 1f that performs name resolution, while storing oid “a.b.d” of the registered object into the object-ID forwarding table 11 of each node 1 passed through. Then, Node 1f stores in the name-resolution table 12 thereof the location ID “d.e.f.a” of Node 1a in which the object ID and the object are registered.
In S301, the node management unit 61 of Terminal 2a determines to register an object “oid=a.b.d”. This determination is caused, for example, by a user operation, a timer of the terminal, an occurrence of a trigger due to an external factor, or the like.
In S302, the node management unit 61 of Terminal 2a sends the object registration message (for name resolution) to Node 1a via the data sender-receiver 21. Node 1a receives the object registration message via the data sender-receiver unit 21. When Node 1a recognizes that the registration destination is Node 1a itself, Node 1a reads and stores into the data storage 31 the object 9 from the payload 602 of the object registration message, and registers the storage location thereof in the stored-data table 14.
In S303, the object-ID forwarding table search unit 63 of Node 1a sets as a search key the object ID of the object registration message received in S302 to search the object-ID forwarding table 11. As the result of the search, since the object ID is not hit, the next hop is set as Node 1b that is an upper node.
In S304, Node 1a sends the object registration message to Node 1b that is identified as the next hop in S303.
In S305, the object-ID forwarding table generation unit 62 of Node 1b updates the object-ID forwarding table 11, in the same manner as S202.
In S307 to S312, and S321 and S322 in
In S323, the object-ID forwarding table search unit 63 of Node 1f sets “oid=a.b.d” as a search key to search the object-ID forwarding table 11, in the same manner as S303. The result of the search is regarded as the exact match because the object-ID forwarding table 11 of Node 1f includes an entry with oid721f=“a.b.c” having the same prefix “a.b” (see
In S324, the name-resolution table generation unit 66 of Node 1f sets lid 731f=“d.e.f.a” that is the location ID of Node 1a in the name-resolution table 12, generates a new entry in which nexthop_nid732f=Node 1e, and reflects the new entry into the name-resolution table 12. Here, the reflection means to rewrite only nexthop_nid732f if an entry with lid 731f=“d.e.f.a” already exists; and to add a new entry in the name-resolution table 12 if the entry does not exist.
In S381, the object-ID forwarding table generation unit 62 updates the object-ID forwarding table 11 in the same manner as S202 (S305).
In S382, the object-ID forwarding table search unit 63 sets the object ID of the object registration message as a search key to search the object-ID forwarding table 11 and obtains the next hop as the result of the search.
In S383, the data sender-receiver unit 21 sends the object registration message to the ID of the next hop obtained at S382 as an address.
First, oid711a=“a.b.d” is referenced in the object-ID forwarding table 11 of Node 1a (the object-ID forwarding table 11 of Node 1b is not shown). Next, oid711c=“a.b.d” is referenced in the object-ID forwarding table 11 of Node 1c. Then, oid711f=“a.b.d” is referenced in the object-ID forwarding table 11 of Node 1f. Node 1f finds that Node 1f itself is a node 1 responsible for name resolution because the nexthop_nid712f is “local”.
The name-resolution table search unit 67 of Node 1f obtains the lid 722f=“d.e.f.a” from oid721f=“a.b.d” in the name-resolution table 12. In addition, the location-ID forwarding table search unit 65 of Node 1f obtains nexthop_nid732f=“e” from lid 731f=“d.e.f.a”.
Then, after the lid forwarding with lid=“d.e.f.a”, store_id 742a=300 is identified from oid741a=“a.b.d” in the stored-data table 14 of Node 1a, and the object 9 is read from the address 300 in the data storage 31 of Node 1a.
The present embodiment described above forwards the object request message up to Node 1f performing name resolution by oid forwarding using the object ID as shown by the solid arrow in
Furthermore, the present embodiment enables the terminal 2, if sending the object request message only once (refer to the description of S117), can achieve both name resolution and forwarding to the destination of the object request message for which the name resolution is completed. In other words, the terminal 2 can obtain a desired object from an object return message only by specifying a data ID in the object request message for the moving object, without explicitly requesting translation from a host ID to a location ID (name resolution).
It should be appreciated that Node 1 responsible for name resolution (Node 1f in
Further, as shown in
Contrastingly, in the method according to NPL 1 and NPL 2, since it is necessary for a client (terminal) to receive a response of name resolution, the terminal needs to take a burden to implement a function for requesting a name resolution. At the same time, a server (service provider such as DNS) also needs to take a cost for managing and maintaining the service.
In addition, since data communications starts after the name resolution, latency (delay) for data communications occurs during a preparation period of name resolution, and network efficiency also deteriorates due to traffic of control packets for performing name resolution. In particular, in the method of NPL 2, since a request to convert a host ID to a location ID wanders around the DHT every communications, excessive traffics and delay occur.
Furthermore, in the present embodiment, when each node 1 forwards an object return message or an object registration message, in conjunction with the forwarding process, a process for registering the object ID in the forwarding table of each node 1 (refer to, for example, S202 and S305). Thereby, even for an object 9 whose location is frequently changed, the latest location information can be reflected in the forwarding table immediately.
In contrast, in a conventional system caching a translation result of name resolution into nodes on the way to the DNS server in order to reduce the load on the DNS server, since it often occurs that the cache data may not surely reflect the latest location information, it becomes difficult to identify the actual location of the object 9 of which the location is frequently changed.
That is, if the host of the communications partner is physically moved, the translation result of the name resolution is changed since the IP address is changed although the host name is unchanged. Therefore, the old cached translation result becomes different from the new translation result after the movement of the host.
In the present embodiment described above, even if a location of an object 9 is changed, when the node in which the latest location information is registered in the same node 1 as before, the sending address of the object request message is not changed and kept to be the same node 1. Therefore, it is not necessary to change the route for an oid forwarding of the object request message (entries of the object-ID forwarding table 11).
On the other hand, when the location of the object 9 is changed and the latest location information is registered in a node 1 other than the node 1 before the change, the route for the oid forwarding of the object request message needs to be changed to direct toward the latest node 1 registering the latest location information.
Therefore, the following defines a new message referred to as “route modification message” (details are explained in
Further, in
“First node” of claims is Node 1g including Terminal 2d.
“Second node” of claims is a name resolution node (Node 1b or Node 1f).
“Third node” of claims is a data storing node (Node 1a or Node 1g).
In order to implement the moving process from the object 9a to the object 9b, it is essentially necessary to delete the object 9a after storing the object 9b. However, the following description explains a case in which a problem occurs under a situation in which the object 9a exists even after storing the object 9b, and a solution to the case.
In nodes 1 on the way through which the object registration message is relayed (Node 1g→Node 1f→Node 1e→Node 1c), each of the object-ID forwarding tables 11 of the nodes 1 is updated (for the specific update process, refer to S305 in
In the following description, the content of nexthop_nid712 of the object-ID forwarding table 11 is referred to as “next_oid” in a box of the node; and the content of nexthop_nid731 of the location-ID forwarding table 13, “next_lid”.
In this case, Node 1f and 1g which the object registration messages pass through, can update the contents of the object-ID forwarding table 11 thereof such that the new name resolution node is Node 1f (for the specific update process, refer to S305 in
The left side of
The cause that makes Terminal 2a retrieve the old object 9a is that the influence of the old object registration message shown in
The right side of
In S401, Terminal 2c determines to request the object “oid=a.b.c” in the same manner as S101.
In S402, Terminal 2c sends the object request message (for name resolution) to Node 1i that is the next hop adjacent, in the same manner as S102.
Node 1i located on the route of the object request message (for name resolution) performs the following steps.
Step 1: receiving the object request message (for name resolution) from the preceding device in the same manner as S102 (S402).
Step 2: searching the object-ID forwarding table 11 thereof to determine the forwarding destination of the object request message in the same manner as S103 (S403).
Step 3: sending the object request message to a succeeding device that is determined as a forwarding destination in the same manner as S104 (S404)
Node 1f that is a name resolution node of the object request message (for name resolution) performs the following steps.
Step 1: receiving the object request message (for name resolution) from the preceding device in the same manner as S113 (S404).
Step 2: searching the object-ID forwarding table 11 thereof to determine that the name resolution node of the object request message is Node 1f itself in the same manner as S114 (S405).
Step 3: searching the name-resolution table 12 to obtain the location ID of the object 9 in the same manner as S115 (S406).
Step 4: searching the location-ID forwarding table 13 to obtain the next hop in the lid forwarding of the object request message in the same manner as S116 (S407).
Step 5: sending the object request message (for object retrieve) generated from the object request message (for name resolution) to the next hop obtained from the location-ID forwarding table 13 (a succeeding device) in the same manner as S117 (S408).
Node 1g storing therein the object 9 that the object request message requests performs the following steps.
Step 1: receiving the object request message (for object retrieve) from the preceding device in the same manner as S117 (S408).
Step 2: searching the stored-data table 14 thereof to obtain the stored data ID, and to read the requested object 9 from the data storage 31 in the same manner as S118 (S409), then generating an object return message based on the object 9 read.
In S421, Node 1g sends the object return message generated in S118 to Node 1f that is the adjacent next hop in the same manner as S201.
Each of the nodes 1 located on the route of the object return message performs the following steps.
Step 1: receiving the object return message from the preceding device in the same manner as S201, (S421 if Node 1f, S424 if Node 1i).
Step 2: updating the object-ID forwarding table 11 thereof, in the same manner as S202 (S422 and S425).
Step 3: searching the location-ID forwarding table 13 thereof to obtain the next hop as the search result in the same manner as S203 (S423, S426).
Step 4: sending the object return message to the next hop obtained in Step 3 (succeeding device) in the same manner as S204 (S424, S427).
The terminal 2c that is the destination of the object return message (the source of the object request message) performs the following steps.
Step 1: receiving the object return message from the preceding device in the same manner as S220 (S427).
Step 2: obtaining the object 9 in the object return message received in the same manner as in S221. This object 9 is the object 9b at the new location (S428).
Terminal 2c in FIG. 22→terminal 2b in
Node 1i in FIG. 22→Node 1h in
Node 1f in FIG. 22→Node 1b in
Node 1g in FIG. 22→Node 1a in
In addition, a step code generated by adding 40 to the number of the step code in
Here, in S468 corresponding to S428, Terminal 2b retrieves the object 9a in the old location (described in
As described in
Node 1f that is the name resolution node determines that modification of the old routing information is necessary, if a rewrite to an existing entry occurs in place of a new registration in the update of the name-resolution table 12 thereof that is a process corresponding to S324. The old routing information is the content of the entry in the object-ID forwarding tables 11 of Node 1e, 1c, and 1b that the new object registration message of
Here, the destination of the route modification message is set as a lid of Node 1a that stores the objects 9a, and a lid forwarding referring to the location-ID forwarding table 13 is used.
In S501, as shown in the description of
Then, Node 1f searches the location-ID forwarding table 13 and finds Node 1e as the next hop corresponding to lid of the route modification message, and sends the route modification message to Node 1e (S502). Note that the route modification message is represented as “object registration (route modification)” in the flowchart of
Now, description is made of the procedure of each node 1 (Node 1e→Node 1c→Node 1b) for forwarding the route modification message.
Step 1: the node 1 receives the route modification message from the preceding device (S502 if Node 1e, S505 if Node 1c, and S508 if Node 1b).
Step 2: the object-ID forwarding table generation unit 62 of the node 1 sets oid in the route modification message as a search key to search the object-ID forwarding table 11 thereof and modifies the entry obtained as the search result to update the object-ID forwarding table 11 (S503, S506, and S509).
Here, the modification of the entry may be deletion of a record of the entry, or change of the node 1 that is the next hop in the entry from the next hop directing toward the name resolution node for the object 9a (Node 1b) to the next hop directing toward the name resolution node for the object 9b (Node 1f). In the example of
Step 3: the location-ID forwarding table search unit 65 of the node 1 sets lid in the route modification message as a search key to search the location-ID forwarding table 13 and obtains the ID of the node 1 to be the next hop as the search result (S504, S507, and S510).
Step 4: node 1 sends the route modification message to the node 1 of the next hop that is a subsequent device obtained in Step 3 (S505, S508, and S511).
Then the route modification message is sent to Node 1a storing the object 9a, Node 1a sends a reply to the route modification message (ACK) to Node 1f that is the sender of the route modification message (S520).
When Node 1f determines that the route modification message is not needed to be sent (S501, No), or when Node 1f receives an ACK for the route modification message (S520), Node 1f returns ACK for the object registration message from which the route modification message derives to the terminal 2 that is the sending source of the object registration message (S530).
Note that since this flowchart is an extension of the steps in Node 1f previously described in
Node 1f, upon receipt of the object registration (name resolution) (S321), updates the object-ID forwarding table 11 (S322) and search the object-ID forwarding table 11 (S323).
Here, Node 1f performs a locking process so that a plurality of route modification messages that Node 1f itself manages are not concurrently generated. This locking process delays an issue of another route modification message until the ACK for the issued route modification message is received since issuing the route modification message.
Therefore, when it is currently locked (Yes at S331), it is after a previous route modification message is already issued, therefore Node 1f can advance the process to S324 after releasing the lock by the previous route modification message (S345). In S324, Node 1f updates the name-resolution table 12.
It should be understood that since the releasing of the lock by the previous route modification message (S345) and the waiting by the current route modification message for releasing of the lock (Yes at S331) are being executed in parallel by different processes respectively, it is unlikely that the waiting for releasing of the lock continues forever (deadlock).
In S332, Node 1f determines whether or not it is necessary to modify the old routing information (the same as S501). When the modification is unnecessary (No at S332), Node 1f returns an ACK for the object registration message to the terminal 2 (S530 in
Node 1f waits for a predetermined period of time starting with, for example, the sending time of the message at S341 and determines whether or not Node 1f receives an ACK for the current route modification message.
When receiving the ACK for the current route modification message (Yes at S342), Node 1f returns an ACK notifying the successful registration as a response to the object registration message of S530 (S343).
If Node 1f cannot receive the ACK for the current route modification message (No at S342), Node 1f returns an ACK notifying the registration failure as a response to the object registration message of S530 (S344).
Then, Node 1f releases the lock applied (S333) for the succeeding route modification message (S345).
For example, next_oid of Node 1b is modified to Node 1c that is the next hop directing toward Node 1f. Therefore, as compared with
In other words, even if any terminal 2 (terminal 2a to 2d) issues an object request message, the object-ID forwarding table 11 of each node 1 is modified so that the message reaches Node 1f.
On the other hand, there exists a case in which the same Node 1f has not both of old and new entries.
Accordingly, in order for Node 1b and Node 1f that are the name resolution nodes to exchange the entries thereof with each other, Node 1b notifies to Node 1f that the object 9a is registered in Node 1b in S601 (notification of the old location) (S602).
Since the notification message issued at S602 enables Node 1f to recognize the registration content in Node 1b and to detect the necessity of rewriting the existing entries. Specifically, the name-resolution table search unit 67 of Node 1f matches the entry in the name-resolution table 12 thereof with the entry of name-resolution table 12 notified by Node 1b, and detect the necessity of rewriting the existing entries when there exist entries having the same oid in the name-resolution tables 12 of both nodes.
Then, in place of the sending process in
Node 1b receiving the notification sends a route modification message originated thereby using oid forwarding in the direction reverse to that of the object registration message at S601 (S605). Thus, the old entries registered in the nodes 1 on the route of the object registration message at S601 are modified to the new entries based on the route modification message at S605 (overwriting).
Thereby, since it is possible for the object registration message at S601 and the route modification message at S605b to pass through the same route from the source to the destination, the old entry is modified to the new entry along the route.
It should be appreciated that the present invention is not limited to the embodiments described above, and that the present invention can include various modifications. For example, the embodiments described above are detailed for easy understanding but the present invention is not necessarily limited to include all the structures described.
Further, some structures of one of the embodiment can be replaced by structures of another embodiment, and a structure of an embodiment can be added to structures of another embodiment.
Furthermore, some of the structures of each embodiment can be deleted, or additions of or substitutions with other structures can be applied thereto. In addition, a part or whole of the above structures, functions, processing units, and processing means may be implemented by hardware, for example, an integrated circuit design.
Further, each of the above structures and functions may be implemented by software by a processor's interpreting and executing of programs performing respective functions.
Information including programs implementing respective functions, tables, and files may be stored in recording devices such as memory, hard disk, or SSD (Solid State Drive), or stored on a recording medium such as IC (Integrated Circuit) card, SD card, or DVD.
Further, for control connection lines or information connection lines, only what is considered necessary for explanation is illustrated, and it should not be understood that all the control connection lines or information connection lines on a product are illustrated. It may be considered all structures are connected to each other in actual practice.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2012-000590 | Jan 2012 | JP | national |
| 2012-160104 | Jul 2012 | JP | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/JP2012/076697 | 10/16/2012 | WO | 00 |
