Patent Application
20060007942
1. Field of the Invention
The present invention generally relates to methods for finding a resource and a service in network and relay node apparatuses, and more particularly to a method for finding a resource and a service in network and a relay node apparatus, in which a plurality of nodes provides resources and services maintained thereby.
2. Description of the Related Art
Conventionally, the Internet is a network mainly for personal computers (PCs) and workstations. Recently, accompanying with an evolution of minimized information terminals including a mobile phone and wide use of state-of-the-art IC chips, a communication called a ubiquitous communication that can communicate to any terminal anywhere and anytime, regardless of a type of a terminal is attracting attention as a communication form for the next generation.
In a network in which various nodes are mutually connected, since the number of resources and services and an amount of resources and services provided by various nodes becomes greater, a mechanism to effectively find a resource and a service becomes important. In a scope of this specification and claims, a resource means the resource included in hardware or a memory of any node, and a service means an intangible material provided by combining resources so as to bring a benefit to a user.
In the ubiquitous communication, requirements needed to find a resource or a service maintained by each node will be shown as follows:
A first requirement is to find a resource and a service maintained by any node. Conventionally, a client/server model, which defines a clear distinction between one node providing the resource and the service and another node receiving the resource and the service form the one node, is mainly applied. Accordingly, a technology for searching for a server as a search subject to receive the service and the resource has been widely used. For example, a conventional search engine for searching for homepages targets a Web server to implement. However, in the ubiquitous network, it is not easy to simply define a clear distinction between nodes such as in the client/server model. Thus, it is required to find the resource and the service provided by any node.
A second requirement is to have scalability with respect to the number of nodes. In the ubiquitous network, a node connected to a network is not limited to a PC (Personal Computer) but can be a node having an IC chip. Thus, a technology having scalability with respect to the number of nodes is required.
A third requirement has a lower load with respect to the network in a process for finding the resource or the service through the network. It is difficult to provide a bandwidth of the network proportional to the enormous number of nodes in a ubiquitous communication. Thus, it is required to suppress the load to the network in the process for finding the resource or the service through the network.
A fourth requirement is to have a fault-tolerance. In the ubiquitous communication, not only nodes securing sufficient reliability such as a conventional server provides the resource and the service. Thus, it is required to be a technology based on the premise that there is a node which cannot provide the resource and the service stably for a long time (for many days) since a connection to the network and an OS of the node are not stable.
A fifth requirement is to support a plurality of nodes providing the same resource or the same service. In the ubiquitous communication, the plurality of nodes may provide the same resource or the same service. Thus, it is required to select one node from a node group providing the same resource or the same service and provide a user a search result.
Existing search technologies for searching for resources and services are classified into as follows:
A centralization type is a search technology in that any node collects information concerning resources and services provided by any server and manages in a database beforehand, and the resources and the services are found. In general, a node called “search site” or “search engine” collects the information concerning the resources and the services. A search site searches for the database by using a keyword input by a user, provides information concerning nodes publishing the resources and the services related to the keyword. It should be noted that the centralization type is a type of a registration of a node providing the resource and the service, and can be classified into a robot type or a manual type.
The robot type is a search technology in that a server autonomously collects information concerning the resources and the services in the network by using a program called “robot”.
The manual type is a search technology in that the user or a server administrator for a search registers a location identification identifying a location of each of the resources and the service to a server managed by the server administrator and a keyword related thereto.
A distribution type is a search technology to inquire nodes in the network for each inquiry which node has the resource and the service. The distribution type does not require any database such as the centralization type. The distribution type is mostly used by a file sharing application such as Gnutella™, WinMix™, and a like. Since the resource and the service provided by any node can be searched from any node, the distribution type is called a peer-to-peer type (PtoP type).
A hybrid type is a search technology positioned between the centralization type and the distribution type, and periodically exchanges the resource and the service published by each node between nodes. In the distribution type, it is difficult to satisfy the first requirement previously described. Accordingly, the following discussion will focus on the distribution type and the hybrid type.
A procedure for finding the resource and the service in the distribution type has not been standardized. In practice, most applications of the distribution type are based on a procedure of Gnutella™. Thus, in the following, an operation example of Gnutella™ will be shown.
Gnutella™ is application software for exchanging files individually through the network. Thus, in Gnutella™, the resource and the service is handled as a file. PCs of users of Gnutella™ are mutually connected through the network, and each user opens a list of files to share with other users through the network. In a case of searching for a file on Gnutella™, files opened by nodes other than its own node and meeting a condition are extracted, and then the own node searching for the file can download the file as the resource directly from a node having the file as the resource.
The procedure for finding the resource and the service in the distribution type will be described with reference to
In
In the above (2), in order to prevent from relaying the query infinitely, since Gnutella™ includes a concept of TTL (Time To Live) as well as IP (Internet Protocol), the query is discarded after the query is transferred to a next neighbor node more than or equal to a predetermined number of nodes.
It is realized to find the resource or the service in Gnutella™ by broadcasting the query by a bucket brigade. Thus, the following problems are raised.
Problem 1: the number of nodes to search is enormous. The number of nodes searching for the resource or the service is increased in geometrical progression. This problem is caused because information concerning the resource or the service provided by nodes is not exchanged to each other among the nodes. As a result, in a case in that a node receiving the query does not have the resource or the service as a search subject, since the node does not have information showing to which neighbor node the query is transferred, it is needed to broadcast all over the neighbor nodes in the network. Accordingly, the second requirement is not satisfied.
Problem 2: a bandwidth of the network is used unnecessarily. The query is broadcast to neighbor nodes and then the number of nodes to broadcast the query is increased in geometrical progression for each path to the neighbor nodes. However, the node originally sending the query sends the request for obtaining the file (obtain command) to one node at most, and other queries (for example, queries toward bottom three nodes of four nodes at a right side in
Problem 3: a mechanism of the fault tolerance is not implemented. Thus, the fourth requirement is not satisfied.
The hybrid type has a feature of periodically exchanging information concerning the resource and the service provided by each of the nodes. Since there is no standard in an actual state, an operation example of the hybrid type will be shown by Flapps (Forwarding Layer for Application-level Peer-to-Peer Services) offered by UCLA (University of California, Los Angeles) in U.S.A.
The hybrid type exchanges “name” (file name, URL (Uniform Resource Locator), and a like) of the resource and the service opened by the node and path information toward the node among nodes. Based on a result of a path exchange, each of the nodes transmits the resource or the service requested by a query to a node sending the query.
Two phases are included in finding the resource and the service in the hybrid type. A first phase is a phase of distributing identification of the resource or the service (hereinafter, called name path information). A second phase is a phase of finding the resource and the service based on a request sent from a node.
In
As described above, each name of the resources opened by the node B and the node C and the path information are exchanged among the relay nodes 1 through 6.
Next, a sequence flow of a find phase of the service is shown in
In
Japanese Laid-open Patent Application No. 10-70552 discloses that a node sends a reply packet showing a correspondence between its own closed address and its own extended address with respect to a node which generated an information packet, and the node which generated an information packet includes contents of the replay packet received from the node which sent the relay packet, into its own routing table. Thus, a routing table for routing by the extended address can be generated.
Moreover, Japanese Laid-open Patent Application No. 2001-203739 discloses a path search frame is generated by using an address of the unknown destination and an own address of a relay apparatus when a receive frame shows an unknown destination, and the received frame is sent toward a sender sending a response frame when the response frame being replied from the relay apparatus which finds a destination in response to the path search frame is received.
The hybrid type conducts the find procedure for finding the resource and the service being distributed by exchanging information (name path information) concerning the resource and the service maintained in each node. Thus, when a state of providing the resource or the service by the node is changed (for example, when it becomes impossible to provide the resource or the service), the find procedure for finding the resource and the service cannot be provided stably in the network until the name path information for informing this change is transferred to a relay node group.
That is, a part of the relay group is not informed that the resource or the service is not provided and another part of the relay group is informed. As a result, an inconsistency of the name path information occurs, that is, the network becomes unstable, hereinafter, called “unstable state”. As described above, the unstable state may occur in the ubiquitous communication that does not ensure stability of the node.
In the network under the unstable state, the query frame might have been already distributed to a node that does not provide the resource or the service (hereinafter, called “closed node”), and the query frame may not be arrived to a node that provides the resource or the service. Hereinafter, a frame that is not distributed to the node providing the resource or the service is called “not-arrived frame”. There are problems to be solved as follows:
Problem 1 to be solved: as an objective to eliminate the not-arrived frame, the network is required to autonomously detect a path toward the closed node and to transfer the query frame being sent to the closed node toward another node.
Problem 2 to be solved: as another objective to suppressing the unstable state, it is needed to inform each of the relay nodes that a node becomes the closed node, without waiting a periodical name path exchange.
It is a general object of the present invention to provide methods for finding a resource and a service in network and relay node apparatuses, in which the above-mentioned problems are eliminated.
A more specific object of the present invention is to provide a method for finding a resource and a service in network and a relay node apparatus, in which an access request being sent to a closed node that stops providing a resource or a service can be transferred to another node providing the same resource or the same service, and information showing that one node becomes the closed node can be informed to each relay node.
The above objects of the present invention are achieved by a method for finding a resource and a service conducted in each of relay node relaying a frame, including: maintaining a search table to register more than one node providing a resource or a service; receiving an access request including an identification identifying the resource or the service, which the node stops providing; and switching from the node, which stops providing the resource or the service, to an available node providing the resource or the service identified by the identification, by searching for the search table by the identification, wherein resources and services are opened in public and managed by the plurality of nodes, the identification identifying each of the resources and the services and a network address of each of the nodes opening the resources or the services are exchanged among relay nodes relaying the identification and the network address, wherein each of the relay nodes structures a search table, searches for the search table by the identification indicated in the access request when the access request for obtaining a desired resource or a desired service using the identification is received from a request node, and accesses the available node providing the desired resource or the desired service.
According to the above invention, it is possible to transfer the access request being sent to the closed node that stops providing the resource or the service, to another node that is available to provide the same resource or the same service.
In the method, information showing that a node providing the resource or the service stops providing the resource or the service may be additionally included in the access request, each of the relay nodes may be informed by the access request that a node providing the resource or the service stops providing the resource or the service, so that each of the relay nodes changes the search table.
According to the above invention, it is possible to inform each of the relay nodes that the node stops providing the resource or the service, instead of waiting for a periodical exchange of the identification.
The above objects of the present invention are achieved by a relay node apparatus, including: a return check field updating part writing a return instruction for switching from a node to an available node providing a resource or a service in order to transfer an access request when a search result is not obtained by searching for a search table in response to the access request since the node stops providing the resource or the service; an address stacking part stacking an own address of the relay node apparatus itself when the access request that does not including a return instruction is transferred; and a stack address extracting part extracting a transfer originator from which a received access request including the return instruction is transferred, from the received access request stacking the transfer originator, wherein resources and services are opened in public and managed by the plurality of nodes, the identification identifying each of the resources and the services and a network address of each of the nodes opening the resources or the services are exchanged with other relay node apparatuses relaying the identification and the network address, wherein the relay nodes apparatus structures a search table, searches for the search table by the identification indicated in the access request when the access request for obtaining a desired resource or a desired service using the identification is received from a request node, and accesses the available node providing the desired resource or the desired service.
According to the above invention, it is possible to transfer the access request being sent to the closed node that stops providing the resource or the service, to another node providing the same resource or the same service.
The relay node apparatus may further include a return originator address updating part writing the own address as a return originator address when the access request including the return instruction.
The relay node apparatus may further include a table controlling part deleting the return address shown in the access request including the return instruction from the search table.
Other objects, features and advantages of the present invention will become more apparent from the following detailed description when read in conjunction with the accompanying drawings, in which:
An embodiment according to the present invention will be described with reference to the accompanying drawings.
Assumption 1: the node C becomes a closed node, which is a node that does not provide the resource or the service. As a result, “resource/music/rock.mp3” as a resource opened by the node C becomes closed to the public.
Assumption 2: in a state shown in
In implementation 1, in
Moreover, in implementation 2, by additionally providing control information of a name path change to the frame being returned (hereinafter, called return frame), each of the relay nodes 1 through 6 changes its own search table by the name path information concerning the closed node, prior to a periodical exchange of the name path information. Accordingly, each of the relay nodes 1 through 6 is informed that one node becomes the closed node. Thus, the problem 2 to be solved is overcome.
Requirements to realize the implementations 1 and 2 are shown as follows:
Requirement 1: each of the relay nodes 1 through 6 can identify the return frame (in order to realize the implementation 1).
Requirement 2: a path for the return frame can be informed to one of the relay nodes 1 through 6 which received the returned frame (in order to realize the implementation 2). For example, in
Requirement 3: any one of the relay nodes 1 through 6 can recognize which relay nodes 1 through 6 a query passed through until the one of the relay nodes 1 through 6 (in order to realize the implementation 1). When the frame (query) is returned, the frame traverses through the relay nodes 1 through 6 in a reversed order.
Requirement 4: a search can be conducted with respect to the return frame without a path toward the closed node (in order to realize the implementations 1 and 2). Because it is required to transfer the return frame to a relay node other than a relay node sending the return frame. For example, in
Moreover, in order to satisfy the requirement 3, as an area for recoding the IP address of each of path nodes through which the frame passed, a path node field is provided in the frame. The path node field includes a relay node number F3 showing the number of the relay nodes being stacked, and an address stack F4 for stacking IP addresses of the path nodes for the number of the relay nodes through which the frame passed.
In general, as shown in
Next, a process of each node will be described in detail.
A process conducted by each relay node relaying the query frame before returning the query frame will be described. (A1) Any relay node identifies “Query” from a command name of a received frame. (A2) The relay node decomposes a resource name by each delimiter (“/” in this case) that is defined beforehand, searches for a search tree in an order of keys obtained by this decomposition, and is a search result. (A3) The relay node increments the relay node number F3 shown in
A process conducted by each relay node returning the query frame will be described. (B1) Any relay node identifies “Query” from the command name of a received frame. (B2) The relay node decomposes the resource name by each delimiter (“/” in this case) that is defined beforehand, searches for the search tree in the order of keys obtained by this decomposition, and does not hit any key in the search tree. In this case, the search result shows “not hit”. This search result triggers a return process. (B3) The relay node writes its own IP address in the return originator IP address field F2. (B4) The relay node updates the return originator IP check field F1 of the query frame to be “1” showing “return”. (B5) The relay node decrements the relay node number F3 by “1”. (B6) The relay node sets an IP address being stacked in the stack row corresponding to the relay node number F3 in the address stack F4 to be the destination IP address. (B7) The relay node sets its own IP address to the source IP address, and sends the frame as the return frame.
A process conducted by each relay node receiving the return frame will be described. (C1) Any relay node identifies “Query” from the command name of a received frame. (C2) When the relay node receives the return frame, the relay node excludes the IP address shown in the return originator IP address field F2 from a search resource name shown by the research resource character string in the return frame as shown in
(C4a) The relay node 4 in
(C4b) The relay node sets an IP address obtained as the search result to the destination IP address, and sets its own IP address to the source IP address. Then, the replay node sends the return frame. (C5) When the search result is not obtained, the relay node checks that the relay node number F3 shows more than or equal to “1”. When the relay node number F3 shows “0”, the relay node itself is a source node to send the query frame. That is, since nodes other than the closed node do not open the resource or the service requested by the query frame in public, the relay node informs a user via an application, which requested to send the query frame, that it failed to find the resource and the service which the user requested.
When the relay node number F3 shows more than or equal to “1” (for example, the relay node 4 in
(C5a) The relay node writes its own IP address to the return originator IP address field F2.
(C5b) The relay node decrements the relay node number F3 by “1”.
(C5c) The relay node sets an IP address being stacked in the stack row corresponding to the relay node number F3 in the address stack F4 to be the destination IP address.
(C5d) The relay node sets its own IP address to the source IP address, and sends the received frame.
As an assumption, the node C becomes the closed node, and as a result, “resource/music/rock.mp3” opened by the node C is closed in public. In a state shown in
As shown in
Moreover, a delimiter maintaining part 12 stores a delimiter used for the resource name and the service name. An own IP address maintaining part 14 stores its own IP address (IP address of a node itself). The delimiter and its own IP address are input from a console 46 and stored, respectively beforehand.
In
The frame determining part 18 identifies the command type and the returned originator IP check field F1 shown in
The return originator IP address extracting part 24 identifies the IP address shown in the return originator IP address field F2 of the frame received from the frame determining part 18, and sends an delete instruction with the search resource character string and the IP address in the return originator IP address field F2 in the frame as arguments, to a table controlling part 26.
The table controlling part 26 searches the search table DB 10, and deletes the IP address indicated by the return originator IP address extracting part 24 from IP addresses of entries having a value “1” of the tree end flag (tree end flag=1) as a search result. Subsequently, the table controlling part 26 decrements an entry of the IP address number by “1”. Then, the table controlling part 26 informs the return originator IP address extracting part 24 that an update of the search table DB 10 ends. After that, the return originator IP address extracting part 24 sends the frame to the table searching part 22.
With respect to the table controlling part 26 in response to the name path setting frame supplied from the frame determining part 18, the name path setting part 28 conducts an add/delete instruction for data at that time when the data in the search table DB 10 is structured.
The table controlling part 26 conducts a structure/restructure of the search table DB 10. First, the table controlling part 26 accesses the delimiter maintaining part 12, obtains the delimiter being defined beforehand, decomposes the search resource character string in the frame by each delimiter, and search for the search table DB 10 by traversing the entries by an entry number and a previous entry number as keys. As a result, one of following processes is conducted.
In a case of the delete instruction from the return originator IP address extracting part 24, when the search result is obtained, from the IP addresses of the entries having the value “1” of the tree end flag (tree end flag=1) in the search table DB 10, the table controlling part 26 deletes the IP address indicated by the return originator IP address, the table controlling part 26 decrements the IP address number by “1”. Then, the end of a table update is informed to the return originator IP address extracting part 24. On the other hand, when the search result is not be obtained, no update is conducted with respect to the search table DB 10, and the end of the table update is informed to the return originator IP address extracting part 24.
In a case of an add instruction from the name path setting part 28 (process at a table structure), when the search result is obtained, from the IP addresses of the entries having the value “1” of the tree end flag (tree end flag=1), the table controlling part 26 adds an IP address indicated by the name path setting part 28, and the table controlling part 26 increments the IP address number by “1”. Then, the end of the table update is informed to the name path setting part 28. On the other hand, when the search result is not obtained, the table controlling part 26 conducts an add process for adding an entry. The table controlling part 26 adds a new entry number to the search table DB 10 from a not-used number, writes a value of the entry number being hit previously to the previous entry number, and the search character string to the name in the search table DB 10. In a case in that the search character string is a last character string segmented by the delimiter (for example, rock.mp3), the table controlling part 26 writes “1” to the tree end flag and the source IP address shown in the frame to an IP address 1 in the search table DB 10.
The table searching part 22 extracts an IP address of a next node to transfer from the query frame received from the frame determining part 18 or the return originator IP address extracting part 24. First, the table searching part 22 accesses the delimiter maintaining part 12, and obtains the delimiter that is defined beforehand. Next, the table searching part 22 decomposes the search resource character string in the frame by each delimiter, and searches the search table DB 10 by traversing the entries registered in the search table DB 10 by the entry number and the previous entry number as keys. As a result, one of the following processes is conducted.
In a case of a table hit, that is in a case in that IP addresses are obtained from the entries having the value “1” of the tree end flag of the search table DB 10 (tree end flag=1), each of the IP addresses is to be a search result. If a plurality of the search results are obtained, a certain algorithm (not shown) is conducted so as to select one of the IP addresses and to be a single search result.
Then, the table searching part 22 obtains the own IP address from the own IP address maintaining part 14, and compares the IP address obtained from the search table DB 10 with the own IP address. When both IP addresses are different from each other (another node), the table searching part 26 sets the IP address of the search result to be the destination IP address used when the IP frame creating part 20. The table searching part 26 sends the frame to a return check field determining part B 30. On the other hand, when both IP addresses are identical (own node), the table searching part 26 sends the resource or the service requested by the query frame to an application 32 in order to establish a TCP session with a source node.
When there is no hit to the search table DB 10, that is, when there is no entry corresponding to the name in the search table DB 10, the table searching part 22 sends the query frame to a return check field determining part A 34.
The return check field determining part A 34 identifies a value of the return originator IP check field F1 of the query frame received from the table searching part 22, and determines a next function block (next processing part) to conduct a process. When the return originator IP check field F1 shows “0” (return originator IP check field F1=0), the return check field determining part A 34 sends the query frame to a return originator IP address field updating part 36. On the other hand, when the return originator IP check field F1 shows “1” (return check field=1), the return check field determining part A 34 sends the query frame to a confirming part 38 for a relay node number@path node field. The relay node number@path node field represents the number of the relay nodes shown in the path node field in the frame.
The return check field determining part B 30 identifies the value of the return originator IP check field F1 of the frame, and determines a next functional block (next processing part) to conduct a process. In this case, a determination rule is different from the return check field determining part A 34. When the return originator IP check field F1 shows “0” (return originator IP check field F1=0), the return check field determining part B 30 sends the frame to a controlling part 40 for an address stack@path node field. On the other hand, when the return originator IP check field F1 shows “1” (return originator IP check field F1=0), the return check field determining part B 30 sends the frame to the return check field updating part 42. The address stack@path node field represents the address stack in the path node field in the frame.
The confirming part 38 for the relay node@path node field identifies the relay node number F3 in the path node field. The following operation is conducted based on an identification result. When the relay node number F3 shows “0” (relay node number F3=0), the own node is the source node of the query frame. Since there is no further destination to return the query frame, the confirming part 38 informs an application 44 that requests sending the query frame. On the other hand, when the relay node number F3 shows more than or equal to “1” (relay node number F3≧1) , the confirming part 38 sends the frame to the return originator IP address field updating part 36.
The return check field updating part 42 changes the value of the return originator IP check field F1. The return check field updating part 42 changes the value of the return originator IP check field F1 from “0” to “1”, and sends the frame to the controlling part 40 for the address stack@path node field. In addition, The return check field updating part 42 changes the value of the return originator IP check field F1 from “1” to “0”, and sends the frame to the IP frame creating part 20.
The return originator IP address field updating part 36 obtains its own IP address from the own IP address maintaining part 14, updates the return originator IP address field F2 in the frame to be its own IP address, and sends the frame to the controlling part 40 for the address stack@path node field.
The controlling part 40 for the address stack@path node field conducts the following processes with respect to the path node field in the frame. When the controlling part 40 receives the frame from the return check field determining part B 30, the controlling part 40 increments the relay node number by “1”, and stacks its own IP address obtained from the own IP address maintaining part 14 to the stack row corresponding to the relay node number F3 in the address stack F4. In addition, the controlling part 40 informs the IP address obtained by the table searching part 22 as the destination IP address to the IP frame creating part 20, and sends the frame to the IP frame creating part 20. It should be noted that the controlling part 40 does not obtain the IP address of a next transfer destination from the path address field.
Moreover, when the frame is received from the return originator IP address field updating part 36, the controlling part 40 for the address stack@path node field decrements the relay node number F3 by “1”, and obtains the IP address being stacked in the stack row corresponding to the relay node number F3 in the address stack F4. Then, the controlling part 40 informs the IP address as the destination IP address to the IP frame creating part 20, and sends the frame to the IP frame creating part 20.
Furthermore, when the frame is received from the return check field updating part 42, the controlling part 40 for the address stack@path node field obtains the IP address being stacked in the stack row corresponding to the relay node number F3 in the address stack F4. Then, the controlling part 40 informs the IP address as the destination IP address to the IP frame creating part 20, and sends the frame to the IP frame creating part 20.
The IP frame creating part 20 obtains the source IP address and the destination IP address, and creates an IP frame. The IP frame creating part 20 obtains the source IP address from the own IP address maintaining part 14. A pattern of the destination address is shown as follows. When there is no hit at the table searching part 22, the IP frame creating part 20 uses the IP address that is obtained by the controlling part 40 for the address stack@path node field and stacked in the path node field. When there is a hit at the table searching part 22, the IP frame creating part 20 uses the IP address obtained from the search table DB 10.
The console 46 is an interface for handling an input and an output by a user to set the delimiter to the delimiter maintaining part 12 and its own IP address to the own IP address maintaining part 14.
Next, in step S14, the returned check field determining part B 30 determines that the return check field F1 shows “0” (return check field F1=0). In step S15, the controlling part 40 for for the address stack@path node fields increments the relay node number F3 in the frame by “1”, stacks its own IP address to the stack row corresponding to the relay node number F3 in the address stack F4, and sets the IP address obtained by the table searching part 22 as the destination IP address. In step S16, the IP frame creating part 20 creates an IP frame and sends out the IP frame from the communication terminator 16 to the network.
Next, in step S24, the return check field determining part A 34 determines that the return check field F2 in the received frame shows “0” (return check field F2=0). In step S25, the return originator IP address field updating part 36 updates the return originator IP address field F2 in the received frame to show its own IP address. In step S26, the return check field updating part 42 updates the return originator IP check field F1 in the received frame to be “1” (return originator IP check field F1=1). In step S27, the controlling part 40 for an address stack@path node field sets the IP address being stacked in the stack row corresponding to the relay node number F3 in the address stack F4. In step S28, the IP frame creating part 20 creates a IP frame and sends out the IP frame from the communication terminator 16 to the network.
Next, in step S35, the return check field determining part B 30 determines that the return originator IP check field F1 shows “1” (return originator IP check field F1=1). In step S36, the return check field updating part 42 updates the return originator IP check field F1 in the received frame to show “0” (return originator IP check field F1=0). In step S37, the IP frame creating part 20 creates an IP frame and sends out the IP frame from the communication terminator 16 to the network.
Next, in step S45, the return check field determining part A 34 determines that the return originator IP check field F1 in the received frame shows “1” (return originator IP check field F1=1). In step S46, the confirming part 38 for the relay node@path node field determines that the relay node number F3 is more than or equal to “1”. In step S47, the return originator IP address field updating part 36 updates the return originator IP address field F2 to show its own IP address. In step S48, the controlling part 40 for an address stack@path node field decrements the relay node number F3 by “1”, obtains the IP address being stacked in the stack row corresponding to the relay node number F3 in the address stack F4, and sets the IP address to the source IP address in the received frame. In step S49, the IP frame creating part 20 creates an IP frame and sends out the IP frame from the communication terminator 16 to the network.
Next, in step S55, the return check field determining part A 34 determines that the return originator IP check field F1 in the received frame shows “1” (return originator IP check field F1=1). In step S56, the confirming part 38 for the relay node@path node field determines that the relay node number F3 is more than or equal to “0”. In step S57, the confirming part 38 informs the application 44 being a request originator of the query frame that the resource or the service requested by the query frame is not available through the network and the query frame is returned.
In this embodiment, the return check field updating part 42 corresponds to a return check field updating part cited in claims, the controlling part 40 for an address stack@path node field corresponds to an address stacking part cited in claims, the return originator IP address extracting part 24 corresponds to a stack address extracting part cited in claims, the return originator IP address field updating part 36 corresponds to a return originator address updating part cited in claims, and the table controlling part 26 corresponds to a table controlling part.
Regarding Japanese Laid-open Patent Application No. 10-70552 considering registrations of the extended address and the closed address, a concept to return a data frame at the relay node and any technology related to this concept are not disclosed. In addition, regarding Japanese Laid-open Patent Application No. 2001-203739, it is assumed that a destination is only one node, and the concept to return a data frame at the relay node and any technology related to this concept are not disclosed.
According to the present invention, it is possible to transfer an access request being sent to a closed node, which stops providing a resource or a service, to another node providing the same resource or the same service. Accordingly, instead of waiting for a periodical exchange of identifications, it is possible to inform each relay node that a node becomes the closed node.
The present invention is not limited to the specifically disclosed embodiments, and variations and modifications may be made without departing from the scope of the invention.
The present application is based on Japanese Priority Application No. 2004-203676 filed on Jul. 9, 2004, the entire contents of which are hereby incorporated by reference.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2004-203676 | Jul 2004 | JP | national |
