JP2012146113A - Information notification node, information distribution system, information notification method, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce a processing load on a device (node) for notifying of an event.SOLUTION: An information notification node comprises: a subscription table holding unit that receives and holds subscription of information; an event control unit that determines a load of notification based on the subscription, and determines whether to delegate the notification based on the load; a load distribution management table holding unit that holds information on a transmission source of the subscription and a notification destination to be notified of the information; and a load distribution control unit that, when the event control unit has determined to delegate it, determines a range of a notification destination to which the notification is to be delegated based on information in the load distribution management table holding unit, and transmits, to another node, a request of proxy notification of the information with respect to a notification destination to which it is to be delegated.

Description

  The present invention relates to information distribution or notification, and more particularly to information distribution or notification load.

  An information processing apparatus connected to the network transmits or receives information via the network. One information processing system that transmits and receives information via such a network is an information distribution system.

  Information distribution systems include systems that distribute (notify) information including events to one or a plurality of notification destinations. Information distributed by such an information distribution system is, for example, an event (event) in which an RFID (Radio Frequency IDentification) reader detects an RFID attached to an article, or a proximity sensor detects the approach of the article. Includes events.

  Information processing apparatuses (hereinafter referred to as nodes) constituting an information distribution system can constitute networks of various connection forms. A pub / sub (publisher / subscriber) network is one of the network connection forms constituting such an information distribution system (see, for example, Non-Patent Document 1).

  An information distribution system using a general pub / sub network will be described with reference to the drawings.

  FIG. 22 is a diagram illustrating an example of the information distribution system 9 including the pub / sub network 90.

  The information distribution system 9 includes a subscriber 20, a publisher 30, and a pub / sub network 90.

  A subscriber (subscriber, hereinafter, also referred to as sub) 20 subscribes a condition of an event to receive distribution (notification) based on an instruction from a person who wants to receive the event (such as a user) or a device. subscription (reception registration) to the pub / sub network 90 (subscribe). Thus, the subscription includes information necessary for the pub / sub network 90 to notify the subscriber 20 of the event.

  A publisher (hereinafter also referred to as “pub”) 30 receives an event from a sensor (not shown) or the like, and inputs an event or information indicating the event (collectively referred to as an event) to the pub / sub network 90 ( (Also called publish, publish, registration).

  The pub / sub network 90 compares the event received from the publisher 30 with the event condition included in the registered subscription. When the event conditions of the event and the registered subscription match, the pub / sub network 90 notifies (notify, distribute) the event to the subscriber 20 who registered the matched subscription.

  The general pub / sub network 90 operating in this way is a network in which information processing devices (nodes) such as servers are connected to each other, and transfers information (subscriptions and events) based on a predetermined method. In this transfer, the node searches for the information transfer destination. Therefore, the general pub / sub network has a problem that it takes time to search for an information transfer destination when the network is large or complicated.

  Therefore, there is a network using a distributed hash table (DHT) as a network with improved search (see, for example, Non-Patent Document 2).

  The distributed hash table is a management method in which a node corresponding to a hash value obtained by applying a hash function to information manages or processes the information. Since the hash value has a fixed length, the distributed hash table does not increase the search load even when the network becomes large.

  Information transfer of the pub / sub network 90 using the distributed hash table will be described with reference to the drawings.

  FIG. 23 is a diagram showing an example of transfer in registration of a subscription of the pub / sub network 90 using the distributed hash table.

  In FIG. 23, nodes constituting the pub / sub network 90 are indicated by small circles. Each node is connected via a network. For convenience of explanation, FIG. 23 schematically shows a circular connection.

  Each node constituting the network using the distributed hash table has a key (key) for managing the node. The key may be a value of a node identifier (ID). Therefore, in FIG. 23, the key of each node is shown as a value of the identifier of the node using a binary number in a small circle indicating the node. In FIG. 23, for convenience of explanation, the key value of each node is shown as one, but a node using a distributed hash table may include a plurality of key values.

  When the subscriber (sub) 20 registers the subscription in the pub / sub network 90, the node receiving the subscription obtains a key by applying a hash function to the condition included in the received subscription. Then, the node receiving the subscription transfers the subscription to the node corresponding to the key based on the key. Here, the condition for applying the hash function is, for example, an event for which notification is requested by subscription.

  FIG. 23 shows, as an example, the transfer when the keys of the transfer destinations of the five subscriptions registered by the subscriber are all ID = 1000. Each node that receives the subscription transfers the subscription to the node with ID = 1000 based on the key obtained from the subscription. However, a general pub / sub network is a network in which a plurality of networks are connected. For this reason, the nodes constituting the pub / sub network may not be connected to the same network as the transfer destination node. In such a case, the node transfers the information to be transferred to the transfer destination node via a plurality of nodes constituting the pub / sub network. A node has information of a node through which information is transferred, that is, route information, as a routing table, and refers to the routing table so that information can be transmitted to a predetermined node so that the node reaches the transfer destination node. Send.

  For example, in FIG. 23, the node with ID = 0001 cannot directly transfer the subscription to the node with ID = 1000. Therefore, the node with ID = 0001 transfers the subscription to the node with ID = 0101. Since the node with ID = 0101 cannot be directly transferred to the node with ID = 1000, the subscription is transferred to the node with ID = 0111. Since the node with ID = 0111 can be transferred to the node with ID = 1000, the subscription is transferred to the node with ID = 1000. As described above, the nodes constituting the pub / sub network transfer information using the routing table.

  The node with ID = 1000 that has received the subscription holds the received subscription. Note that the node with ID = 1000 applies a hash function to the subscription condition, and determines that the subscription is managed by the own node based on the obtained hash value being its own key (ID). it can.

  FIG. 24 is a diagram illustrating an example of event distribution (notification) of the pub / sub network 90 using the distributed hash table.

  FIG. 24 shows an example in which the key (node ID) obtained from the event is ID = 1000. Upon receiving the event from the publisher (pub), the node with ID = 0101 determines from the hash value obtained by applying the hash function to the event that the event transfer destination node is the node with ID = 1000, and Forward. Since the node with ID = 0101 cannot transfer information directly to the node with ID = 1000 as already described, the event is transferred to the node with ID = 1000 via the node with ID = 0111.

  The node having ID = 1000 that received the event notifies the subscriber (sub) 20 of the event (notify, distribute) based on the registered subscription described with reference to FIG.

  Note that, as in the node with ID = 1000 shown in FIGS. 23 and 24, a node where an event meets (collects) a subscriber is called a rendezvous node.

  As described above, even if the network increases based on the distributed hash table, each node can set the table to be searched within a predetermined range.

  However, there are many subscribers who want to be notified of special events such as events related to celebrities, stock price fluctuation events that are attracting attention in the stock market, and disaster events. Therefore, a rendezvous node for such an event is a heavy load for event notification processing. As a result, even if the rendezvous node adopts a distributed hash table, there is a problem that it takes time to notify an event with many notification destinations, that is, an event with a large load, and the notification is delayed.

  In response to such an increase in load, a system using a general network uses load distribution as a device load reduction.

  For example, a system using tunneling changes the allocation of tunneled communication paths based on the operating state of a device (node) (see, for example, Patent Document 1). However, the system described in Patent Document 1 changes the communication path, and there is a problem that it is impossible to reduce loads other than the communication path in the node where the load is increased.

  Further, as a system for notifying information to a plurality of transmission destinations, there is a system in which time is set for a notification destination and information is notified by dividing the time. (For example, see Patent Document 2). However, since a time difference cannot be set as a notification destination for events such as stock price fluctuations or disasters, the system described in Patent Document 2 has a problem that it cannot be used for such events.

  Thus, there is a system that moves a program to be processed to another device in order to reduce processing in the device (see, for example, Patent Document 3). In addition, there is a system in which data necessary for processing is moved only by the processing while the data necessary for the processing is left in order to reduce the time for the handover processing (see, for example, Patent Document 4).

JP 2005-228036 A JP2008-198047 JP 2005-004674 A JP 2003-248669 A

F Cao, et al., “Efficient Event Routing in Content-based Publish-Subscribe Service Networks”, IEEE INFOCOM, 2004 Ion Stoica, et al., “Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications” ACM SIGCOMM, 2001

  However, the systems described in Patent Literature 3 and Patent Literature 4 change the device to be processed, and the amount of processing load in the device that has taken over the event notification processing is the same as that of the delivered device. It is. The systems described in Patent Literature 3 and Patent Literature 4 have a problem in that it is not possible to reduce the processing load for notifying an event in a device that takes over event notification, that is, an event notification device.

  An object of the present invention is to solve the above problems and provide a reduction in the load on a device (node) that notifies information (information including an event).

  The information notification node of the present invention is configured to determine a load of notification of the information based on a subscription table holding unit that receives and holds reception registration (subscription) of information including an event, and the reception registration held, An event control unit that determines whether or not to delegate the notification based on a load; a load distribution management table holding unit that holds information on a transmission source of the reception registration and a notification destination that notifies the information; and the event control If it is determined that the information is to be delegated, a range of notification destinations to which the notification of the information is delegated is determined based on information held by the load distribution management table holding unit, and the notification destination of the information is delegated for the notification destination to be delegated A load distribution control unit that sends a request to the first node and requests the event control unit to notify the information about a notification destination that is not delegated.

  The information notification method of the present invention receives and holds an information reception registration, determines the information notification load based on the held reception registration, and determines whether to delegate the notification based on the load And holding the information of the transmission source of the reception registration and the notification destination for notifying the information, and when determining to delegate, based on the information of the transmission source of the reception registration and the notification destination for notifying the information The range of notification destinations to which information notification is delegated is determined, a request for proxying the information notification is sent to the first node for the notification destination to be delegated, and the information is notified to the notification destination that is not to be delegated.

  The program of the present invention receives and holds information reception registration, determines the information notification load based on the held reception registration, and determines whether to delegate the notification based on the load A process of holding the information of the transmission source of the reception registration and a notification destination of notifying the information, and a notification destination of notifying the information of the transmission source of the reception registration and the information when it is determined to delegate Based on the above, the scope of the notification destination to which the notification of the information is delegated is determined, a request for proxying the notification of the information is sent to the first node for the notification destination to be delegated, and the information for the notification destination not to be delegated Causes the computer to execute notification processing.

  In the information distribution system of the present invention, the information notification node of the present invention includes a subscription table holding unit that receives and holds reception registration (subscription) of information including an event, and the information notification node of the information based on the received reception registration. A load distribution management that holds an event control unit that determines a notification load, determines whether to delegate the notification based on the load, and information on a transmission source of the reception registration and a notification destination that notifies the information When the table holding unit and the event control unit determine to delegate, the range of the notification destination to which the information notification is delegated is determined based on the information held by the load distribution management table holding unit, and the notification destination to delegate Sends a proxy request for notification of the information to the first node, and requests notification of the information to the event control unit for notification destinations that are not delegated Including that a load distribution control unit and the information notification node comprising a subscriber to register to receive registration information, and a publisher to issue the information.

  ADVANTAGE OF THE INVENTION According to this invention, the processing load of the apparatus (node) which notifies (notify) information (information including an event) can be reduced.

It is a block diagram which shows an example of a structure of the information notification node which concerns on 1st Embodiment in this invention. It is a block diagram which shows an example of a structure of the information delivery system which concerns on 1st Embodiment. It is a flowchart which shows an example of the reception operation | movement of the subscription of the information notification node which concerns on 1st Embodiment. It is a figure which shows an example of the transfer of the subscription of the information delivery system which concerns on 1st Embodiment. It is a figure which shows an example of the load distribution management table which concerns on 1st Embodiment. It is a figure which shows another example of the load distribution management table which concerns on 1st Embodiment. It is a figure which shows an example of the subscription table which concerns on 1st Embodiment. It is a flowchart which shows an example of operation | movement of the event control part which concerns on 1st Embodiment. It is a flowchart which shows an example of operation | movement of the load distribution control part which concerns on 1st Embodiment. It is a figure which shows an example of the load distribution management table which concerns on 1st Embodiment. It is a flowchart which shows an example of operation | movement of the information notification node which concerns on 1st Embodiment. It is a figure which shows an example of the load distribution management table which concerns on 1st Embodiment.

It is a flowchart which shows an example of operation | movement of the information notification node which concerns on 1st Embodiment. It is a flowchart which shows an example of operation | movement of the load distribution control part which concerns on 1st Embodiment. It is a flowchart which shows an example of operation | movement of the information notification node which concerns on 1st Embodiment. It is a figure which shows an example of the notification of the event of the pub / sub network which concerns on 1st Embodiment. It is a flowchart which shows an example of operation | movement of the event control part which concerns on 1st Embodiment. It is a flowchart which shows an example of operation | movement of the load distribution control part which concerns on 1st Embodiment. It is a flowchart which shows an example of operation | movement of the load distribution control part which concerns on 1st Embodiment. It is a block diagram which shows an example of another structure of the information notification node which concerns on 1st Embodiment. It is a figure which shows an example of a structure of the information notification node which concerns on 2nd Embodiment. It is a figure which shows an example of a general information delivery system. It is a figure which shows an example of the transfer of the subscription in a general pub / sub network. It is a figure which shows an example of the notification of the event in a general pub / sub network.

  Next, embodiments of the present invention will be described with reference to the drawings.

  First, terms in the description of the present embodiment will be organized.

  An “event” is information generated based on detection of a sensor or human operation. An event is transmitted (also referred to as “publish”, “publish”, “registered”, or “input”) to a network by a device that has received information that is the basis of the event, such as sensor detection. A device that transmits an event to a network is called a publisher or pub. An event transmitted by a publisher is received by a network, specifically, a device constituting the network. The event according to the present embodiment is referred to as an event including the event and information generated or generated based on the event.

  An event may contain a variety of information. An event (also referred to as information including an event) according to the present embodiment includes an event ID (Identification) and event information as an example.

  The event ID is an identifier for uniquely identifying the event. For example, the event ID is a hash value obtained by applying a hash function to RFID (Radio Frequency IDentification) detected by the sensor that is the basis of the event. As will be described later, an information notification node including a key corresponding to the event ID as an identifier notifies the event (also referred to as notification or distribution). That is, the event ID may be used for identifying an event and determining an information notification node that notifies the event.

  The event condition is information including an event related information, for example, a condition (time, place, cause, etc.) in which the event has occurred.

  The information notification node according to the present embodiment is described using an event, but the information handled by the information notification node according to the present embodiment is not limited to the event. Information handled by the information notification node according to the present embodiment may be, for example, database information or expert system information.

  “Subscription” is information (reception registration) to register (subscribe) information (information including an event) to be notified (distributed) in the network. A device for registering a subscription (reception registration) is referred to as a subscriber or a sub. The subscription registered in the network by the subscriber is transferred to the information notification node that notifies the event, as will be described later.

  A subscription may contain some information. As an example, the subscription according to the present embodiment includes a subscription condition, a subscriber ID, a notification destination ID, and a relay node ID.

  The subscription condition is information including a condition regarding an event for notifying a subscription. It should be noted that the conditions related to the event included in the subscription condition include a case where it is sufficient to match a part of the event. For example, if the subscription condition includes “location = Tokyo” as a condition regarding the event, an event such as “location = Tokyo, incident = fire” or “location = Tokyo, incident = earthquake” matches the subscription condition. It may be an event. The subscription condition includes information for transferring the subscription to the information notification node that notifies the event, for example, information corresponding to the event ID.

  The subscriber ID is information (identifier) indicating the subscriber who registered the subscription in the network.

  The notification destination ID is information (identifier) indicating a device that notifies an event based on a registered subscription. One or a plurality of notification destination devices may be indicated by the notification destination ID. The notification destination device may be a subscriber. That is, the subscriber who registered the subscription may be the event notification (distribution) destination. For convenience of explanation, it is assumed that the event notification destination apparatus according to the present embodiment is a subscriber who has registered a subscription. Therefore, in the subscription according to the present embodiment, the notification destination ID may be substituted with the subscriber ID.

  The transit node ID is an identifier of the node that relayed the subscription. When each node receives the subscription, each node sets the identifier of the sender node as the transit node ID. However, the transit node ID may be set by the transmission source node when transmitting the subscription. Further, the transit node ID according to the present embodiment may include all the identifiers of the transited nodes, may include the identifiers of a predetermined range or number of nodes, or may include the identifier of the immediately preceding node. .

  The “pub / sub network” is a network in which a subscriber registers a subscription and a publisher sends an event. In addition, the devices constituting the pub / sub network transfer the subscription and the event to the information notification node in charge of event notification. Further, the pub / sub network transfers a message created by the information notification node. Note that the pub / sub network includes the routing information (routing table) of the device to which information is transferred, and transfers information using the routing table, as in a general network. That is, the nodes constituting the pub / sub network transfer subscriptions, events, and messages to predetermined devices based on the routing table.

  A “node” is a device that forms a pub / sub network by connecting to each other via a communication path. The node searches for a transfer destination of information based on the routing table. The node may use various schemes for this search. However, in the present embodiment, for the convenience of explanation, description will be made using a distributed hash table (DHT). Therefore, each node includes an identifier (node ID) as a key allocated for DHT. As already described, the node ID according to the present embodiment is a key corresponding to the event ID. That is, the node ID according to the present embodiment will be described as a hash value of the event ID.

  Note that the node according to the present embodiment may hold not only one value but also a plurality of values as a node ID as a key. However, in this embodiment, it is assumed that each node has a value of one node ID (key) for convenience of explanation.

  Further, the node includes a routing table that holds the information indicating the information transfer path (for example, transfer destination and / or transfer source), which has already been described. In the present embodiment, the routing table will be described as a routine table based on logical connection. However, the node according to the present embodiment may include a routing table based on physical connection.

  The “information notification node” is configured to send information (information including an event) to a notification destination (notification destination ID) specified by the subscription based on the subscription (reception registration) and information (information including an event). It is a node to notify (deliver). The pub / sub network according to the embodiment of the present invention includes an information notification node at least partially. Note that a node that uses a subscription (reception registration) and information (information including an event) like an information notification node is referred to as a rendezvous node.

  As described later, the information notification node according to the present embodiment delegates notification of information (information including an event) to another information notification node according to the state of the load. Further, the information notification node receives a request from another information notification node and performs notification of information. The information notification node according to the present embodiment transmits and receives messages for delegation and substitution of such information notification.

(First embodiment)
Next, the information notification node 10 according to the first exemplary embodiment of the present invention will be described with reference to the drawings.

  First, the configuration of the information notification node 10 according to the present embodiment will be described.

  FIG. 1 is a block diagram illustrating an example of the configuration of the information notification node 10 according to the first embodiment.

  The information notification node 10 transmits / receives information (for example, a subscription or an event) to / from other nodes, subscribers (sub), and publishers (pub) that configure an information distribution system (not shown) via the network.

  Therefore, the information notification node 10 includes an information transfer unit 110, a routing unit 120, a routing table holding unit 130, an event control unit 140, a subscription table holding unit 150, a load distribution control unit 160, and a load distribution management. Table holding unit 170.

  The information transfer unit 110 relays transmission / reception of information between each unit of the information notification node 10 and other devices (other nodes, subscribers, or publishers) connected to the network via the network.

  The routing unit 120 searches for information transfer destinations (look-up) based on the routing table 131 held by the routing table holding unit 130, and transfers information via the information transfer unit 110.

  The routing table holding unit 130 holds a routing table 131 used by the routing unit 120 to search for information transfer destinations.

  Note that the routing unit 120 and the routing table holding unit 130 may hold and update the routing table 131 based on a routing protocol used by a device constituting a general network. Is omitted. In the routing table 131, the number of passing nodes (devices) is referred to as the hop number.

  The event control unit 140 creates and updates the subscription table 151 held by the subscription table holding unit 150 based on the received subscription. Further, the event control unit 140 notifies an event notification destination (subscriber in the present embodiment) of an event received from the publisher or another node based on the subscription table 151. Details of the operation of the event control unit 140 will be described later. Note that a subscription that is stored in the subscription table 151 in its own node and is a target of event notification processing is referred to as a “managed subscription”. Also, an event that is a target of a managed subscription is referred to as a “managed event”. Furthermore, the information notification node 10 that notifies the management target event is referred to as an “information manager” information management node. That is, the information notification node 10 in charge of management holds the managed subscription in the subscription table 151 and notifies the managed event.

  The subscription table holding unit 150 holds a subscription table 151 including managed subscriptions used by the event control unit 140. A set of information stored in the subscription table 151 according to the present embodiment is referred to as a record.

  The load distribution control unit 160 creates and updates the load distribution management table 171 held by the load distribution management table holding unit 170. Further, the load distribution control unit 160 controls the load distribution process of the information notification node 10 based on the load distribution management table 171. The detailed operation of the load distribution control unit 160 will also be described later.

  The load distribution management table holding unit 170 holds a load distribution management table 171 used by the load distribution control unit 160. Note that the information stored in the load distribution management table 171 is also referred to as a record.

  Next, the configuration of the information distribution system 1 including the information notification node 10 according to the present embodiment will be described.

  FIG. 2 is a block diagram illustrating an example of the information distribution system 1 including the information notification node 10.

  The information distribution system 1 includes a pub / sub network 40 including an information notification node 10, a subscriber 20, and a publisher 30. In FIG. 2, the subscriber 20 and the publisher 30 are shown as one for convenience of explanation, but the information distribution system 1 according to the present embodiment includes not only one subscriber 20 and the publisher 30, Two or more may be sufficient.

  In the following description, in order to clarify the positional relationship of each node on the route, an information notification node serving as a rendezvous node is referred to as a “target node”. A node that forwards the subscription to the target node, that is, an information notification node that has been previously registered in the routing table 131 is referred to as a “previous node”. Further, a node that transfers a subscription to the previous node, that is, an information notification node registered before the previous node in the routing table 131 is referred to as a “previous node”. Note that “previous” according to the present embodiment is not limited to the previous one, and may be two or more previous. However, in FIG. 2, “Previous” is shown as one previous for convenience of description. Therefore, in FIG. 2, the information notification node 10 is the target node, the information notification node 11 is the previous node, and the information notification node 12 is the previous node.

  The information notification node 10 searches for the previous node based on the routing table 131. However, the information notification node 10 may search for the “previous node” using the transit node ID included in the subscription.

  Note that the information notification nodes according to the present embodiment are not limited to the same configuration, but for the convenience of description, in the following description, the information notification nodes have the same configuration. Therefore, the numbers given to the configuration of each information notification node refer to the numbers in FIG. The description common to the information notification node will be described using the information notification node 10.

  In FIG. 2, a subscriber 20 subscribes to a pub / sub network 40 for a subscription. The information notification nodes 10 to 12 search for the key obtained from the subscription in the routing table 131 and transfer the key to the information notification node (for example, the information notification node 10 shown in FIG. 2) having the obtained key. The information notification node that manages the subscription (for example, the information notification node 10 shown in FIG. 2) holds the received subscription in the subscription table 151. As already described, the node ID of the subscription is sequentially added at the time of transfer.

  Next, the publisher 30 inputs (publishes) the event to the pub / sub network 40. The event is also transferred to the information notification node 10 based on the routing table 131.

  The information notification node 10 that has received the event notifies the notification destination (subscriber 20 in the present embodiment) specified by the subscription (notify) of the event.

  Furthermore, the information notification node 10 transmits a message for requesting proxy for event notification to the information notification node 11 which is the previous node as necessary.

  The information notification node 11 that has received the notification request message notification notifies the notification destination (subscriber) of the event. Furthermore, if necessary, the information notification node 11 transmits a message for requesting proxy for event notification to the information notification node 12 which is the previous node.

  Next, details of the operation of the information notification node 10 will be described with reference to the drawings.

  First, the operation when the subscription of the information notification node 10 is received will be described.

  FIG. 3 is a flowchart showing an example of an operation when the information notification node 10 receives a subscription.

  The information transfer unit 110 of the information notification node 10 that has received the subscription from the subscriber 20 or another node sends the subscription to the routing unit 120 (step 1001).

  The routing unit 120 that has received the subscription sets the identifier (ID) of the transmission source information notification node in the transit node ID of the subscription, and then sends the subscription to the load distribution control unit 160. The load distribution control unit 160 that has received the subscription updates the load distribution management table 171 held by the load distribution management table holding unit 170 based on the subscription (step 1002).

  Note that sending a subscription to the load distribution control unit 160 is not limited to the routing unit 120, and the information transfer unit 110 may send the subscription to the load distribution management control unit 160.

  After sending the subscription to the load balancing control unit 160, the routing unit 120 determines whether or not the received subscription is a managed subscription based on the subscription conditions included in the subscription (step 1003).

  When the subscription is not the management target subscription of the own node (No in Step 1003), the routing unit 120 transfers the subscription to the next node via the information transfer unit 110 based on the routing table 131 (Step 1004).

  In the case of a managed subscription of the own node (yes in step 1003), the routing unit 120 sends the subscription to the event control unit 140. Upon receiving the subscription, the event control unit 140 adds the received subscription to the subscription table 151 held by the subscription table holding unit 150 (step 1005). As this addition, the event control unit 140 may update some information in the subscription table 151. Note that the information notification node 10 becomes a rendezvous node for the managed subscription of the own node.

  The subscription is transferred to the next node or the subscription is registered in the subscription table 151, and the information notification node 10 ends the operation when receiving the subscription.

  Next, subscription transfer in the pub / sub network 40 will be described with reference to the drawings.

  FIG. 4 is a diagram showing an example of subscription transfer in the pub / sub network 40.

  First, the configuration of FIG. 4 will be described.

  In FIG. 4, a great circle is a transfer route of information indicated by the routing table 131. Note that the transfer direction in the route shown in FIG. 4 is clockwise. Therefore, the subscription is transferred clockwise.

  The information notification node is indicated by a small circle. The numerical value in the small circle is the node ID of each information notification node that is also a key of the distributed hash table (DHT).

  Note that the information notification node according to the present embodiment may be at any node position in FIG. 4, but in the description according to the present embodiment, the information notification node 10 having ID = 1000 will be described.

  Note that the information notification node 10 according to the present embodiment does not necessarily have one previous node. Therefore, FIG. 4 shows a case where there are two previous nodes of the information notification node 10 as an example. The information notification node 11 with ID = 0111 is the first previous node, and the information notification node 13 with ID = 0110 is the second previous node. The information notification node 12 with ID = 0101 is a previous node of the information notification node 11. Since the information notification node 11 is a previous node of the information notification node 10, the information notification node 12 is a node before the information notification node 10.

  Further, in FIG. 4, six subscribers (sub20a-sub20f) have registered subscriptions. In FIG. 4, subscription registration is indicated by arrows from each subscriber (sub). For convenience of explanation, all six subscriptions are managed subscriptions of the information notification node 10 (ID = 1000).

  Next, the subscription transfer operation of the information notification node in FIG. 4 will be described.

  The information notification node 15 (ID = 0001) that has received the subscription from the subscriber 20a transfers the subscription based on the routing table 131 held in the own node. However, the information notification node 15 cannot directly transfer the subscription to the information notification node 10 (ID = 1000) that is the transfer destination of the subscription. Therefore, the information notification node 15 first transfers the subscription to the information notification node 12 (ID = 0101).

  The information notification node 12 that has received the subscription from the information notification node 15 and the subscriber 20c cannot transfer the subscription directly to the information notification node 10, and therefore transfers two subscriptions to the information notification node 11 (ID = 0111).

  The information notification node 11 that has received subscriptions from the information notification node 12 and the subscriber 20 e transfers three subscriptions to the information notification node 10.

  Similarly, the information notification node 14 (ID = 0010) that received the subscription from the subscriber 20b cannot directly transfer the subscription to the information notification node 10, and therefore transfers the subscription to the information notification node 13 (ID = 0110). .

  The information notification node 13 that has received subscriptions from the information notification node 14 and the subscriber 20 d transfers the two subscriptions to the information notification node 10.

  The information notification node 10 that has received a subscription from the subscriber 20f, the information notification node 13, and the information notification node 11 does not transfer the subscription because the received subscription is a managed subscription of the own node.

  The information notification node 10 in charge of management who has received the managed subscription updates the load distribution management table 171 and the subscription table 151 based on the operation described with reference to FIG.

  In this way, the pub / sub network 40 including the information notification node 10 according to the present embodiment transfers the subscription to the information notification node 10 that is in charge of managing the subscription.

  Next, a table included in the information notification node 10 after registering the subscription described with reference to FIG. 4 will be described. As already described, description of the routing table 131 is omitted.

  First, the load distribution management table 171 will be described with reference to the drawings.

  FIG. 5 is a diagram illustrating an example of the load distribution management table 171 created or updated by the information notification node 10 based on the subscription transfer operation described with reference to FIG.

  The load distribution management table 171 according to the present embodiment includes a subscription condition 172, a previous node ID 173, a notification destination ID 174, a load person 175, and a previous node transfer 176. In FIG. 5, each row is a record.

  The subscription condition 172 holds the subscription condition included in the subscription. That is, the subscription condition 172 includes an information notification node of a manager in charge of event notification based on the subscription and information on the event condition. For example, in the record on the first line (first) in FIG. 5, the information notification node with ID = 1000 (information notification node 10 in FIG. 4) is the information notification node in charge of management, and the event to be notified is “accident”. It is shown that.

  The previous node ID 173 holds information of the node that has sent the subscription, that is, the previous node. Note that various methods may be used as the method of indicating the previous node, but in this embodiment, a node ID is used as an example. For example, the record in the first row in FIG. 5 indicates that a subscription has been received from the information notification node with ID = 0111 (information notification node 11 in FIG. 4). However, when the information notification node 10 receives a subscription from the subscriber 20, the previous node ID 173 is blank ("-" in the record on the third line in FIG. 5). Further, as already described, the previous node ID 173 may be set based on the subscription node ID of the subscription.

  The notification destination ID 174 is information indicating a notification destination (subscriber 20 in the present embodiment) of an event designated based on the subscription. Since the records shown in FIG. 5 are collected by the previous node ID 173, the notification destination ID 174 may include a plurality of notification destinations. For example, the record on the first line in FIG. 5 indicates that the notification destinations are sub20a, sub20c, and sub20e. However, the information notification node 10 according to the present embodiment is not limited to this, and may be a record for each notification destination.

  The load charge 175 indicates whether or not to notify the event in its own node. The load charge 175 indicates “T” when notifying by the own node, and “F” when not informing.

  The previous node transfer 176 indicates whether or not processing is delegated to the previous node (request for notification) for load distribution which will be described in detail later. When the previous node transfer 176 is “T”, the information notification node 10 delegates the process. In the case of “F”, the information notification node 10 has not delegated the process.

  The load manager 175 and the previous node transfer 176 shown in FIG. 5 are all released as an initial state.

  Note that the load distribution management table 171 illustrated in FIG. 5 includes the six subscriptions received by the information notification node 10 based on the operation described with reference to FIG. Shows an example held together.

  FIG. 6 is a diagram illustrating an example of the load distribution management table 171 created or updated by the information notification node 11 based on the subscription transfer operation described with reference to FIG.

  Since each item is the same as that in FIG. 5, detailed description thereof is omitted.

  Since the information notification node 11 has received two subscriptions, the load distribution management table 171 also holds two records.

  It should be noted that the load manager 175 and the previous node transfer 176 shown in FIG. 6 are all released as an initial state.

  FIG. 7 is a diagram showing an example of the subscription table 151 according to the present embodiment.

  The subscription table 151 of the information notification node 10 according to the present embodiment includes a subscription condition 152, a notification destination ID 153, and a load delegation 154. In FIG. 7, each line is a record.

  The subscription condition 152 holds the subscription condition included in the subscription. That is, the subscription condition 152 includes a condition of the node ID of the information notifying node in charge of management who notifies the event and the event based on the subscription. Note that the information notification node 10 according to the present embodiment holds the managed subscription in the subscription table 151. That is, the information notification node 10 holds the subscription notified by the own node in the subscription table 151. Therefore, the node ID that notifies the event of the subscription condition 152 is the ID of the own node.

  The notification destination ID 153 is an identifier (ID) indicating an event notification destination device. As already described, in this embodiment, since the subscriber 20 and the notification destination are described as being the same, the notification destination ID 153 is the subscriber ID that has registered the subscription. Note that the subscription table 151 according to the present embodiment collects records having the same subscription condition 152. Therefore, the notification destination ID 153 shown in FIG. 7 holds a plurality of notification destinations (subscribes). However, the information notification node 10 according to the present embodiment is not limited to this, and may be a record for each notification destination.

  Note that the record in the first row in FIG. 7 is a record corresponding to the subscription described with reference to FIG. 4 and holds sub20a to sub20f as notification destinations.

  The load delegation 154 is information indicating whether or not another node has been requested to notify the management target event specified by the subscription. In FIG. 7, “T” indicates requested, and “F” indicates unrequested, that is, notification by the own node.

(Load distribution setting in the information notification node)
Next, the load distribution setting operation in the information notification node 10 will be described with reference to the drawings.

  First, the load balancing setting operation in the event control unit 140 will be described with reference to the drawings.

  FIG. 8 is a flowchart showing an example of load distribution setting operation of the event control unit 140.

  The event control unit 140 starts the following operation based on each record of the subscription table 151 at a predetermined timing (for example, periodically or after receiving a subscription) (step 2001).

  The event control unit 140 determines whether or not the event notification load of each record is greater than that of its own node (step 2002). The event control unit 140 can make a determination based on various conditions. For example, as a determination condition, the event control unit 140 determines the number of notification destinations registered in the record of the subscription table 151, the frequency of occurrence of an event for the subscription or the subscription, the CPU (central process unit) of the own node. The processing state or the load state of the communication line, the distance (number of hops) to the notification destination, the memory usage of the own node, or the predicted values thereof can be used. In this embodiment, as an example, a case where the number of notification destinations registered in the subscription table 151 is used as a condition will be described. Therefore, the event control unit 140 compares the number of notification destinations registered in the record of the subscription table 151 (in this embodiment, the number of subscriptions) with a predetermined threshold value. For example, the number of notification destinations of the record shown in the first line in FIG. 7 is “6”. Therefore, when the threshold value is less than “6”, the number of notification destinations exceeds the threshold value, and it is determined that the load is large (yes in step 2002). On the other hand, when the threshold value is “6” or more, the number of notification destinations does not exceed the threshold value, and it is determined that the load is not large (No in step 2002).

  When the load is not large (No in Step 2002), load distribution is not necessary. Therefore, the event control unit 140 sets the processing in the own node, that is, the load delegation 154 of the subscription table 151 to not delegation (F) (step 2006).

  If the load is heavy (yes in step 2002), load balancing is necessary.

  Therefore, the event control unit 140 sends a load sharing request including the subscription condition 152 to the load distribution control unit 160 in order to request the previous node to share the load of the record exceeding the threshold (step 2003). .

  Thereafter, the event control unit 140 waits for the end of the processing of the load distribution control unit 160 (step 2004).

  When the processing of the load distribution control unit 160 ends, the event control unit 140 sets the load delegation 154 of the subscription table 151 to delegation (T).

  For example, the record in the first line in FIG. 7 indicates that the load has been delegated and the record in the second line has not been delegated.

  Based on such an operation, the event control unit 140 sets load distribution.

  Next, the load distribution setting operation of the load distribution control unit 160 will be described with reference to the drawings.

  FIG. 9 is a flowchart showing an example of the load distribution setting operation of the load distribution control unit 160.

  The load distribution control unit 160 receives a load distribution setting request from the event control unit 140 and starts processing (step 2101).

  The load distribution control unit 160 repeats the following operation for each record in the load distribution management table 171 that matches the subscription condition included in the request of the event control unit 140 (step 2102).

  First, the load distribution control unit 160 determines whether or not to request (delegate) processing of each record to the previous node based on a predetermined condition (step 2103). The predetermined condition used for this determination is a condition for the load distribution control unit 160 to determine the range of events to be delegated or the range of events not to be delegated. For example, the load distribution control unit 160 may hold a threshold value of the number of notification destinations in advance and determine to delegate the number of notifications exceeding the threshold value. You may delegate. However, the subscription received directly from the subscriber has no previous node. For this reason, in the case of a subscription received directly from a subscriber, the load distribution control unit 160 determines to notify the local node.

  As a result of the determination, when delegation is not performed (No in Step 2103), the load distribution control unit 160 sets the load manager 175 of the load distribution management table 171 to the own node (Step 2106). Specifically, the load distribution control unit 160 sets the load manager 175 of the load distribution management table 171 to “T” and the previous node manager to “F”.

  When delegating a notification (yes in step 2103), the load distribution control unit 160 creates a proxy request message 201 for requesting delegation of notification and sends it to the previous node held by the previous node ID 173 (step 2104). ). The proxy request message 201 can adopt various formats. For example, the proxy request message 201 includes a subscription condition 172 of a record to be delegated and a notification destination ID 174. To do.

  After sending the proxy request message 201, the load distribution control unit 160 sets “T” in the previous node transfer 176 and “F” in the load manager 175 of the load distribution management table 171 (step 2105). However, when a part of the record is delegated, the load distribution control unit 160 divides the target record into a record to be delegated and a record that is not delegated. The record to be set is set in the same manner as in step 2105.

  The load distribution control unit 160 repeats the operations described so far for all records that match the requested subscription condition.

  When the processing of all the records to be processed is completed, the load distribution control unit 160 notifies the event control unit 140 of the end of the processing (step 2107).

  FIG. 10 is a diagram illustrating an example of the load distribution management table 171 after the operation described with reference to FIG. The load distribution management table 171 shown in FIG. 10 is an example of a case where a part of the records in the first line of the load distribution management table 171 shown in FIG. 5 is delegated based on a threshold value and all the records in the second line are delegated. It is. In order to delegate a part, the record on the first line in FIG. 5 is divided into a record on the first line notified by the own node and a record on the second line to be delegated in FIG. In the load distribution management table 171 shown in FIG. 10, the notification destination (sub20a) of the record on the first row and the notification destination (sub20f) on the fourth row where the own node has received the subscription are notified by the own node. The load manager 175 is “T” and the previous node transfer 176 is “F”. Further, since the notification destinations (sub2b-sub2e) of the records in the second and third rows have already been delegated by sending the proxy request message 201, the load manager 175 is “F”, and the previous node transfer 176 is “T”. It has become.

(Load delegation setting on the previous node)
Next, the operation of the previous node (for example, the information notification node 11) that has received the proxy request message 201 will be described with reference to the drawings. This operation is performed in the same manner in the information notification node according to the present embodiment, but will be described using the information notification node 11 here.

  FIG. 11 is a flowchart showing an example of the operation of the information notification node 11 that has received the proxy request message 201.

  The information transfer unit 110 of the information notification node 11 that has received the proxy request message 201 sends the proxy request message 201 to the load distribution control unit 160 (step 3001).

  Upon receiving the proxy request message 201, the load distribution control unit 160 compares the subscription condition included in the proxy request message 201 with the subscription condition of the load distribution management table 171 and repeats the following operation for the matched records ( Step 3002).

  The load distribution control unit 160 determines whether the proxy request message 201 is delegated at its own node and takes charge of notification, or further delegates to the previous node (step 3003). As this determination, the load distribution control unit 160 may determine, for example, in the same manner as in Step 2103 described with reference to FIG.

  When delegating the load to the previous node (yes in step 3003), the load distribution control unit 160 transmits the proxy request message 201 to the further previous node (previous node) (step 3004).

  Further, the load distribution control unit 160 sets the previous node transfer 176 of the corresponding record in the load distribution management table 171 to “T” and the load manager 175 to “F” (step 3005).

  On the other hand, when the node is in charge of notification (no in step 3003), the load distribution control unit 160 sets the load manager 175 of the corresponding record to “T” and the previous node transfer 176 to “F” (step 3006). ).

  Based on such an operation, the information notification node 11 sets the response or delegation in the own node based on the load distribution management table 171 for the received proxy request message 201.

  FIG. 12 is a diagram illustrating an example of the load distribution management table 171 of the information notification node 11 after receiving the proxy request message 201. The record in the first line in FIG. 12 is a record in the case where the own node takes charge. Therefore, the load manager 175 is “T”, and the previous node transfer 176 is “F”. The record on the second line is an example of delegation. Therefore, the load manager 175 is “F”, and the previous node transfer 176 is “T”. That is, the load distribution management table 171 shown in FIG. 12 indicates that the own node notifies the event to the sub 20e and delegates the notification of the sub 20c.

(Event notification operation at the target node)
Next, the operation when the information notification node 10 that is the target node (the rendezvous node) receives an event, that is, the operation of the information notification node 10 that is the manager in charge of receiving the management target event will be described with reference to the drawings. .

  FIG. 13 is a flowchart showing an example of the operation of the information notification node 10 that has received the management target event.

  When an event is published (transmitted or input) from the publisher 30 to the pub / sub network 40, the pub / sub network 40 transfers the event to the information notification node 10 in charge of management.

  The information transfer unit 110 of the information notification node 10 that has received the event sends the event to the event control unit 140 (step 4001).

  Upon receiving the event, the event control unit 140 repeats the processing described below for each record held in the subscription table 151 (step 4002).

  The event control unit 140 checks whether or not the received event matches the subscription condition 152 of each record, that is, whether or not it is a target event (step 4003).

  If the event is not a target event (no in step 4003), the event control unit 140 proceeds to processing of the next record without particularly operating.

  In the case of a target event (yes in step 4003), the event control unit 140 confirms the load delegation 154 of the record of the subscription table 151 corresponding to the target event (step 4004).

  When the load delegation 154 is not load delegation (F) (no in step 4004), the information notification node 10 notifies the notification destination ID 153 of an event (step 4005).

  If the load has been transferred (T) (yes in step 4004), the event control unit 140 requests the load distribution control unit 160 to perform notification (load distribution) (step 4006).

  Then, the event control unit 140 waits for a result from the load distribution control unit 160. The event control unit 140 that has received the result from the load distribution control unit 160 checks the content of the result (step 4007).

  If the result of the determination is not load delegation, that is, notification in the own node is included (No in step 4007), the event control unit 140 notifies the event that results in notification (step 4005).

  If all the determination results are load delegation (yes in step 4007), the event control unit 140 ends the process and proceeds to the process for the next record.

  FIG. 14 is a flowchart showing an example of the operation of the load distribution control unit 160 requested to distribute the load of the event in step 4006 shown in FIG.

  Upon receiving the load distribution request (step 4101), the load distribution control unit 160 repeats the following operation for the record in which the subscription condition 172 in the load distribution management table 171 matches the subscription condition of the load distribution request ( Step 4102).

  The load distribution control unit 160 checks whether or not the load has been delegated, that is, the load manager 175 of each record in the load distribution management table 171 (step 4103).

  When the load is handled by the own node (yes in step 4103), the load distribution control unit 160 returns to the event control unit 140 a result of notifying the event corresponding to the record by the own node (step 4104). Upon receiving this result, the event control unit 140 notifies the event as described above. After notifying the event control unit 140, the load distribution control unit 160 proceeds to processing the next record.

  If the node does not handle the load (no in step 4103), the load distribution control unit 160 confirms the previous node transfer 176 of the record, and determines whether or not it has been delegated to the previous node. It is confirmed whether or not the request is made (step 4105).

  When the load has been delegated (yes in step 4105), the load distribution control unit 160 sends a request for notification on behalf of the previous node registered in the previous node ID 173 via the information transfer unit 110 (hereinafter referred to as notification ( notify) (referred to as request message 202) (step 4106). The notification request message 202 can adopt various formats and information included therein. The notification request message 202 according to the present embodiment includes, as an example, information (or subscription conditions) related to an event that requests a proxy for notification.

  If the load has not been delegated (No in step 4105), the load is not generated. Therefore, the load distribution control unit 160 may not particularly operate.

  After transmitting the notification request message 202 or when the load has not been transferred, the load distribution control unit 160 proceeds to the operation of the next record.

  When the operation is completed for all the matching records, the load distribution control unit 160 notifies the event control unit 140 of the end of load distribution (step 4107), and ends the processing.

  Note that the load distribution control unit 160 may collectively notify the event control unit 140 of event notifications at its own node. However, as described in the present embodiment, when the load distribution control unit 160 communicates for each record, the event control unit 140 may start notification of an event earlier compared to the case where the last contact is collectively received. it can.

(Event notification operation at the previous node)
Next, the operation of the previous node that has received the notification request message 202 (in this description, the information notification node 11) will be described.

  FIG. 15 is a flowchart showing an example of the operation of the previous node (information notification node 11) that has received the notification request message 202.

  The information transfer unit 110 of the information notification node 11 that is the previous node receives the notification request message 202 from the information notification node 10 that is in charge of event management (step 5001).

  The information transfer unit 110 that has received the notification request message 202 sends the notification request message 202 to the load distribution control unit 160.

  The load distribution control unit 160 that has received the notification request message 202 searches the load distribution management table 171 for a record including the subscription condition 172 that matches the subscription condition included in the notification request message 202. The load distribution control unit 160 repeats the following operation for the matched records (step 5002).

  The load distribution control unit 160 determines whether or not the own node is in charge of load based on the load charge 175 of each record (step 5003).

  When the load is in charge (yes in step 5003), the load distribution control unit 160 requests the event control unit 140 to notify the event. Upon receiving the request, the event control unit 140 notifies the event requested by the notification request message 202 (step 5004).

  When not in charge of load (no in step 5003), the load distribution control unit 160 refers to the previous node transfer 176 in the load distribution management table 171, and determines whether to delegate the load, that is, to transmit the notification request message 202. Determination is made (step 5005).

  When delegating the load (yes in step 5005), the load distribution control unit 160 transmits the notification request message 202 to a further previous node (previous node) based on the load distribution management table 171.

  When the load is not delegated (No in Step 5006), the load distribution control unit 160 ends without particularly operating.

(An example of network event notification)
The event notification proxy will be further described with reference to the drawings.

  FIG. 16 is a diagram illustrating an example of an event notification proxy in the pub / sub network 40.

  The small circles shown in FIG. 16 indicate information notification nodes as in FIG. The information notification node 10 (ID = 1000) includes a subscription table 151 shown in FIG. 7 and a load distribution management table 171 shown in FIG. Furthermore, it is assumed that the information notification node 11 (ID = 0111) includes a load distribution management table 171 shown in FIG. Further, it is assumed that the information notification node 12 and the information notification node 13 notify the event by the own node.

  As shown in FIG. 16, it is assumed that the publisher 30 (pub30) issues an event that matches the subscription condition 152 of the record in the first row in FIG.

  This event is received by the information notification node 16 and transferred to the information notification node 10 which is responsible for managing the event.

  First, the operation of the information notification node 10 will be described.

  The event control unit 140 of the information notification node 10 that has received the event determines that the event matches the subscription condition 152 of the record in the first row of the subscription table 151 shown in FIG. 7 (step 4003 in FIG. 13). Then, the event control unit 140 confirms the load delegation 154 of the record in the first line (step 4004 in FIG. 13), and since the delegation has been completed, requests the load distribution control unit 160 to distribute the load (in FIG. 13). Step 4006).

  Upon receiving the request, the load distribution control unit 160, for the record on the first line (the notification destination is sub20a) and the record on the fourth line (the notification destination is sub20f), based on the load distribution management table 171 shown in FIG. An event notification is notified to the control unit 140 (step 4104 in FIG. 14).

  Based on this result, the event control unit 140 notifies the event to the sub 20a and the sub 20f (step 4005 in FIG. 13).

  In addition, the load distribution control unit 160 reports the node 0111 (information notification of the first previous node) held in the previous node ID 173 for the second row record (the notification destination is sub20c, 20e) of the load distribution management table 171. The notification request message 202 is sent to the node 11) (step 4106 in FIG. 14).

  Similarly, the load distribution control unit 160 sends a notification request message to the node 0110 (the second previous node, the information notification node 13) regarding the record on the third line of the load distribution management table 171 (the notification destinations are sub20b and 20d). 202 is sent (step 4106 in FIG. 14).

  In this way, the information notification node 10 notifies the event at its own node and requests proxy of notification.

  Next, the operation of the information notification node 11 will be described.

  Upon receiving the notification request message 202, the load distribution control unit 160 of the information notification node 11 determines, based on the load distribution management table 171 shown in FIG. 12, the event control unit 140 for the record on the first line (the notification destination is sub20e). Contact event notification. Further, the load distribution control unit 160 of the information notification node 11 notifies the node 0101 (the information notification node 12 which is the previous node) held in the previous node ID 173 for the record on the second line (the notification destination is sub20c). A request message 202 is sent.

  The information notification node 12 and the information notification node 13 notify the notification delegated by the notification request message 202 at their own nodes. That is, the information notification node 12 notifies the event to the sub 20 c requested from the information notification node 11. The information notification node 13 notifies the event to the sub 20b and the sab 20d requested from the information notification node 10.

  The correspondence between each information notification node and the notification destination subscriber 20 (sub20a-sub20f) is summarized as follows.

Information notification node 10: sub20a, sub20f
Information notification node 11: sub20e
Information notification node 12: sub20c
Information notification node 13: sub20b, sub20d
As described above, the information notification node 10 according to the present embodiment uses the subscription table 151 and the load distribution management table 171 set based on the load to notify the previous node of information (event), that is, proxy the load. Ask. Also, the information notification node 11 that has received the request can determine whether the node notifies the event or requests proxy of the notification based on the load of the local node, and can request the proxy of the load.

(Cancellation of subscription)
Next, the operation of the information notification node 10 when a subscription is further received after setting load distribution or when a subscription is canceled (hereinafter referred to as a cancellation notification) will be described with reference to the drawings.

  FIG. 17 is a flowchart illustrating an example of the operation of the event control unit 140 that has received a subscription or cancellation notification after setting load distribution.

  The event control unit 140 that has received the subscription operates as described below when the subscription condition 152 is already registered. If the subscription condition 152 is not registered, the event control unit 140 may operate in the same manner as already described with reference to FIG.

  The event control unit 140 repeats the operation described below for the registered records (step 6001).

  The event control unit 140 updates the record stored in the subscription table 151 based on the received subscription or cancellation notification. After the update, the event control unit 140 determines the load status of the own node (step 6002).

  If the load is not heavy (No in Step 6002), the event control unit 140 determines whether or not the load has been transferred (Step 6003).

  If the load has not been transferred (No in step 6003), the event control unit 140 ends without performing any particular operation.

  If the load has been transferred (yes in step 6003), the event control unit 140 requests the load distribution control unit 160 to cancel the load distribution (step 6004).

  Thereafter, the event control unit 140 waits for the end of the processing of the load distribution control unit 160 (step 6005).

  When the processing of the load distribution control unit 160 ends, the event control unit 140 changes the data in the subscription table 151 to the load of the own node (step 6006), and ends the processing.

  When the load is large (yes in step 5002), the event control unit 140 requests the load distribution control unit 160 to reset the load distribution (step 6007). The resetting operation of the load distribution control unit 160 may be performed in the same manner as the operation described with reference to FIG. 9, and detailed description thereof is omitted.

  After requesting resetting, the event control unit 140 waits for the end of the processing of the load distribution control unit 160 (step 6008).

  After the processing of the load distribution control unit 160 ends, the event control unit 140 sets the subscription table 151 to be delegated (step 6009).

  Next, the operation of the load distribution control unit 160 that has received a request to cancel load distribution will be described with reference to the drawings.

  FIG. 18 is a flowchart illustrating an example of the operation of the load distribution control unit 160.

  In response to the request for releasing load distribution (step 6101), the load distribution control unit 160 repeats the following operation with respect to the record of the load distribution management table 171 corresponding to the request (step 6102).

  The load distribution control unit 160 determines whether the load has been delegated based on the load manager 175 of the load distribution management table 171 (step 6103).

  When the load has been delegated (yes in step 6103), the load distribution control unit 160 creates a proxy release message 203 for requesting the proxy release and transmits it to the delegation destination node (for example, the information notification node 11). (Step 6104). After the notification, the load distribution control unit 160 updates the information in the load distribution management table 171 (step 6105). More specifically, the load distribution control unit 160 cancels the load charge, that is, sets the previous node transfer 176 to “F” and the load charge 175 to “F”. Here, the load distribution control unit 160 may combine the records to be combined.

  When the load has not been transferred (No in step 6103), the load distribution control unit 160 does not need to operate. However, for the sake of safety, the load distribution control unit 160 may set the release of the load charge in the same manner as in Step 6105.

  After updating the load distribution management table 171, the load distribution control unit 160 notifies the event control unit 140 of the end of release (step 6106) and ends the process.

  Next, the operation of the delegation destination (for example, the information notification node 11) that has received the proxy release message 203 will be described with reference to the drawings.

  FIG. 19 is a flowchart illustrating an example of the operation of the load distribution control unit 160 of the information notification node 11 that has received the proxy release message 203.

  Upon receiving the proxy release message 203 (step 7001), the load distribution control unit 160 of the information notification node 11 repeats the following operation for the record of the load distribution management table 171 corresponding to the request (step 7002).

  The load distribution control unit 160 determines whether or not the load has been delegated based on the load manager 175 of the load distribution management table 171 (step 7003).

  When the load has been delegated (yes in step 7003), the load distribution control unit 160 transmits the proxy release message 203 to the delegation destination node (for example, the information notification node 12) (step 7004). After the notification, the information notification node 11 updates the information in each table so as to release the load charge (step 7005).

  If the load has not been transferred (No in Step 7003), the load distribution control unit 160 ends without doing anything. However, for the sake of safety, the load distribution control unit 160 may set the release of the load charge similarly to step 7005.

  Based on the operations described so far, the information notification node cancels the load sharing.

  In the above description, when the previous node (for example, the information notification node 11) that has received the proxy request message 201 cannot take charge of the load, the previous node further sends the proxy request message 201 to the node two days before the load request. I was asking for an agent. However, the information notification node according to the present embodiment is not limited to this.

  For example, the previous node that cannot take charge of the load may send a delegation rejection message back to the requesting node instead of sending the proxy request message 201 by itself.

  The information notification node that has received this message of rejection of delegation may newly send a proxy request message 201 to another information notification node.

  Furthermore, the configuration of the information notification node 10 according to the present embodiment is not limited to the configuration described so far. The information notification node 10 according to the present embodiment may include several configurations as one configuration, for example, a configuration in which the event control unit 140 and the load distribution control unit 160 are combined.

  In addition, each configuration of the information notification node 10 according to the present exemplary embodiment may be further divided into a plurality of configurations, or a configuration in which the configuration is provided in another device and connected via a network. For example, each table holding unit may be included in an external storage device connected via a network. Furthermore, the information notification node 10 according to the present embodiment may constitute a part of another device.

(Another configuration)
FIG. 20 is a block diagram showing an example of another configuration of the information notification node according to the present embodiment.

  20, the same components as those in FIG. 1 are denoted by the same reference numerals, and detailed description thereof is omitted.

  The information notification node 18 is incorporated in a predetermined device such as a blade server, and is connected to another device using an internal bus. The information transfer unit 110 of the information notification node 18 is omitted in FIG. 20 because it is included in the event control unit 140 and the load distribution control unit 160. Further, since each table holding unit holds a table in the semiconductor memory unit included in the circuit of each holding unit, the display of each table is omitted in FIG.

  The event control unit 140 and the load distribution control unit 160 of the information notification node 18 configured in this way transmit / receive information to / from other devices (such as the subscriber 20) via the bus, and the information notification node 10 regarding subscriptions and events. It can operate in the same way. For this reason, the information notification node 18 can delegate event notification in the same manner as the information notification node 10.

  The information notification node 18 has a minimum configuration in the present embodiment.

  As described above, the information notification node according to the present embodiment can reduce the load on the device that notifies information (information including an event).

  The reason is that the information notification node according to the present embodiment determines the load of the own node based on the held subscription (reception registration), and if the load is large, the other information notification node (previous node) This is because the notification of the information of the own node can be reduced by requesting the agent to perform the information notification. In addition, since the information notifying node requested to act on behalf of the node can further request delegation based on the load of the own node, the information notifying node requested to act is also appropriate for the own node. This is because a large load can be substituted.

(Second Embodiment)
The information notification node according to the first embodiment may be realized as a program that executes each component on a computer.

  Furthermore, each configuration of the information notification node according to the first embodiment may include a recording medium that stores a program executed by the computer.

  FIG. 21 is a diagram illustrating an example of the configuration of the information notification node 19 according to the second embodiment.

  The information notification node 19 includes an information processing unit 520, an information storage unit 530, and a communication unit 510.

  The information processing unit 520 includes a CPU (Central Process Unit) and executes a program 540 stored in the information storage unit 530. The information processing unit 520 communicates with the subscriber 20 and the like via the communication unit 510 based on the program 540, and operates in the same manner as the information notification node 10 according to the first embodiment.

  The information storage unit 530 includes a storage device such as a hard disk device or a memory storage device (not shown), and stores a program 540 executed by the information processing unit 520. Further, the information storage unit 530 may include a storage medium 550 that holds the program 540. The information storage unit 530 may operate as a temporary storage (work area) of information when the information processing unit 520 operates.

  The communication unit 510 includes a circuit for connecting to a network, for example, a NIC (Network Interface Card), and relays information between the information processing unit 520, the subscriber 20, the publisher 30, and the like.

  Thus, the information notification node 19 according to the second embodiment can obtain the same effect as the information notification node 10 according to the first embodiment.

  This is because the information processing unit 520 of the information notification node 19 according to the second embodiment can operate in the same manner as the information notification node 10 of the first embodiment based on the program 540. is there.

  A part or all of the above-described embodiment can be described as in the following supplementary notes, but is not limited thereto.

(Appendix)
(Appendix 1)
A subscription table holding unit that receives and holds registration (subscription) of information including events;
An event control unit that determines a load of notification of the information based on the held reception registration and determines whether to delegate the notification based on the load;
A load distribution management table holding unit that holds information on a transmission source of the reception registration and a notification destination that notifies the information;
When it is determined that the event control unit is to be delegated, the range of the notification destination to which the notification of the information is delegated is determined based on the information held by the load distribution management table holding unit, and the notification of the information is performed for the notification destination to be delegated An information notification node including a load distribution control unit that sends a request for delegation to the first node and requests the event control unit to notify the information about a notification destination that is not delegated.
(Appendix 2)
The load balancing control unit
When receiving a request for information notification from the second node,
It is determined whether or not the information contained in the request of the second node is notified by the own node, and when not notified by the own node, a request for proxy of the information notification is transmitted to the third node. The information notification node according to supplementary note 1 as a feature.
(Appendix 3)
The load balancing control unit
When receiving a request for information notification from the second node,
It is determined whether or not the information contained in the request from the second node is notified by the own node, and if not notified by the own node, a rejection of the substitute request is sent to the second node. The information notification node according to appendix 1.
(Appendix 4)
The load balancing control unit
When a request for a proxy request is sent in response to a proxy request for the notification of information sent to the first node, a request for a proxy for notification of information is transmitted to a node different from the first node. 4. The information notification node according to any one of supplementary notes 1 to 3, which is a feature.
(Appendix 5)
The load balancing control unit
The information notification node according to any one of appendix 1 to appendix 4, wherein the first node is selected from nodes included in the transmission source held by the load distribution management table holding unit.
(Appendix 6)
The event control unit or the condition for determining whether or not to notify the own node of the load distribution control unit,
The number of notification destinations of the reception registration held by the subscription table holding unit;
Occurrence frequency of the distribution request and the distribution request,
Processing load of the own node,
Distance (number of hops) to notification destination,
Resource usage of the own node,
The information notification node according to any one of Supplementary Note 1 to Supplementary Note 5, which includes any one of predicted values of the above-described conditions.
(Appendix 7)
Receive and hold information subscriptions,
Determining the load of notification of the information based on the received registration held, determining whether to delegate the notification based on the load;
Holding information of the sender of the reception registration and a notification destination for notifying the information;
When it is determined that the information is to be delegated, the range of the notification destinations to which the notification of the information is delegated is determined based on the information of the transmission source of the reception registration and the notification destination to which the information is notified. An information notification method for sending a request for proxy of notification to the first node and notifying the information about a notification destination that is not delegated.
(Appendix 8)
When receiving a request for information notification from the second node,
It is determined whether or not the information contained in the request of the second node is notified by the own node, and when not notified by the own node, a request for proxy of the information notification is transmitted to the third node. The information notification method according to appendix 7, which is a feature.
(Appendix 9)
When receiving a request for information notification from the second node,
It is determined whether or not the information contained in the request from the second node is notified by the own node, and if not notified by the own node, a rejection of the substitute request is sent to the second node. The information notification method according to appendix 7.
(Appendix 10)
When a request for a proxy request is sent in response to a proxy request for the notification of information sent to the first node, a request for a proxy for notification of information is transmitted to a node different from the first node. 10. The information notification method according to any one of appendix 7 to appendix 9, which is a feature.
(Appendix 11)
The information notification method according to any one of appendix 7 to appendix 10, wherein the first node is selected from nodes included in the transmission source to be held.
(Appendix 12)
The condition for determining whether or not to notify the local node is:
The number of notification destinations of the reception registration held by the subscription table holding unit;
Occurrence frequency of the distribution request and the distribution request,
Processing load of the own node,
Distance (number of hops) to notification destination,
Resource usage of the own node,
The information notification method according to any one of Supplementary Note 7 to Supplementary Note 11, which includes any one of predicted values of each of the above conditions.
(Appendix 13)
Processing to receive and hold information reception registration;
A process for determining a load of the notification of the information based on the received reception registration, and determining whether to delegate the notification based on the load;
A process of holding information on the transmission source of the reception registration and a notification destination for notifying the information;
When it is determined that the information is to be delegated, the range of the notification destinations to which the notification of the information is delegated is determined based on the information of the transmission source of the reception registration and the notification destination to which the information is notified. A program that sends a request for proxy to the first node, and causes the computer to execute a process of notifying the information about a notification destination that is not delegated.
(Appendix 14)
When receiving a request for information notification from the second node,
It is determined whether or not the information contained in the request of the second node is notified by the own node, and when not notified by the own node, a request for proxy of the information notification is transmitted to the third node. 14. The program according to appendix 13, which is characterized.
(Appendix 15)
When receiving a request for information notification from the second node,
It is determined whether or not the information contained in the request from the second node is notified by the own node, and if not notified by the own node, a rejection of the substitute request is sent to the second node. The program according to appendix 13.
(Appendix 16)
When a request for a proxy request is sent in response to a proxy request for the notification of information sent to the first node, a request for a proxy for notification of information is transmitted to a node different from the first node. The program according to any one of Supplementary Note 13 to Supplementary Note 15, which is characterized.
(Appendix 17)
The program according to any one of appendix 13 to appendix 16, wherein the first node is selected from nodes included in the transmission source to be held.
(Appendix 18)
The condition for determining whether or not to notify the local node is:
The number of notification destinations of the reception registration held by the subscription table holding unit;
Occurrence frequency of the distribution request and the distribution request,
Processing load of the own node,
Distance (number of hops) to notification destination,
Resource usage of the own node,
Or the program according to any one of appendix 13 to appendix 17, wherein the program includes any one of the predicted values of the above conditions.
(Appendix 19)
The information notification node according to any one of appendix 1 to appendix 6, and
A subscriber to register for subscription of information;
An information distribution system including a publisher that issues the information.

DESCRIPTION OF SYMBOLS 1 Information delivery system 9 Information delivery system 10 Information notification node 11 Information notification node 12 Information notification node 13 Information notification node 14 Information notification node 15 Information notification node 16 Information notification node 18 Information notification node 19 Information notification node 20 Subscriber 30 Publisher 40 pub / sub network 90 pub / sub network 110 information transfer unit 120 routing unit 130 routing table holding unit 140 event control unit 150 subscription table holding unit 151 subscription table 152 subscription condition 153 notification destination ID
154 Load delegation 160 Load distribution control unit 170 Load distribution management table holding unit 171 Load distribution management table 172 Subscription condition 173 Previous node ID
174 Notification ID
175 Load charge 176 Previous node transfer 201 Proxy request message 202 Notification request message 203 Proxy release message 510 Communication unit 520 Information processing unit 530 Storage unit 540 Program 550 Storage medium

Claims (10)

A subscription table holding unit that receives and holds registration (subscription) of information including events;
An event control unit that determines a load of notification of the information based on the held reception registration and determines whether to delegate the notification based on the load;
A load distribution management table holding unit that holds information on a transmission source of the reception registration and a notification destination that notifies the information;
When it is determined that the event control unit is to be delegated, the range of the notification destination to which the notification of the information is delegated is determined based on the information held by the load distribution management table holding unit, and the notification of the information is performed for the notification destination to be delegated An information notification node including a load distribution control unit that sends a request for delegation to the first node and requests the event control unit to notify the information about a notification destination that is not delegated. The load balancing control unit
When receiving a request for information notification from the second node,
It is determined whether or not the information contained in the request of the second node is notified by the own node, and when not notified by the own node, a request for proxy of the information notification is transmitted to the third node. The information notification node according to claim 1, wherein: The load balancing control unit
When receiving a request for information notification from the second node,
It is determined whether or not the information contained in the request from the second node is notified by the own node, and if not notified by the own node, a rejection of the substitute request is sent to the second node. The information notification node according to claim 1. The load balancing control unit
When a request for a proxy request is sent in response to a proxy request for the notification of information sent to the first node, a request for a proxy for notification of information is transmitted to a node different from the first node. The information notification node according to any one of claims 1 to 3, wherein the information notification node is provided. The load balancing control unit
The information notification node according to any one of claims 1 to 4, wherein the first node is selected from nodes included in the transmission source held by the load distribution management table holding unit. The event control unit or the condition for determining whether or not to notify the own node of the load distribution control unit,
The number of notification destinations of the reception registration held by the subscription table holding unit;
Occurrence frequency of the distribution request and the distribution request,
Processing load of the own node,
Distance (number of hops) to notification destination,
Resource usage of the own node,
The information notification node according to claim 1, wherein the information notification node includes any one of predicted values of the respective conditions. Receive and hold information subscriptions,
Determining the load of notification of the information based on the received registration held, determining whether to delegate the notification based on the load;
Holding information of the sender of the reception registration and a notification destination for notifying the information;
When it is determined that the information is to be delegated, the range of the notification destinations to which the notification of the information is delegated is determined based on the information of the transmission source of the reception registration and the notification destination to which the information is notified. An information notification method for sending a request for proxy of notification to the first node and notifying the information about a notification destination that is not delegated. When receiving a request for information notification from the second node,
It is determined whether or not the information contained in the request of the second node is notified by the own node, and when not notified by the own node, a request for proxy of the information notification is transmitted to the third node. The information notification method according to claim 7, wherein Processing to receive and hold information reception registration;
A process for determining a load of the notification of the information based on the received reception registration, and determining whether to delegate the notification based on the load;
A process of holding information on the transmission source of the reception registration and a notification destination for notifying the information;
When it is determined that the information is to be delegated, the range of the notification destinations to which the notification of the information is delegated is determined based on the information of the transmission source of the reception registration and the notification destination to which the information is notified. A program that sends a request for proxy to the first node, and causes the computer to execute a process of notifying the information about a notification destination that is not delegated. An information notification node according to any one of claims 1 to 6,
A subscriber to register for subscription of information;
An information distribution system including a publisher that issues the information.

Images