JP4780075B2 - Peer-to-peer communication system, node device, and program - Google Patents

Description

  The present invention provides a peer-to-peer communication system having a plurality of node devices connected to each other via a network in a peer-to-peer manner using a routing table, and a server connected to the node devices via the network The present invention relates to the node device.

  In order to share information such as contents (for example, audiovisual contents) among a plurality of node devices (for example, a plurality of personal computers), an overlay network is logically constructed by the participation of the plurality of node devices, and Thus, a technology that enables the plurality of node devices to communicate with each other has already been put into practical use.

  An example of such a communication system is disclosed in Patent Document 1 as a peer-to-peer communication system. In this communication system, a plurality of node devices are assigned a plurality of logical positions on the overlay network. For example, a distributed hash table (DHT) is used in order to distribute and store a plurality of logical positions respectively assigned to a plurality of node devices on the overlay network.

  In the peer-to-peer communication system described above, it is possible for other node devices to correctly acquire information on whether or not each node device is actually alive on the overlay network, so that normal information exchange between the node devices is maintained. Is important to do.

  On the other hand, there is no problem when each node device normally leaves the overlay network, that is, when the connection with the network is terminated after performing the regular termination procedure. May end. For example, if there is a software defect in the node device or a cable that disconnects or disconnects a physical connection between the node device and the network, the node device does not notify other node devices in advance. There is a possibility of leaving the network.

Because of this possibility, in a peer-to-peer communication system, conventionally, any node device is connected to a server that centrally monitors the node devices, whereby each node device has a server-client. A system was built. In the server-client system, any node device periodically notifies the server of a Keep Alive message that is negotiated in advance with the server. It has become possible to monitor whether a device is alive on the overlay network. Specifically, the server issues an alarm to the administrator of the peer-to-peer communication system that an abnormality has occurred in the node device when reception of the keep alive message from a certain node device is interrupted and a certain time has elapsed.
JP 2006-197400 A

  However, in this conventional node monitoring method, when the number of node devices to be monitored by the same server increases, the load on the server increases. Therefore, when it is necessary to reduce the burden imposed on the server for node monitoring as much as possible, it is difficult to cope with the conventional node monitoring method.

  Against the background described above, the present invention is connected to a plurality of node devices connected to each other via a network in a state where communication can be performed in a peer-to-peer manner using a routing table, and to the node devices via the network. In a peer-to-peer communication system having a server and the node device, it is possible to completely or partially omit the burden imposed on the server to monitor whether each node device is alive on the network. It was made to do.

  The following aspects are obtained by the present invention. Each aspect is divided into sections, each section is given a number, and is described in a form that cites other section numbers as necessary. This is to facilitate understanding of some of the technical features that the present invention can employ and combinations thereof, and the technical features that can be employed by the present invention and combinations thereof are limited to the following embodiments. Should not be interpreted. That is, it should be construed that it is not impeded to appropriately extract and employ the technical features described in the present specification as technical features of the present invention although they are not described in the following embodiments.

  Further, describing each section in the form of quoting the numbers of the other sections does not necessarily prevent the technical features described in each section from being separated from the technical features described in the other sections. It should not be construed as meaning, but it should be construed that the technical features described in each section can be appropriately made independent depending on the nature.

(1) A peer-to-peer communication system having a plurality of node devices connected to each other via a network in a state where communication can be performed in a peer-to-peer manner using a routing table, and servers connected to the node devices via the network. And
Each node device has a function as a survival confirmation requesting node for requesting other node devices to monitor whether or not the own node device is alive on the network, and whether or not the other node device is alive on the network. Function as a monitoring node to monitor,
Each node device
Monitoring node selection that, when functioning as the existence confirmation request node, selects at least one of the other node devices stored in the routing table for the own node device as a monitoring node that should monitor the own node device Including means,
Each node device
When functioning as the monitoring node, survival determination means for determining whether other node devices as the survival confirmation request node survive on the network,
A peer-to-peer notifying means for notifying the server that the survival confirmation requesting node does not survive on the network when the survival determining means determines that the survival confirmation requesting node does not survive on the network. Communications system.

  In this peer-to-peer communication system, a plurality of node devices use the contents of the routing table for each node device to determine whether or not each node device is alive on the network. Only when it is determined by another node device that the node device does not survive on the network, the server is notified that the node device does not survive on the network.

  Thus, according to this peer-to-peer communication system, it is no longer necessary for the server to monitor all the node devices individually and regularly, and thus is imposed on the server to monitor each node device. The burden is reduced. In other words, any node device that should survive on the network does not generate a large amount of traffic between the plurality of node devices and the server at the normal time when the node device actually survives on the network. Since only traffic between the node device and the server needs to be generated only when there is an abnormality that does not actually survive on the network, the load on the server is reduced.

(2) The server
Storage means for storing in advance the installation positions of a plurality of node devices participating in the network in association with node IDs;
When each node device functioning as the monitoring node is notified that the survival confirmation request node does not survive on the network, the access to the storage unit is performed to access the survival confirmation request node on the network. The peer-to-peer communication system according to item (1), further including: a position specifying unit that specifies an installation position.

  In this peer-to-peer communication system, when it is determined that a certain node device does not survive on the network, the installation position of the node device on the network is specified.

  Therefore, according to this peer-to-peer communication system, a network administrator can quickly provide necessary information and services (including recovery work) to node devices that do not survive on the network. Is possible.

(3) A node device connected to a plurality of other node devices via a network in a state in which communication can be performed in a peer-to-peer manner using a routing table, and connected to a server via the network,
Monitoring means for monitoring whether or not the survival confirmation requesting node that requested the node device to monitor whether or not to survive on the network survives on the network;
Based on the monitoring result by the monitoring means, a survival determination means for determining whether or not the survival confirmation request node is alive on the network,
A node that includes notification means for notifying the server that the survival confirmation request node does not survive on the network when it is determined by the survival determination means that the survival confirmation request node does not survive on the network. apparatus.

  When this node device accepts a request to monitor whether or not another node device connected to the same network is alive on the network, the other node device monitors the other node device, thereby Determine whether to survive. Further, when it is determined that another node device does not survive on the network, this node device notifies the server of that fact.

  Therefore, according to this node device, it is possible to monitor whether or not another node device is alive on the network without depending on the server. Therefore, the server can be used to monitor another node device. The burden imposed is reduced.

(4) The node device according to (3), wherein the monitoring unit includes a time-limited monitoring unit that monitors the survival confirmation requesting node when a designated time arrives.

(5) The monitoring unit includes a transmission unit that transmits a specific request to the survival confirmation requesting node,
The survival determination unit includes a determination unit that determines that the survival confirmation request node does not survive on the network when the survival confirmation request node does not return a response to the node device in response to the transmission of the request. The node device according to (3) or (4).

(6) including monitoring node storage means for storing other monitoring nodes that monitor the same survival confirmation requesting node;
The monitoring node storage means that the notification means determines that the survival confirmation request node does not survive on the network when the survival judgment means determines that the survival confirmation request node does not survive on the network. The node device according to any one of (3) to (5), including other monitoring node notification means for notifying other monitoring nodes stored in the node.

  According to this node device, when the same existence confirmation requesting node is monitored by a plurality of monitoring nodes, if the own node device determines that the existence confirmation requesting node does not survive on the network, that is the case. Shared by nodes.

  Therefore, it is possible to reduce the possibility that the same survival confirmation request node is redundantly monitored unscheduled by a plurality of monitoring nodes, and as a result, the monitoring burden imposed on each monitoring node can be reduced. It becomes possible.

(7) The node device according to any one of (3) to (6), including withdrawal notification means for notifying the survival confirmation requesting node of withdrawal when leaving the network.

  According to this node device, when a monitoring node that should monitor the survival confirmation request node leaves the network, this is notified to the survival confirmation request node. Therefore, it is possible to avoid a situation where the survival confirmation request node is not monitored.

(8) A survival confirmation request node storage unit that stores the survival confirmation request node to be monitored;
A node number determination means for determining whether or not the number of the survival confirmation request nodes stored in the survival confirmation request node storage means exceeds a predetermined value when a survival confirmation request is received;
When it is determined by the node number determination means that the number of the survival confirmation request nodes is equal to or less than the predetermined value, the request for survival confirmation is accepted, and when it is determined that the number exceeds the predetermined value The node device according to any one of (3) to (7), including request acceptance / rejection means for rejecting a request for confirmation of existence.

  According to this node device, when the same monitoring node is allowed to monitor a plurality of survival confirmation request nodes, the number of survival confirmation request nodes to be monitored by the same monitoring node is excessive. For this reason, it is possible to prevent an excessive monitoring burden on the monitoring node.

(9) including monitoring node storage means for storing other monitoring nodes that monitor the same survival confirmation requesting node;
When the communication to the server fails, the notification means notifies the other monitoring nodes stored in the monitoring node storage means that the survival confirmation request node does not survive on the network. The node device according to any one of items (3) to (8), including proxy notification means for requesting to do so.

  According to this node device, since a certain monitoring node has determined that a certain survival confirmation request node does not survive on the network, an attempt was made to notify the server. By using the monitoring node, notification to the server is attempted. Therefore, according to this node device, information indicating that a certain survival confirmation request node does not survive on the network is notified to the server without fail, and accordingly, it is also notified to the network administrator.

(10) A node device connected to a plurality of other node devices via a network and capable of communicating in a peer-to-peer manner using a routing table, and connected to a server via the network,
Monitoring node selection means for selecting at least one of the other node devices stored in the routing table for the own node device as a monitoring node to be monitored;
A node device comprising: a survival confirmation requesting unit that requests the monitoring node selected by the monitoring node selecting unit to monitor whether or not the own node device is alive on the network.

  According to this node device, when there are a plurality of other node devices capable of monitoring the node device, at least one of the node devices is monitored by referring to the routing table for the node device. Automatically selected as. Further, it is determined by the selected monitoring node whether or not the own node device survives on the network.

(11) monitoring node determination means for determining whether or not the monitoring node has confirmed the existence of the own node device;
A monitoring node changing unit for selecting a node device different from the monitoring node as a new monitoring node when the monitoring node determining unit determines that the monitoring node has not confirmed the existence of the own node device; The node device according to item (10), including:

  According to this node device, when it is found that the monitoring node that should monitor the own node device does not monitor the own node device for some reason, another node device is automatically selected as a new monitoring node. The Therefore, according to this node device, it is possible to monitor whether or not the own node device survives on the network even if the monitoring node selected first is abnormal.

(12) The monitoring node determination unit includes a non-survival determination unit that determines that the monitoring node has not confirmed the existence of the own node device when a specific request is not received from the monitoring node at a specified time. The node device according to item (11).

(13) Item (11) or (12) including a monitoring node changing unit that selects a node device different from the monitoring node as a new monitoring node when the monitoring node receives a message to leave the network. The node device described in 1.

  According to this node device, when a monitoring node that should monitor the local node device leaves the network, the local node device is monitored by another monitoring node, so that the local node is disconnected from the network. Occurrence of a situation where the device is no longer monitored is avoided.

(14) A program executed to cause a computer to function as each unit of the node device according to any one of (3) to (13).

  If this program is executed by a computer, the same operational effects can be realized in accordance with basically the same principle as that of the device according to any one of the above items (3) to (13).

  The program according to this section can be interpreted so as to include not only a combination of instructions executed by a computer to fulfill its function, but also files and data processed in accordance with each instruction.

  In addition, this program may achieve its intended purpose by being executed by a computer alone, or may be intended to achieve its intended purpose by being executed by a computer together with other programs. it can. In the latter case, the program according to this section can be mainly composed of data.

(15) A recording medium on which the program according to item (14) is recorded in a computer-readable manner.

  If the program recorded on the recording medium is executed by a computer, the same operational effects as those of the method according to any one of (3) to (13) can be realized.

  This recording medium can adopt various formats, for example, a magnetic recording medium such as a flexible disk, an optical recording medium such as a CD and a CD-ROM, a magneto-optical recording medium such as an MO, and an unremovable storage such as a ROM. Any of these may be adopted.

  Hereinafter, one of more specific embodiments of the present invention will be described in detail with reference to the drawings. In the present embodiment, when the present invention is applied to an information communication system S that makes it possible to perform peer-to-peer communication while sharing information such as content among a plurality of node devices by configuring an overlay network using DHT. It is an example.

  FIG. 1 systematically shows the connection configuration of the information communication system S. In this information communication system S, each node device selectively performs various processes according to the type of role that changes over time.

  Schematically, each node device (represented by a white circle in FIG. 1) calculates a node ID, creates a routing table, and receives messages from other node devices, as is well known. To the node device, processing according to the message received from the other node device, and the like. The basic operation of the information communication system S is disclosed in Japanese Patent Application Laid-Open No. 2006-197400, and the disclosure content thereof is incorporated into the present specification by quoting the official gazette as a whole.

  Next, the physical configuration and logical configuration of the information communication system S will be described with reference to FIG. In FIG. 1, the overlay network 9 as a logical entity is systematically shown in the upper frame denoted by reference numeral 100, while the physical existence is present in the lower frame denoted by reference numeral 101 in FIG. 1. The network (for example, the Internet, LAN, WAN) 8 is systematically shown.

  As shown in the lower frame 101, an IX (Internet eXchange) 3, an ISP (Internet Service Provider) 4, a DSL (Digital Subscriber Line) line provider is used to construct a physical network (real-world network) 8. Apparatus 5, apparatus 6 for FTTH (Fiber To The Home) line operators, communication line (for example, telephone line, optical cable, etc.) 7, etc. are used.

  The information communication system S is configured to include a plurality of node devices 1a, 1b, 1c,..., 1x, 1y, 1z,. Thus, a peer-to-peer network system is realized.

  Each node device 1a, 1b, 1c,..., 1x, 1y, 1z,... Has a serial number unique to each node device 1 as information (device ID) indicating the identity of each node device 1. And an IP (Internet Protocol) address. The serial number and IP address of each node device 1 are set so as not to overlap among the plurality of node devices 1.

  Hereinafter, for convenience of explanation, the node device 1a, 1b, 1c,..., 1x, 1y, 1z,.

  The information communication system S calculates a node ID using a distributed hash table DHT (Distributed Hash Table). Specifically, the information communication system S constructs the overlay network 9 as shown in the upper frame 100 of FIG. 1 by an algorithm using DHT. The overlay network 9 means a network composed of virtual links formed using the existing network 8.

  Next, the configuration and function of each node device 1 will be described with reference to FIG. Since the configuration of each of the plurality of node devices 1 is common to each other, only one node device 1 will be representatively described. FIG. 2 schematically shows an example of the configuration of the representative node device 1.

  As illustrated in FIG. 2, the node device 1 includes a control unit 11 and a storage unit 12. The control unit 1 includes a computer including a CPU having a calculation function, a working RAM, a ROM that stores various data and programs, and the like. The storage unit 12 includes an HD for storing and storing (stores) content data, index information, the DHT, the program, and the like. However, among the plurality of node devices 1, there is also a node device 1 that does not store content data.

  The node device 1 further decodes the encoded video data (video information), audio data (sound information), etc. included in the content memory and the buffer memory 13 for temporarily storing the received content data, etc. And a decoder unit 14 for decoding and the like. The node device 1 further performs a predetermined drawing process on the decoded video data or the like and outputs it as a video signal, and a CRT that displays a video based on the video signal output from the video processing unit 15 And a display unit 16 such as a liquid crystal display.

  The node device 1 further converts the decoded audio data into an analog audio signal by D (Digital) / A (Analog) conversion, amplifies the signal by an amplifier, and outputs the signal, and the audio processing unit The speaker 18 which outputs the audio signal output from 17 as a sound wave is provided.

  The node device 1 further receives a command from the user and performs an instruction signal in accordance with the instruction from the communication unit 20 for performing communication control of information with the other node device 1 through the network 8. An input unit (for example, a keyboard, a mouse, an operation panel, etc.) 21 is provided.

  As shown in FIG. 2, the control unit 11, the storage unit 12, the buffer memory 13, the decoder unit 14, and the communication unit 20 are connected to each other via a bus 22.

  In the node device 1, the CPU in the control unit 11 executes various programs stored in the storage unit 12 and the like, whereby the entire node device 1 is controlled in an integrated manner. Further, content data registration processing or the like is performed in response to an instruction signal from the input unit 21.

  As is well known, each node device 1 creates a routing table as shown in the table of FIG. 3 in order to participate in the overlay network. Further, each node device 1 changes its role depending on the type of program to be executed. Specifically, each node device 1 functions as a node device that transmits (transfers) information, or as a node device that receives information. Function.

  In this information communication system S, whether or not each node device 1 has stopped without undergoing a normal termination procedure, that is, whether or not it is abnormal, is determined by using the above routing table. It is determined by performing communication.

  This abnormality detection technique will be described more specifically with reference to FIGS. 4 (a) and 4 (b). First, the own node X has a group of nodes {A (1), A (2),. . . , A (N)} from some nodes {A (1), A (2),. . . , A (k)} is requested to confirm that the own node X is alive on the network 8 (hereinafter referred to as “request for alive confirmation”). Since the other node device 1 that has been requested to confirm the existence of the node has a role of monitoring the own node X, it is hereinafter referred to as a monitoring node.

  At the time of this request, the time at which each monitoring node should access its own node X (that is, the monitoring time) is designated by its own node X, but the designation method is not limited to this. For example, each monitoring node designates itself. May be. As a result, the own node X makes its own node X live in order one by one in a plurality of nodes A (1) to A (k) (k = 3 in the example shown in FIG. 4), which are monitoring nodes. Confirmation is requested (indicated as “confirmation request” in FIG. 4A).

  When the own node X normally survives on the network 8, as shown in FIG. 4A, in response to the access from each monitoring node, the response indicating that it survives (FIG. 4A ) Is sent back to each monitoring node.

  On the other hand, when the own node X intends to stop through the normal termination procedure, as shown in FIG. 4A, before leaving the network 8, the monitoring node group {A (1), A (2),. . . , A (k)} respectively, a withdrawal message (indicated as “NG” in FIG. 4A) is transmitted. Node groups {A (1), A (2),. . . , A (k)} thereafter does not check the existence of the own node X.

  Even if any monitoring node transmits a message for confirming its existence to its own node X because it has not received a withdrawal message from its own node X and is not even alive in the network 8. On the other hand, when the own node X does not respond at all (indicated by “no response” in FIG. 4B), the monitoring node notifies the server 200 of the abnormality of the own node X, and Notify other monitoring nodes.

  FIG. 5 conceptually shows the configuration of the server 200 in a block diagram. This server 200 has a configuration that is basically in common with the node device 1 shown in FIG. Specifically, in the server 200, the processor 202 and the storage unit 204 are connected to each other via a bus 205, thereby configuring a computer.

  An input / output controller 206 is further connected to the bus 205, and an input device 210 such as a mouse and an output device 212 such as a liquid crystal display and a printer are connected to the input / output controller 206. A communication unit 220 is further connected to the bus 205, and the server 200 is connected to any terminal on the network 8 (including a plurality of node devices 1 and clients associated with the server 200) via the communication unit 220. It is possible to communicate with.

  Briefly described, the server 200 is used by an administrator who centrally maintains and manages a plurality of node devices 1 constituting the information communication system S. Further, in this server 200, the installation locations of the nodes participating in the network 8 are registered in advance.

  When this server 200 receives notification from one of the monitoring nodes that the own node X is not alive, that is, an abnormality, the server 200 displays the location of the own node X where the abnormality has occurred on the screen of the server 200. Displaying and / or transmitting to a client (not shown) connected to the server 200 and displaying it on the screen of the client. Therefore, when an abnormality occurs in the own node X, the server 200 can promptly notify the administrator of the information communication system S of this, so that the administrator can detect the failure of the own node X. It is possible to take necessary measures such as responding quickly.

  Next, processing executed in each node device 1 will be specifically described with reference to a flowchart. In FIG. 6, the main program executed by the control unit 11 is conceptually represented by a flowchart. This main program is activated in response to power-on of each node device 1, and first, in step S1, a routing table is created in order to participate in the peer-to-peer network 8.

  Next, in step S2, a function as a survival confirmation request node is started, and in step S3, a function as a monitoring node is started. Steps S2 and S3 are both executed in parallel as a thread.

  Specifically, in step S2, when the own node device 1 functions as a survival confirmation requesting node that requests the monitoring node to confirm the existence of the own node device, another node device to which monitoring is requested Node devices are added to or deleted from the survival confirmation request list (see FIG. 7A for the example shown in FIG. 3). Details of this step S2 will be described later as a survival confirmation request routine with reference to FIG.

  On the other hand, in step S3, when the own node device 1 functions as a monitoring node for other node devices, a monitoring list for specifying other node devices to be monitored (for the example shown in FIG. 3). , (See FIG. 7B), node devices are added / deleted. The details of this step S3 will be described later with reference to FIG. 9 which conceptually shows it as a monitoring routine in a flowchart.

  Returning to FIG. 6, in step S <b> 4, the local node device 1 waits to receive a message from another node device 1. If received, in step S5, the received message is processed in a manner suitable for it. Subsequently, in step S6, it is determined whether or not there has been a shutdown request from the user to the node device 1. If there is no shutdown request, the process returns to step S4. If there is a shutdown request, in step S7, it is waited for both the function as the survival confirmation requesting node and the function as the monitoring node to end. If completed, the execution of this main program ends.

  Here, the details of step S2 shown in FIG. 6 will be described with reference to the flowchart of FIG. First, in step S101, in order to create a survival confirmation request list, a survival confirmation request list creation routine conceptually shown in the flowchart of FIG. 10 is executed.

  By executing this survival confirmation request list creation routine, another node device 1, that is, a monitoring node that should monitor the own node device 1 is determined. An outline of the monitoring node determination technique will be described.

  As described above, the own node device 1 creates a routing table when participating in the network 8. When the node ID is 128 bits, a maximum of 256 (= 16 × 16) node devices 1 exist in the routing table.

  When the own node device 1 functions as a survival confirmation request node, the other node devices 1 stored in the routing table of the own node device 1 are requested to confirm the existence, but all of the 256 node devices 1 are requested. When requesting the existence confirmation, if an abnormality occurs in the own node device 1, it is not efficient because 256 node devices 1 need to detect the abnormality of the own node device 1. Therefore, the node group {A (1), A (2),..., A (k)} that should confirm the existence of the own node device 1 is appropriately selected from the node devices 1 stored in the routing table. It is desirable to select it as a monitoring node.

  Specifically, in this embodiment, for example, the routing table shown in FIG. 3 scans the level 1 row from the left end to the right end, and when reaching the right end, returns to the left end of the next level row. Thereby, each node device 1 is sequentially determined as a monitoring node.

  For example, when it is necessary to check the existence of the own node device 1 at intervals of 15 minutes, four (= 60 (minutes) / 15 (minutes)) node devices 1 are determined as monitoring nodes, respectively. In this case, the monitoring frequency of each monitoring node is 1 time / hour. For example, when the routing table shown in FIG. 3 is used, first, the first four node devices A to D are determined as monitoring nodes, and the node device E becomes the next monitoring node candidate.

  Furthermore, by executing this survival confirmation request list creation routine, a request for survival confirmation is made from the own node device 1 to the monitoring node. The outline of the survival confirmation request technology will be described.

  The own node device 1 designates the time at which the monitoring node should confirm the existence of the own node device 2 (hereinafter referred to as “survival confirmation time”). In the example shown in FIG. 3, for example, if the start time of the survival confirmation is 14:00, node A is 14:00, node B is 14:15, node C is 14:30, and node D is 14:45 is indicated as the survival confirmation time.

  The own node device 1 stores the node ID and IP address of the monitoring node and the above-mentioned survival confirmation request list (the monitoring node and the survival confirmation time are stored in association with each other as shown in FIG. 7A). Remember. Each monitoring node receives the node ID, IP address, survival confirmation time, and survival confirmation request list of the own node device 1 from the own node device 1 and stores them.

  For example, in the example illustrated in FIG. 3, when the own node device 1 receives a message for which the existence of the node A is confirmed by the node A at 14:00, the own node device 1 responds with a response to the next existence confirmation time. Includes information that is 15:00. This is because when the existence of the own node device 1 is confirmed at intervals of 15 minutes, the survival confirmation time of the last node D is 14:45, and the time after 15 minutes from that time is the next survival confirmation time. Because it becomes. When the own node device 1 updates the survival confirmation time in this way, the monitoring node also updates the survival confirmation time accordingly.

  The same monitoring node may already be monitoring other node devices. If the number of monitoring for the same monitoring node increases, a new request for confirmation of survival can be rejected.

  The outline of the survival confirmation request list creation routine shown in FIG. 10 has been described above, but will be described in detail below with reference to FIG.

  First, in step S301, initial setting is performed. Specifically, the number of monitoring nodes that should monitor the own node device 1 (= node X) (the number of monitoring nodes registered in the survival confirmation request list) is set to N, and other node devices 1 monitor The value of the monitoring node determination number k as an integer that is incremented by 1 every time it is determined as a node is set to 0, the time interval for sequentially performing the survival check is set to Δt (specified value), and the survival check starts The time (first time at which the own node device 1 should be monitored) is set to T (specified value). Furthermore, the position (i, j) (i: row number, j: column number) of the monitoring node candidate on the routing table is set to (0, 0).

  Next, in step S302, the survival confirmation request list is cleared. Subsequently, in step S303, it is determined whether or not any node device 1 is registered at the position (i, j) on the routing table. If no node device 1 is registered, the column number j is incremented by 1 in step S304, and then the current value of the column number j matches the number of columns in the routing table in step S305. It is determined whether or not. If they do not match, the process returns to step S303. If they match, in step S306, the row number i is incremented by 1, and the column number j is returned to “0”.

  Subsequently, in step S307, it is determined whether or not the current value of the line number i matches the number of levels in the routing table (“4” in the example shown in FIG. 3). If they do not match, the process returns to step S303. If they match, the line number i is returned to “0” in step S308, and then the process returns to step S303.

  On the other hand, when any node device 1 is registered at the position (i, j) on the routing table, the determination at step S303 is YES, and at step S309, the position (i, j) on the routing table. It is determined whether or not the node device 1 registered in is the own node device 1. If so, the process proceeds to step S304. Otherwise, if no node device 1 is registered in step S310, the column number j is incremented by 1 in step S304. Thereafter, the process proceeds to step S310.

  In step S310, the node device 1 registered at the position (i, j) on the routing table is determined as the monitoring node, and when the survival confirmation start time T has arrived for the monitoring node, It is requested to confirm the existence of the node device 1. Subsequently, in step S311, it is determined whether or not there is a response from the node device 1 (monitoring node) registered at the position (i, j) on the routing table to affirm the survival confirmation request. If there is no affirmative response, the process proceeds to step S304. If there is, the process proceeds to step S312.

  In this step S312, the node ID, IP address, and survival confirmation time t of the node device 1 (monitoring node) registered at the position (i, j) on the routing table in the survival confirmation request list of the own node device 1. (This time coincides with the survival confirmation start time T) is stored.

  Thereafter, in step S313, the monitoring node determination number k is incremented by one. Subsequently, in step S314, it is determined whether or not the current value of the monitoring node determination number k matches the monitoring node number N. If they do not match, the next survival confirmation time t is determined in step S315 as the current survival start time t (this time coincides with the survival confirmation start time T) plus the time interval Δt. Subsequently, the process proceeds to step S304.

  On the other hand, if the current value of the monitoring node determination number k matches the monitoring node number N, after all the necessary monitoring nodes are determined in step S316, The node ID, IP address, survival confirmation time t, and survival confirmation request list of the own node device 1 are transmitted. This is the end of the execution of the survival confirmation request list creation routine, and then the process proceeds to step S102 shown in FIG.

  FIG. 11 is a sequence diagram showing a procedure performed when the survival confirmation request list creation routine is executed for the example shown in FIG.

  In step S102 shown in FIG. 8, in order for the node device 1 to detect an abnormality of the monitoring node, a monitoring node abnormality detection routine conceptually shown in the flowchart of FIG. 12 is executed. This monitoring node abnormality detection routine is executed as a thread, and as a result, is executed in parallel with other steps.

  Briefly, when this monitoring node abnormality detection routine is executed, the monitoring node of interest does not confirm the existence of the own node device 1 even if the survival confirmation time t associated therewith has elapsed. Therefore, if the node device 1 remains without being deleted from the survival confirmation request list, the node device 1 determines that the monitoring node has stopped abnormally. In this case, the own node device 1 requests the next monitoring node candidate to confirm the existence that the abnormal monitoring node should have performed according to the above-described monitoring node selection procedure.

  Specifically, when this monitoring node abnormality detection routine is started, first, in step S401, the number of monitoring nodes, that is, the number of monitoring nodes registered in the survival confirmation request list of the own node device 1 is set to N. In addition, a number i for specifying a monitoring node to be noted is set to “1”.

  Next, in step S402, among the plurality of monitoring nodes, it is associated with the one that is noticed this time (the monitoring node having the current value of the number i, hereinafter referred to as “current monitoring node A (i)”). It is determined whether the survival confirmation time t has elapsed.

  In the present embodiment, the current monitoring node A (i) originally monitors the survival confirmation request node when the survival confirmation time t arrives, and as a result, from the monitoring list of the survival confirmation request node. Should be deleted. On the other hand, if the survival confirmation request node does not receive any specific request from the corresponding monitoring node A even though the survival confirmation time t has elapsed, each monitoring node A It is designed to determine that it has not been confirmed normally.

  Therefore, even if the survival confirmation time t has elapsed, the fact that the current monitoring node A (i) exists in the monitoring list means that the current monitoring node A (i) did not perform the survival confirmation at the survival confirmation time t. Means that. Therefore, in this step S402, it is finally determined whether or not the current monitoring node A (i) has not confirmed the survival at the survival confirmation time t.

  If the survival confirmation time t associated with the current monitoring node A (i) has not elapsed, the number i is incremented by 1 in step S403, and then the current value of the number i is monitored in step S404. It is determined whether the number of nodes is greater than N. If the current value of the number i is not greater than the number N of monitoring nodes, the process immediately returns to step S402. If it is greater, the current value of the number i is returned to “1” in step S405, and then the process returns to step S402. Return.

  On the other hand, when the survival confirmation time t associated with the current monitoring node A (i) has elapsed (that is, when the current monitoring node A (i) has not performed the survival confirmation at the survival confirmation time t). In step S402, the determination in step S402 is YES. In step S406, the next monitoring node candidate (for example, node B in the example shown in FIG. 3) is confirmed to be alive in association with the current monitoring node A (i). It is requested to confirm the existence of the own node device 1 at the next survival confirmation time t when the time interval P has elapsed from the time t.

  Subsequently, in step S407, the node device that has received the request is set as a new monitoring node A (i), and the node ID of the new monitoring node A (i) is displayed in the survival confirmation request list of the own node device 1. , The IP address and the survival confirmation time t are stored. Thereby, the survival confirmation request list of the own node device 1 is updated.

  Subsequently, in step S408, the number i is returned to “1”. Thereafter, in step S409, the updated survival confirmation request list is notified to the current monitoring node A (i). Subsequently, in step S410, the number i is incremented by 1. Thereafter, in step S411, it is determined whether or not the current value of the number i is larger than the number N of monitoring nodes. If the current value of the number i is not larger than the number N of monitoring nodes, the process returns to step S409, but if larger, the process returns to step S401.

  Returning to FIG. 8, in step S <b> 103, it is determined whether or not the own node apparatus 1 has received a withdrawal message from the monitoring node. If received, in step S104, the monitoring node deletion routine conceptually shown in the flowchart of FIG. 13 is executed to delete the withdrawn monitoring node from the survival confirmation request list of the own node device 1. Is done.

  In this monitoring node deletion routine, first, in step S451, the number of monitoring nodes, that is, the number of monitoring nodes registered in the survival confirmation request list of the own node device 1 is set to N. The number i for specifying the node is set to “1”.

  Next, in step S452, the monitoring node that has transmitted the withdrawal message (in the example illustrated in FIG. 3, for example, node A may be applicable. It is determined whether or not the node ID of the monitoring node A (i) of this time and the node ID of the current monitoring node A (i) match. If they do not match, the number i is incremented by 1 in step S453.

  Thereafter, in step S454, it is determined whether or not the current value of the number i is larger than the number N of monitoring nodes. If it is not larger, the process returns to step S452. If it is larger, the process proceeds to step S456. If the node ID of the node A that transmitted the withdrawal message and the node ID of the current monitoring node A (i) match each other, in step S455, the current monitoring node A (i) After being deleted, the process proceeds to step S456.

  In any case, in step S456, a response indicating that the withdrawal message has been received is sent to the node A that has transmitted the withdrawal message. Subsequently, in step S457, the time interval P has elapsed from the survival confirmation time t associated with the current monitoring node A (i) to the next monitoring node candidate (for example, node B in the example shown in FIG. 3). It is requested to confirm the existence of the node device 1 at the next existence confirmation time t.

  Subsequently, in step S458, the node device that has received the request is set as a new monitoring node A (i), and the node ID of the new monitoring node A (i) is added to the survival confirmation request list of the own node device 1. , The IP address and the survival confirmation time t are stored. Thereby, the survival confirmation request list of the own node device 1 is updated.

  Subsequently, in step S459, the number i is returned to 1. Thereafter, in step S460, the updated survival confirmation request list is notified to the current monitoring node A (i). Subsequently, in step S461, the number i is incremented by 1. Thereafter, in step S462, it is determined whether or not the current value of the number i is greater than the number N of monitoring nodes. If the current value of the number i is not larger than the number N of monitoring nodes, the process returns to step S460. If it is larger, the execution of this monitoring node deletion routine ends.

  Thereafter, in step S105 shown in FIG. 8, it is determined whether or not the user has issued a shutdown request to the node device 1. If a shutdown request has not been issued, the process returns to step S103. If a shutdown request has been issued, the node apparatus 1 withdraws from the network 8 in step S106. The node withdrawal notification routine is executed.

  Briefly described, when this node withdrawal notification routine is executed, the own node device 1 transmits a withdrawal message to all the monitoring nodes when attempting to leave the network 8. Each monitoring node that has received the withdrawal message does not confirm the existence of its own node device 1 thereafter.

  Specifically, when this node withdrawal notification routine is executed, first, in step S501, the number of monitoring nodes, that is, the number of monitoring nodes registered in the survival confirmation request list of the own node device 1 is N. In addition, the number i assigned to each of the plurality of monitoring nodes to which the survival confirmation is requested is set to “1”.

  Next, in step S502, a withdrawal message is transmitted to the current monitoring node A (i). Subsequently, in step S503, it is awaited to receive a response from the current monitoring node A (i). If a response is received, in step S504, the number i is incremented by 1. Subsequently, in step S505, it is determined whether or not the current value of the number i is greater than the number N of monitoring nodes. If the current value of the number i is not greater than the number N of monitoring nodes, the process returns to step S502. If it is greater, the execution of this node withdrawal notification routine is terminated.

  FIG. 15 is a sequence diagram showing a procedure performed when this node withdrawal notification routine is executed for the example shown in FIG. In this example, the monitoring node A (1) notifies the server 200 that the node X has stopped abnormally if there is no response to the existence confirmation of the node X even though there is no withdrawal message from the node X. . If the monitoring node A (1) fails to notify the server 200, the monitoring node A (1) requests an alternate notification to the other monitoring node A (2) that monitors the same survival confirmation requesting node. If the monitoring node A (2) succeeds in notifying the server 200, the monitoring node A (2) notifies all monitoring nodes (here, only A (3)) that monitor the same survival confirmation request node that the node X has stopped abnormally. .

  Here, details of step S3 shown in FIG. 6 will be described with reference to the flowchart of FIG. As described above, step S3 is executed in order for the own node device 1 to function as a monitoring node, that is, as a node that monitors the survival confirmation requesting node device.

  As shown in FIG. 9, in step S3, first, step S201 is executed. In this step S201, the own node apparatus 1 is conceptually represented by a flowchart in FIG. 16 in order to detect an abnormality of the node apparatus that has requested the existence confirmation to the own node apparatus 1 as a monitoring node. A survival confirmation request node abnormality detection routine is executed. This survival confirmation request node abnormality detection routine is executed as a thread, and as a result, is executed substantially in parallel with other steps.

  To explain briefly, when this survival confirmation request node abnormality detection routine is executed, the own node device 1 (which functions as a monitoring node this time) is connected to the survival confirmation request node (in the example shown in FIG. X) If no withdrawal message has been received from the existence confirmation request node, and there is no response from the existence confirmation request node even if a confirmation message is sent to the existence confirmation request node. Then, it is determined that the survival confirmation request node has stopped abnormally, and this is notified to the server 200.

  In this case, if the node device 1 fails to notify the server 200, the node device 1 selects one of the other plurality of monitoring nodes that should monitor the same survival confirmation request node as the proxy monitoring node, and sets it as the proxy monitoring node. The server 200 is requested to notify the server 200 that the survival confirmation requesting node has stopped abnormally.

  More specifically, when this survival confirmation request node abnormality detection routine is executed, first, in step S601, the number of survival confirmation request nodes, that is, a plurality of survival registrations registered in the monitoring list of the own node device 1 are first obtained. The number of confirmation request nodes is set as M, the number i for specifying a noticeable survival confirmation request node is set as “1”, the number of retries for survival confirmation is set as R (specified value), and the survival confirmation is performed. The survival confirmation trial count r incremented by 1 each time is retried is set as “0”.

  Next, in step S602, it is determined whether or not the survival confirmation time t associated with the current survival confirmation request node X (i) has elapsed. If not, in step S603, the number i is incremented by 1. Subsequently, in step S604, it is determined whether or not the current value of the number i is greater than the number M of survival confirmation request nodes. If it is not larger, the process immediately returns to step S602. If it is larger, the current value of the number i is returned to “1” in step S605, and then the process returns to step S602.

  When the survival confirmation time t associated with the current survival confirmation request node X (i) has elapsed, the determination in step S602 is YES, and in step S606, the survival confirmation trial count r is returned to “0”. Subsequently, in step S607, a message for confirming the survival is transmitted to the current survival confirmation request node X (i). Thereafter, in step S608, it is determined whether or not there is a response from the current survival confirmation requesting node X (i) to the own node device 1. If there is a response, the process immediately proceeds to step S603. If there is no response, the survival confirmation trial count r is incremented by 1 in step S609.

  Thereafter, in step S610, it is determined whether or not the current value of the survival confirmation trial count r matches the retry count R. If they do not match, the process returns to step S607, but if they match, the process proceeds to step S610a. In step S610a, it is determined that the current survival confirmation request node X (i) does not survive on the network 8, that is, is abnormal. Thereafter, in step S611, an attempt is made to notify the server 200 that the current survival confirmation request node X (i) is abnormal.

  Subsequently, in step S612, it is determined whether or not the trial is successful. If successful, in step S619, the current node device 1 is checked from the monitoring list of the current node device 1 to stop continuing the life check for the current life check request node X (i). The survival confirmation request node X (i) is deleted.

  Thereafter, in step S620, for all monitoring nodes A (k) (k = 1,... N) registered in the survival confirmation request list of the current survival confirmation request node X (i), It is notified that the survival confirmation request node X (i) is abnormal. This is because the monitoring nodes A (k) stop performing the survival check for the current survival check request node X (i). Subsequently, in step S621, the survival confirmation requesting node number M is decremented by 1, and then the process returns to step S603.

  On the other hand, assuming that the attempt to notify the server 200 that the current survival confirmation request node X (i) is abnormal has failed this time, the determination in step S612 is NO, and in step S613, The number of monitoring modes, that is, the number of monitoring nodes A (j) registered in the survival confirmation request list of the current survival confirmation request node X (i) is set as N, and the number j is set as “1”. Is done.

  Subsequently, in step S614, among the monitoring nodes A registered in the survival confirmation request list of the current survival confirmation request node X (i), the current survival confirmation request node X ( An attempt is made to notify server 200 that i) is abnormal. That is, the current monitoring node A (j) is the aforementioned proxy monitoring node.

  Thereafter, in step S615, it is determined whether or not the attempt to notify the server 200 is successful. If successful, the process proceeds to step S619. If unsuccessful, the current value of number j is incremented by 1 in step S616. Subsequently, in step S617, the current value of number j is changed to the number of monitoring nodes. It is determined whether or not it is greater than N. If it is not larger, the process immediately proceeds to step S614. If it is larger, the current value of the number j is returned to “1” in step S618, and then the process returns to step S614.

  FIG. 17 is a sequence diagram showing a procedure performed when this survival confirmation request node abnormality detection routine is executed for the example shown in FIG.

  FIG. 18 conceptually shows a program executed by the server 200 in a flowchart. When this program is started, first, in step S651, from any monitoring node, any node device 1 (survival confirmation request node) does not survive on the network 8, that is, an abnormal node exists. Wait for notification.

  When the server 200 receives a notification indicating that an abnormal node exists, in step S652, the storage unit 204 is accessed to identify the installation position of the abnormal node on the network 8. In the storage unit 204, the installation positions of the plurality of node devices 1 participating in the network 8 are stored in advance in association with the node ID unique to each node device 1.

  Accordingly, in step S652, data for specifying the location of the abnormal node is acquired from the storage unit 204 by searching the storage unit 204 using the node ID unique to the current abnormal node as a keyword.

  Subsequently, in step S653, the installation position of the current abnormal node is specified based on the acquired data, and then, in step S654, the current abnormal node is present at the specified installation position. Information is displayed on the screen of the output device 212. Subsequently, in step S655, if the above-described client connected to the server 200 exists, information indicating that the current abnormal node exists at the specified installation position via the network 8 in the client. Is sent. Thereafter, the process returns to step S651.

  Returning to FIG. 9, in step S <b> 202, it is determined whether or not the own node apparatus 1 has received a survival confirmation request from any of the survival confirmation request nodes. If received, in step S203, in order for the node device 1 to create its own monitoring list, a monitoring list creation routine conceptually shown in the flowchart in FIG. 19 is executed.

  When this monitoring list creation routine is executed, first, in step S701, the number of survival confirmation request nodes, that is, the number of survival confirmation request nodes registered in the monitoring list of the own node device 1 is set to M.

  Next, in step S702, it is determined whether or not the survival confirmation requesting node number M is equal to or less than the upper limit value Mmax of the number of nodes that can be monitored by the own node device 1. If the number M of survival confirmation request nodes is less than or equal to the upper limit value Mmax, in step S703, an affirmative response is made to the survival confirmation request node that issued the survival confirmation request in step S310 in FIG. If M exceeds the upper limit Mmax, a negative response is made in step S706. When the execution of step S706 ends, the execution of the monitoring list creation routine also ends.

  If an affirmative response is made in step S703, then the number M of monitoring nodes is incremented by 1 in step S704. Thereafter, in step S705, the node ID, IP address, and survival confirmation time t of the added Mth survival confirmation requesting node X (M) are stored in the monitoring list of the own node device 1. This completes the execution of the monitoring list creation routine.

  Returning to FIG. 9, if the determination in step S202 is NO, step S204 is executed immediately after the execution of step S203 if YES. In this step S204, it is determined whether or not the own node device 1 has received a withdrawal message from the node that is the subject of survival confirmation (that is, the survival confirmation requesting node that is being monitored). When the own node apparatus 1 receives the withdrawal message, in step S205, in order to delete the survival confirmation requesting node to be withdrawn from the monitoring list, the withdrawal node conceptually represented in the flowchart in FIG. A delete routine is executed.

  When this withdrawal node deletion routine is executed, first, in step S801, the number of survival confirmation request nodes, that is, the number of survival confirmation request nodes registered in the monitoring list of the own node device 1 is set to M. The number i for identifying the notable survival confirmation request node is set to “1”.

  Next, in step S802, the existence confirmation requesting node that transmitted the withdrawal message (in the example shown in FIG. 3, for example, node X may be applicable. It is determined whether or not the node ID of the node “X” and the node ID of the current survival confirmation request node X (i) match each other. If they do not match, the number i is incremented by 1 in step S803.

  Thereafter, in step S804, it is determined whether or not the current value of the number i is greater than the number M of survival confirmation request nodes. If it is not larger, the process returns to step S802. If it is larger, the process proceeds to step S806. If the node ID of the node X that transmitted the withdrawal message matches the node ID of the current survival confirmation request node X (i), in step S805, the current survival confirmation request node X (i ) Is deleted, the process proceeds to step S806.

  In any case, in step S806, a response indicating that the withdrawal message has been received is sent to the node X that has transmitted the withdrawal message. This is the end of the execution of the leaving node deletion routine.

  Returning to FIG. 9, if the determination in step S204 is NO, immediately, if yes, step S206 is executed after step S205. In this step S206, another monitoring node that is not the original monitoring node is allowed to notify the server 200 that the survival confirmation request node is abnormal. In other words, the server 200 is notified by the proxy monitoring node. For the proxy notification, a proxy notification routine conceptually shown in the flowchart of FIG. 21 is executed.

  Briefly, when this proxy notification routine is executed, the own node device 1 has abnormally stopped the survival confirmation request node as a proxy monitoring node that proxy notification to the server 200 by other monitoring nodes. Is notified to the server 200. If the node device 1 succeeds in the trial, the node device 1 notifies the other monitoring nodes that should monitor the same survival confirmation request node that the survival confirmation request node has stopped abnormally.

  Specifically, when this proxy notification routine is executed, first, in step S901, the survival confirmation requesting node to be monitored is not alive from another monitoring node (that is, it is abnormal). ) Is determined. If notified, in step S902, the non-existent survival confirmation request node is deleted from the monitoring list of the node device 1, and then the process proceeds to step S903. On the other hand, when it is not notified from other monitoring nodes that the survival confirmation requesting node being monitored is not alive, the process immediately proceeds to step S903.

  In any case, in step S903, it is determined whether or not another monitoring node has requested that the local node device 1 try to notify the server 200 as a proxy monitoring node. When the proxy notification is not requested, the execution of this proxy notification routine is immediately terminated. On the other hand, when a proxy notification is requested, an attempt is made in step S904 to notify the server 200 of the existence of a survival confirmation request node that does not survive, that is, that a specific survival confirmation request node is abnormal. The

  Thereafter, in step S905, it is determined whether or not the trial is successful. If successful, in step S906, the survival confirmation requesting node that does not survive is deleted from the monitoring list of the own node device 1. Thereafter, the process proceeds to step S907. On the other hand, if the attempt to notify the server 200 of the existence of the survival confirmation request node that does not survive fails, the process immediately proceeds to step S907.

  In any case, in step S907, the success or failure of the notification to the server 200 is answered to the other monitoring node. This is the end of the execution of this proxy notification routine.

  Thereafter, in step S207 shown in FIG. 9, it is determined whether or not a shutdown request is issued from the user to the own node device 1. If not issued, the process returns to step S202. If issued, the process proceeds to step S208.

  In step S208, in order for the monitoring node to leave the network 8, a monitoring node withdrawal routine conceptually represented in the flowchart in FIG. 22 is executed.

  Briefly, when this monitoring node withdrawal routine is executed, if the monitoring node tries to leave the network 8 before the survival confirmation requesting node X, the monitoring node is the monitoring target of the monitoring node. A certain node X is notified of withdrawal from the network 8. The node X notified of the withdrawal of the monitoring node deletes the monitoring node from the survival confirmation request list by executing step S104 shown in FIG. When a certain monitoring node is deleted from the survival confirmation request list, another node device 1 is selected as a new monitoring node instead.

  Specifically, when this monitoring node withdrawal routine is executed, first, in step S1001, the number of survival confirmation request nodes, that is, the number of survival confirmation request nodes registered in the monitoring list of the own node device 1 Is set to M, and the number i for identifying the survival confirmation request node to be noted is set to “1”.

  Next, in step S1002, it is determined whether or not the current value of the number i is equal to or less than the number M of survival confirmation request nodes. If so, in step S1003, a withdrawal message indicating that the node device 1 is withdrawing from the network 8 is transmitted to the current survival confirmation request node X (i). In step S1004, a response indicating that the withdrawal message has been received is awaited from the current survival confirmation request node X (i). If received, the current value of number i is incremented by 1 in step S1005. Thereafter, the process returns to step S1002.

  If the current value of the number i is larger than the survival confirmation requesting node number M, the determination in step S1002 is NO and the process proceeds to step S1006. In step S1006, the node withdrawal notification routine shown in FIG. 14 is executed, so that other monitoring nodes are notified that the own node device 1 as the monitoring node is leaving the network 8. This is the end of the execution of this monitoring node withdrawal routine. Thereby, the execution of step S3 shown in FIG. 9 ends.

  FIG. 23 is a sequence diagram showing a procedure performed when this monitoring node withdrawal routine is executed for the example shown in FIG.

  As is clear from the above description, in the present embodiment, for the sake of convenience of explanation, the part that executes step S101 shown in FIG. 10 in each node device 1 is the “monitoring node selection means” in the section (1). The part that executes step S610a shown in FIG. 16 constitutes an example of “survival determination means” in the same paragraph, and step S611 shown in FIG. 16 constitutes an example of “notification means” in the same paragraph. It is possible to think that

  Furthermore, in this embodiment, for convenience of explanation, the storage unit 204 of the server 200 constitutes an example of the “storage unit” in the item (2), and the part of the server 200 that executes the program shown in FIG. It can be considered that it constitutes an example of the “position specifying means” in the same section.

  Furthermore, in the present embodiment, for the sake of convenience of explanation, the part that executes step S607 shown in FIG. 16 in each node device 1 constitutes an example of the “monitoring means” in the section (3), and is shown in FIG. The portions that execute steps S608, S609, S610, and S610a shown constitute an example of the “survival determination means” in the same paragraph, and the portions that execute step S611 shown in FIG. It is possible to think that it constitutes.

  Further, in the present embodiment, for the sake of convenience of explanation, the portion of each node device 1 that executes steps S602 to S607, S609, and S610 shown in FIG. 16 is the “timed monitoring means” in the section (4). It can be considered as an example.

  Further, in the present embodiment, for the sake of convenience of explanation, a portion of each node device 1 that executes step S607 shown in FIG. 16 constitutes an example of “transmission means” in the above section (5), and is shown in FIG. It can be considered that the part that executes Step S610a shown constitutes an example of the “determination means” in the same section.

  Further, in the present embodiment, for convenience of explanation, a part of the storage unit 12 of each node device 1 that stores the survival confirmation request list constitutes an example of the “monitoring node storage unit” in the above section (6). 16 can be considered to constitute an example of “another monitoring node notification unit” in the same section.

  Furthermore, in the present embodiment, for convenience of explanation, it is assumed that a part of each node device 1 that executes step S208 shown in FIG. 9 constitutes an example of the “withdrawal notification unit” in the above section (7). It is possible to think.

  Further, in the present embodiment, for convenience of explanation, the portion of the storage unit 12 of each node device 1 that stores the monitoring list constitutes an example of the “survival confirmation request node storage unit” in the section (8). Of the respective node devices 1, the part that executes step S702 shown in FIG. 19 constitutes an example of the “node number determination means” in the same paragraph, and the part that executes steps S703 and S706 shown in FIG. It can be considered that it constitutes an example of “request acceptance / rejection means” in the section.

  Further, in the present embodiment, for convenience of explanation, a part of the storage unit 12 of each node device 1 that stores the survival confirmation request list constitutes an example of the “monitoring node storage unit” in the above section (9). It can be considered that the part that executes steps S613 to S618 shown in FIG. 16 constitutes an example of the “proxy notification means” in the same section.

  Further, in the present embodiment, for the sake of convenience of explanation, the part of step S101 shown in FIG. 8 in each node device 1 constitutes an example of the “monitoring node selection means” in the section (10). It can be considered that the part that executes step S310 shown in FIG. 10 constitutes an example of the “survival confirmation requesting unit” in the same section.

  Furthermore, in the present embodiment, for convenience of explanation, the portion of each node device 1 that executes step S402 shown in FIG. 12 constitutes an example of “monitoring node determination means” in the above-mentioned item (11). It can be considered that the part that executes step S406 shown in the drawing constitutes an example of “monitoring node changing means” in the same section.

  Furthermore, in the present embodiment, for convenience of explanation, a part of each node device 1 that executes step S402 shown in FIG. 12 constitutes an example of the “non-survival confirmation determination unit” in the above (12). It is possible to think that

  Furthermore, in the present embodiment, for the convenience of explanation, the portion that executes steps S452 to S457 shown in FIG. 13 in each node device 1 constitutes an example of the “monitoring node changing means” in the section (13). It is possible to think that

  Furthermore, in this embodiment, for convenience of explanation, it can be considered that the main program shown in FIG. 6 constitutes an example of the “program” according to the item (14).

  As described above, some of the embodiments of the present invention have been described in detail with reference to the drawings. However, these are exemplifications, and are based on the knowledge of those skilled in the art including the aspects described in the section of [Disclosure of the Invention]. The present invention can be implemented in other forms with various modifications and improvements.

1 is a system diagram conceptually showing a physical configuration and a logical configuration of a network in an information communication system according to an embodiment of the present invention. FIG. 2 is a block diagram conceptually illustrating an example of a schematic hardware configuration of each node device illustrated in FIG. 1. It is a figure which shows an example of the routing table produced in order for each node apparatus to participate in a network in the information communication system shown in FIG. FIG. 3 is a diagram for explaining a state in which an abnormality of a node X is detected by another node A using a routing table and notified to a server 200 in the information communication system illustrated in FIG. 1. FIG. 5 is a block diagram conceptually showing the configuration of a server shown in FIG. 4. 2 is a flowchart conceptually showing a main program executed by a computer of each node device shown in FIG. 1. FIG. 7A is a diagram for explaining an example of a survival confirmation request list used by each node device shown in FIG. 1, and FIG. 7B is a monitor used by each node device shown in FIG. It is a figure for demonstrating an example of a list. 7 is a flowchart conceptually showing details of step S2 shown in FIG. 6 as a survival confirmation request routine. 7 is a flowchart conceptually showing details of step S3 shown in FIG. 6 as a monitoring routine. 9 is a flowchart conceptually showing details of step S101 shown in FIG. 8 as a survival confirmation request list creation routine. It is a sequence diagram for demonstrating one execution example of the survival confirmation request list creation routine shown in FIG. 9 is a flowchart conceptually showing details of step S102 shown in FIG. 8 as a monitoring node abnormality detection routine. 9 is a flowchart conceptually showing details of step S104 shown in FIG. 8 as a monitoring node deletion routine. 9 is a flowchart conceptually showing details of step S106 shown in FIG. 8 as a node withdrawal notification routine. FIG. 15 is a sequence diagram for explaining an example of execution of a node withdrawal notification routine shown in FIG. 14. 10 is a flowchart conceptually showing details of step S201 shown in FIG. 9 as a survival confirmation request node abnormality detection routine. FIG. 17 is a sequence diagram for explaining an example of execution of a survival confirmation request node abnormality detection routine shown in FIG. 16. 6 is a flowchart conceptually showing a program executed by the computer of the server shown in FIG. 10 is a flowchart conceptually showing details of step S203 shown in FIG. 9 as a monitoring list creation routine. 10 is a flowchart conceptually showing details of step S205 shown in FIG. 9 as a withdrawal node deletion routine. 10 is a flowchart conceptually showing details of step S206 shown in FIG. 9 as a proxy notification routine. 10 is a flowchart conceptually showing details of step S208 shown in FIG. 9 as a monitoring node withdrawal routine. FIG. 23 is a sequence diagram for explaining an example of execution of a monitoring node withdrawal routine shown in FIG. 22.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Node apparatus 8 Network 9 Overlay network 11 Control part 12 Memory | storage part 13 Buffer memory 14 Decoder part 15 Image | video processing part 16 Display part 17 Audio | voice processing part 18 Speaker 20 Communication part 21 Input part 22 Bus 200 Server S Information communication system

Claims (14)

A peer-to-peer communication system comprising a plurality of node devices connected to each other via a network in a state where communication can be performed in a peer-to-peer manner using a routing table, and a server connected to the node devices via the network,
Each node device has a function as a survival confirmation requesting node for requesting other node devices to monitor whether or not the own node device is alive on the network, and whether or not the other node device is alive on the network. Function as a monitoring node to monitor,
Each node device
Monitoring node selection that, when functioning as the existence confirmation request node, selects at least one of the other node devices stored in the routing table for the own node device as a monitoring node that should monitor the own node device Including means,
Each node device
When functioning as the monitoring node, survival determination means for determining whether other node devices as the survival confirmation request node survive on the network,
A peer-to-peer notifying means for notifying the server that the survival confirmation requesting node does not survive on the network when the survival determining means determines that the survival confirmation requesting node does not survive on the network. Communications system. The server
Storage means for storing in advance the installation positions of a plurality of node devices participating in the network in association with node IDs;
When each node device functioning as the monitoring node is notified that the survival confirmation request node does not survive on the network, the access to the storage unit is performed to access the survival confirmation request node on the network. The peer-to-peer communication system according to claim 1, further comprising: a position specifying unit that specifies an installation position. A node device connected to a plurality of other node devices via a network and capable of communicating in a peer-to-peer manner using a routing table, and connected to a server via the network;
Monitoring means for monitoring whether or not the survival confirmation requesting node that requested the node device to monitor whether or not to survive on the network survives on the network;
Based on the monitoring result by the monitoring means, a survival determination means for determining whether or not the survival confirmation request node is alive on the network,
A node that includes notification means for notifying the server that the survival confirmation request node does not survive on the network when it is determined by the survival determination means that the survival confirmation request node does not survive on the network. apparatus.   The node device according to claim 3, wherein the monitoring unit includes a timed monitoring unit that monitors the survival confirmation requesting node when a designated time arrives. The monitoring means includes a transmission means for transmitting a specific request to the survival confirmation request node,
The survival determination unit includes a determination unit that determines that the survival confirmation request node does not survive on the network when the survival confirmation request node does not return a response to the node device in response to the transmission of the request. The node device according to claim 3 or 4. Including monitoring node storage means for storing other monitoring nodes that monitor the same survival confirmation requesting node;
The monitoring node storage means that the notification means determines that the survival confirmation request node does not survive on the network when the survival judgment means determines that the survival confirmation request node does not survive on the network. 6. The node device according to claim 3, further comprising other monitoring node notification means for notifying other monitoring nodes stored in the node.   The node device according to any one of claims 3 to 6, further comprising withdrawal notification means for notifying the survival confirmation requesting node of withdrawal when leaving the network. A survival confirmation request node storage unit for storing the survival confirmation request node to be monitored;
A node number determination means for determining whether or not the number of the survival confirmation request nodes stored in the survival confirmation request node storage means exceeds a predetermined value when a survival confirmation request is received;
When it is determined by the node number determination means that the number of the survival confirmation request nodes is equal to or less than the predetermined value, the request for survival confirmation is accepted, and when it is determined that the number exceeds the predetermined value The node apparatus according to claim 3, further comprising: a request acceptance / rejection unit that rejects the request for existence confirmation. Including monitoring node storage means for storing other monitoring nodes that monitor the same survival confirmation requesting node;
When the communication to the server fails, the notification means notifies the other monitoring nodes stored in the monitoring node storage means that the survival confirmation request node does not survive on the network. 9. The node device according to claim 3, further comprising proxy notification means for requesting to do so. A node device connected to a plurality of other node devices via a network and capable of communicating in a peer-to-peer manner using a routing table, and connected to a server via the network;
Monitoring node selection means for selecting at least one of the other node devices stored in the routing table for the own node device as a monitoring node to be monitored;
A node device comprising: a survival confirmation requesting unit that requests the monitoring node selected by the monitoring node selecting unit to monitor whether or not the own node device is alive on the network. Monitoring node determination means for determining whether or not the monitoring node has confirmed the existence of the own node device;
A monitoring node changing unit for selecting a node device different from the monitoring node as a new monitoring node when the monitoring node determining unit determines that the monitoring node has not confirmed the existence of the own node device; The node device according to claim 10, comprising:   The monitoring node determination unit includes a non-survival determination unit that determines that the monitoring node has not confirmed the existence of the own node device when a specific request is not received from the monitoring node at a specified time. The node device described in 1.   13. The node device according to claim 11 or 12, further comprising monitoring node changing means for selecting a node device different from the monitoring node as a new monitoring node when the monitoring node receives a message for leaving the network.   14. A program executed to cause a computer to function as each means of the node device according to claim 3.

Images