Message delivery system and method

The message distribution system addresses the issue of increasing session management costs by merging topics into a unified topic, reducing the number of sessions and managing costs effectively.

JP2026055405APending Publication Date: 2026-03-31HITACHI LTD
View PDF 1 Cites 0 Cited by

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-09-18
Publication Date
2026-03-31

AI Technical Summary

Technical Problem

In message distribution systems using the Pub/Sub model, increasing the number of topic subscriptions on the message receiving side leads to an increase in session management costs due to the growing number of sessions between the relay system and the message receiving side.

Method used

A message distribution system where messages are managed by topic in a relay device, with a topic editor device merging topics when the number of subscriptions exceeds a threshold, creating an integrated topic, and managing messages of this unified topic to reduce the number of sessions.

Benefits of technology

This approach suppresses the increase in session management costs by merging topics into a single unified topic, preventing the number of sessions from exceeding a threshold.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2026055405000001_ABST
    Figure 2026055405000001_ABST
Patent Text Reader

Abstract

This document proposes a message delivery system and method that can suppress the increase in session management costs associated with an increase in the number of topic subscriptions on the message receiving side. [Solution] A message delivery system that uses the Pub / Sub model to deliver messages is equipped with a topic editor device. When the number of subscriptions to a topic exceeds a first threshold, the receiving device sends a request to merge these topics to the topic editor device. The topic editor device instructs the relay device to create a merged topic by merging each of the topics requested to be merged in the received merged request, and also starts subscribing to these topics and sends the messages to the relay device. The relay device then delivers the messages of the merged topic to the receiving devices that subscribe to the merged topic.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0002] , , ,

[0005] ,

[0004] , , , , , , ,

[0003] , ,

[0001] The present invention relates to a message distribution system and method, and is suitable for application to, for example, a message distribution system applying a Pub / Sub model.

Background Art

[0002] Conventionally, there is a Pub / Sub model as a message distribution model for enhancing the flexibility and efficiency of a messaging system. In the Pub / Sub model, a message transmission unit called one or more publishers provided on the message distributor side transmits a message to a relay system. Then, this message is classified and managed by category called a topic in the relay system. <00​​​​​​​​​​​​​​​​​​

[0006] [Patent Document 1] Japanese Patent Publication No. 2015-125639 [Overview of the project] [Problems that the invention aims to solve]

[0007] Incidentally, in message distribution systems that employ the Pub / Sub model, increasing the number of topic subscriptions on the message receiving side also increases the number of sessions between the relay system and the message receiving side, which in turn increases the management cost of session management on the message receiving side.

[0008] This invention has been made in consideration of the above points, and aims to propose a message delivery system and method that can suppress the increase in session management costs associated with an increase in the number of topic subscriptions on the message receiving side. [Means for solving the problem]

[0009] To solve the above problem, the present invention provides a message distribution system in which messages transmitted from a transmitting device are managed by topic in a relay device, and messages of topics subscribed to by a receiving device are distributed from the relay device to the receiving device, wherein a topic editor device is provided to manage the topics, and when the number of topics subscribed to by the receiving device exceeds a predetermined first threshold, the receiving device sends a merge request to the topic editor device requesting the merger of each of the topics it subscribes to, and the topic editor device instructs the relay device to merge each of the topics requested to be merged in the received merge request. Both devices begin subscribing to each of the topics requested to be integrated in the integration request and transmit each received message to the relay device. At the same time, they instruct the receiving device that sent the integration request to subscribe to the integrated topic which is a merged topic formed by integrating each of the topics requested to be integrated in the integration request. The relay device generates the integrated topic which is a merged topic formed by integrating each of the specified topics in accordance with the instructions from the topic editor device, manages the messages of each topic which constitute the integrated topic as messages of the integrated topic, and distributes the messages of the integrated topic to the receiving device which subscribes to the integrated topic.

[0010] Furthermore, the present invention relates to a message distribution method performed in a message distribution system in which messages transmitted from a transmitting device are managed by topic in a relay device, and messages of the topics subscribed to by a receiving device are distributed from the relay device to the receiving device, wherein the message distribution system has a topic editor device for managing the topics, and the first step is that when the number of topics subscribed to by the receiving device exceeds a predetermined first threshold, the receiving device sends an integration request to the topic editor device requesting the integration of each of the topics it subscribes to, and the topic editor device transmits the integration of each of the topics requested to be integrated in the received integration request to the relay device. The system is configured to include a second step in which the relay device issues instructions, starts subscribing to each of the topics requested to be integrated in the integration request, and transmits each received message to the relay device, while instructing the receiving device that sent the integration request to subscribe to an integrated topic which integrates each of the topics requested to be integrated in the integration request; and a third step in which the relay device generates an integrated topic which integrates each of the specified topics in accordance with instructions from the topic editor device, manages the messages of each of the topics which constitute the integrated topic as messages of the integrated topic, and delivers the messages of the integrated topic to the receiving device which subscribes to the integrated topic.

[0011] According to the message distribution system and method of the present invention, when the number of topics subscribed to by a receiving device exceeds a first threshold, these topics are merged into a single unified topic, thereby preventing the number of sessions between the relay device and the receiving device from exceeding the first threshold. [Effects of the Invention]

[0012] According to the present invention, a message delivery system and method can be realized that can suppress the increase in session management costs associated with an increase in the number of topic subscriptions on the message receiving side. [Brief explanation of the drawing]

[0013] [Figure 1] This is a block diagram illustrating the overall configuration of the message delivery system according to this embodiment. [Figure 2] This block diagram schematically shows the message flow in a conventional message delivery system that applies the Pub / Sub model. [Figure 3] This is a block diagram illustrating the topic integration and deintegration function installed in the message distribution system of this embodiment. [Figure 4] This is a block diagram illustrating the topic integration and deintegration function installed in the message distribution system of this embodiment. [Figure 5] This is a block diagram illustrating the topic integration and deintegration function installed in the message distribution system of this embodiment. [Figure 6] This is a block diagram illustrating the topic integration and deintegration function installed in the message distribution system of this embodiment. [Figure 7] This is a block diagram illustrating the topic integration and deintegration function installed in the message distribution system of this embodiment. [Figure 8] This is a block diagram illustrating the topic integration and deintegration function installed in the message distribution system of this embodiment. [Figure 9] This block diagram shows the logical configuration of the message delivery system of this embodiment regarding the topic integration and unintegration function. [Figure 10] (A) and (B) are diagrams illustrating examples of the structure of a subscription status list. [Figure 11] This is a diagram illustrating an example of the structure of a reference topic list. [Figure 12] This is a diagram illustrating an example of the structure of an integrated requirements list. [Figure 13] This is a diagram illustrating an example of the structure of the integration status list. [Figure 14] This is a diagram illustrating an example of the structure of a list of planned changes. [Figure 15]It is a flowchart showing the processing procedure of topic integration request processing. [Figure 16] It is a flowchart showing the processing procedure of integration management processing. [Figure 17] It is a flowchart showing the processing procedure of subscription switching processing. [Figure 18] It is a flowchart showing the processing procedure of topic integration cancellation request processing. [Figure 19] It is a flowchart showing the processing procedure of integration cancellation processing. [Figure 20] It is a flowchart showing the processing procedure of subscription switching processing. [Figure 21] It is a block diagram for explaining a specific example of a series of processes performed in a message distribution system based on the topic integration / integration cancellation function of the present embodiment. [Figure 22] It is a block diagram for explaining a specific example of a series of processes performed in a message distribution system based on the topic integration / integration cancellation function of the present embodiment. [Figure 23] It is a block diagram for explaining a specific example of a series of processes performed in a message distribution system based on the topic integration / integration cancellation function of the present embodiment. [Figure 24] It is a block diagram for explaining a specific example of a series of processes performed in a message distribution system based on the topic integration / integration cancellation function of the present embodiment. [Figure 25] It is a block diagram for explaining a specific example of a series of processes performed in a message distribution system based on the topic integration / integration cancellation function of the present embodiment. [Figure 26] It is a block diagram for explaining a specific example of a series of processes performed in a message distribution system based on the topic integration / integration cancellation function of the present embodiment.

Embodiment for Implementing the Invention

[0014] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

[0015] (1) Configuration of the message distribution system according to this embodiment In Figure 1, 1 represents the message distribution system of this embodiment, which employs a Pub / Sub model as a whole. This message distribution system 1 comprises one or more message transmitting devices 2, a message broker device 4 and a topic editor device 5 interconnected via a first network 3, and a message receiving device 7 connected to these message broker device 4 and topic editor device 5 via a second network 6.

[0016] Message transmission device 2 is a transmission device that transmits, for example, operational data of manufacturing equipment installed in a factory or operational data of construction machinery operating at a construction site as messages at regular intervals. However, message transmission device 2 may also transmit data or information other than operational data.

[0017] The message transmission device 2 is equipped with one or more publishers 10. The publishers 10 are software or hardware that have the function of sending messages to the message broker device 4 periodically or irregularly.

[0018] The message broker device 4 is a relay device that relays messages transmitted from the publisher 10 between the message transmission device 2 and the message receiving device 7, and consists of a general-purpose server device equipped with information processing devices such as a CPU (Central Processing Unit) 11, memory 12, storage device 13, and communication device 14.

[0019] The CPU 11 is a processor that controls the operation of the entire message broker device 4. The memory 12 is composed of, for example, volatile semiconductor memory and is used as the working memory of the CPU 11. Furthermore, the storage device 13 is composed of, for example, a non-volatile, high-capacity storage device such as a hard disk drive or an SSD (Solid State Drive) and is used to hold programs and data that needs to be stored long-term.

[0020] When the message broker device 4 is started up or as needed, the necessary programs are loaded from the storage device 13 into memory 12. The CPU 11 then executes the programs loaded into memory 12, thereby performing various processes for the message broker device 4 as a whole, as described later.

[0021] The communication device 14 is composed of, for example, a NIC (Network Interface Card) and performs protocol control when communicating with the message transmission device 2 via the first network 3 and when communicating with the message receiving device 7 via the second network 6.

[0022] On the other hand, the topic editor device 5 is a computer device that has the function of performing the necessary processing related to the integration and unintegration of topics, as described later, and consists of a general-purpose server device equipped with information processing devices such as a CPU 15, memory 16, storage device 17, and communication device 18.

[0023] The message receiving device 7 is a computer device that receives messages transmitted from the publisher 10 of the message transmitting device 2 and relayed by the message broker device 4. As described later, the message receiving device 7 is equipped with various applications 36 (Figures 3 to 8) that have functions such as analyzing the operating status of monitored manufacturing equipment and construction machinery based on received messages (in this case, operational data), and extracting alarm information and distributing it to users. This message receiving device 7 is also composed of a general-purpose server device equipped with information processing devices such as a CPU 19, memory 20, storage device 21, and communication device 22.

[0024] The CPUs 15, 19, memories 16, 20, storage devices 17, 21, and communication devices 18, 22 of the topic editor device 5 and the message receiving device 7 have the same functions as the CPU 11, memory 12, storage device 13, or communication device 14 of the message broker device 4, respectively, so their explanation is omitted here.

[0025] (2) Topic integration and unintegration function Next, we will explain the topic integration and deintegration functions installed in this message distribution system 1. In this context, we will describe a conventional message distribution system 30 that applies the Pub / Sub model, referring to Figure 2.

[0026] As shown in Figure 2, in a conventional message distribution system 30, the message broker device 4 stores messages sent from the publisher 31 of the message transmission device in a message queue 33 for the topic corresponding to that message, which is located inside the device.

[0027] Furthermore, the message receiving device 34 is provided with subscribers 35, each associated with a topic that the message receiving device 34 wishes to subscribe to. Each subscriber 35 accesses the message broker device 4 periodically or irregularly to read messages from the message queue 33 of the topic associated with it (in the case of a PULL type), and outputs the read messages to the application 36 implemented in the message receiving device 34.

[0028] In conventional message distribution systems 30 that apply such a Pub / Sub model, if the number of topics to subscribe to increases, for example, by increasing the number of applications 36 implemented in the message receiving device 34, the number of sessions between the message broker device 4 and the message receiving device 34 increases, which leads to a problem in that the load on the message receiving device 34 that manages these sessions and the cost of managing sessions in the message receiving device 34 increase.

[0029] Therefore, in the message distribution system 1 of this embodiment, as shown in Figure 3, where the corresponding parts in Figure 2 are denoted by the same reference numerals, each message receiving device 7 is equipped with a manager 40 that monitors the number of topics subscribed to in that message receiving device 7 (hereinafter referred to as the number of topic subscriptions).

[0030] Then, when the number of topics subscribed to by the message receiving device 7 on which the manager 40 is implemented (hereinafter referred to as the self-message receiving device) 7 exceeds a predetermined threshold (hereinafter referred to as the topic subscription threshold), the manager 40 sends a topic merge request to the topic editor device 5 requesting the merger of each topic that the self-message receiving device 7 is currently subscribed to (S1).

[0031] The topic editor device 5 manages topic merger requests received from the manager of the message receiving device 7 up to that point, and when the number of topic merger requests with the same content exceeds a predetermined threshold (hereinafter referred to as the merger request threshold), it instructs the message broker device 4 to merge each topic specified in that topic merger request (S2).

[0032] Upon receiving this instruction, the message broker device 4 generates a new topic (hereinafter referred to as the integrated topic) by integrating each topic requested for integration in the topic integration request, and creates a new message queue 33 associated with that integrated topic ("Topic 1000" in Figure 3). Hereafter, the message queue 33 created in this manner will be referred to as the message queue 33 for the integrated topic.

[0033] The topic editor device 5 then starts subscribing to each of the topics that have been integrated in response to the topic integration request, as shown in Figure 4 (S3). Specifically, the topic editor device 5 periodically reads messages from each of the topics that make up the integrated topic from the corresponding message queue 33 of the message broker device 4, and stores these read messages in a message queue 37 that it has generated internally, associating them with the integrated topic.

[0034] The topic editor device 5 also periodically transmits each message stored in the message queue 37 to the message broker device 4 (S4). Thus, the message broker device 4 stores each of these integrated topic messages provided by the topic editor device 5 in the integrated topic message queue 33 that was generated in conjunction with that integrated topic.

[0035] In parallel with this, as shown in Figure 5, the topic editor device 5 notifies each manager 40 that has previously sent a topic integration request requesting the integration of each of the topics integrated as described above, that the requested topics will be integrated, and provides identification information of the integrated topic formed by integrating these topics (S5).

[0036] Upon receiving this notification, Manager 40 begins subscribing to the integrated topic and performs a subscription switching process to cancel subscriptions to the individual topics integrated into that integrated topic.

[0037] Specifically, the manager 40 creates new subscribers 35 within its message receiving device 7 that are associated with the integrated topic (hereinafter referred to as integrated topic subscribers). In Figure 5, "Subscriber A" and "Subscriber B" correspond to these. The manager 40 also deletes the subscribers 35 that were previously located within its message receiving device 7 and associated with each of the topics integrated into the integrated topic (S6). In Figure 5, "Subscriber 001" to "Subscriber 050" and "Subscriber 051" to "Subscriber 100" correspond to these.

[0038] As a result, in the message receiving device 7 where the integrated topic subscriber 35 was generated, each message stored in the integrated topic message queue 33 in the message broker device 4 is read by the integrated topic subscriber 35 and output to the application 36 (S7).

[0039] On the other hand, if the manager 40 receives input indicating that its message receiving device 7 has been operated in a predetermined manner and has stopped subscribing to some of the topics that make up the integrated topic (integrated topic) as described above, it sends a request to withdraw the topic integration request (hereinafter referred to as a topic integration withdrawal request) to the topic editor device 5, as shown in Figure 6 (S8).

[0040] The topic editor device 5, upon receiving this topic merge withdrawal request, determines whether the number of message receiving devices 7 currently subscribing to the merged topic that is the subject of the topic merge withdrawal request (hereinafter referred to as the merged topic to be removed) (excluding the message receiving device 7 that sent the topic merge withdrawal request) is equal to or greater than a pre-set threshold (hereinafter referred to as the merge removal threshold).

[0041] If the topic editor device 5 obtains a positive result in this determination, it instructs the message broker device 4 to unsubscribe from the integrated topic, as shown in Figure 7 (S9). Thus, in response to this instruction, the message broker device 4 performs processing to stop subscribing to the integrated topic, such as deleting the message queue 33 for the corresponding integrated topic.

[0042] The topic editor device 5 also sends a notice to the manager 40 of each message receiving device 7 that had been subscribing to the integrated topic, informing them that the integration of the integrated topic will be terminated (S10).

[0043] Upon receiving this unintegration notification, the manager 40 regenerates subscribers 35 within its message receiving device 7 for each topic that it wishes to continue subscribing to among the topics that make up the integrated topic, and deletes the subscriber 35 for the integrated topic that is being unintegrated, thereby stopping the subscription to the integrated topic (S11).

[0044] As a result, as shown in Figure 8, each message receiving device 7 then reads the messages for the necessary topics from the corresponding message queue 33 of the message broker device 4, based on the subscribers 35 generated at that time, and these messages are output to the coordinating application 36.

[0045] As a means to realize the function of autonomously integrating and unintegrating topics as described above (hereinafter referred to as the topic integration / unintegration function), in this embodiment, as shown in Figure 9, the message broker device 4 is provided with a topic management unit 41 and a message distribution unit 42. In addition, the storage device 13 of the message broker device 4 stores a topic list 43 and a subscriber list 44 as management information.

[0046] The topic list 43 is a list that registers the correspondence between the message queues 33 (Figures 3 to 8) created in the message broker device 4 and the topics, and the subscriber list 44 is a list that registers the relationship between each topic and each subscriber 35. A detailed explanation of these topic list 43 and subscriber list 44 will be omitted.

[0047] The topic management unit 41 and the message distribution unit 42 are functional units that are realized when the CPU 11 (Figure 1) of the message broker device 4 executes the corresponding program loaded from the storage device 13 (Figure 1) into the memory 12 (Figure 1).

[0048] The topic management unit 41 has the function of managing the correspondence between message queues 33 created in the message broker device 4 and the topics corresponding to each of these message queues 33 using a topic list 43. The topic management unit 41 also has the function of managing the correspondence between each topic and the subscribers 35 that subscribe to that topic using a subscriber list 44.

[0049] Furthermore, the message distribution unit 42 refers to the topic list 43 and the subscriber list 44, stores and manages messages sent from the publisher 10 of the message transmission device 2 in the corresponding message queue 33 (Figures 3 to 8), and also has the function of distributing messages stored in the corresponding message queue 33 to the subscriber 35 of the message receiving device 7 in response to requests from the subscriber 35.

[0050] Furthermore, the message distribution unit 42 also has the function of creating the aforementioned integrated topic message queue 33 in response to a request from the integrated management unit 48 (Figure 9) of the topic editor device 5, and then storing the messages of each topic constituting the integrated topic given by the topic editor device 5 in the integrated topic message queue 33.

[0051] On the other hand, the message receiving device 7 has a manager 40 implemented in addition to one or more subscribers 35, as described above. The subscribers 35 and the manager 40 are functional units that are realized when the CPU 19 (Figure 1) of the message receiving device 7 executes the corresponding program loaded from the storage device 21 (Figure 1) into the memory 20 (Figure 1).

[0052] The subscriber 35 periodically accesses the message broker device 4, reads messages from the message queue 33 of the topic associated with itself, and outputs the read messages to a cooperating application 36 (Figures 3 to 8) implemented in its own message receiver device 7.

[0053] The manager 40 also includes an integrated request function unit 40C, a subscription switching instruction function unit 40A, and a subscription switching function unit 40B, and stores and manages the subscription status list 45 and the reference topic list 46 in the storage device 21.

[0054] The subscription status list 45 is a list used to manage the current topic subscription status of the local message receiving device 7, and as shown in Figure 10(A), it is configured to include a subscriber name column 45A, a subscribed topic name column 45B, and a subscription flag column 45C. In the subscription status list 45, one record (row) corresponds to one topic that the local message receiving device 7 is subscribed to.

[0055] The subscription topic name field 45B stores the name of the corresponding topic that the message receiving device 7 is subscribed to (topic name), and the subscriber name field 45A stores the name of the subscriber associated with that topic (subscriber name).

[0056] The subscription flag field 45C also stores a flag (hereinafter referred to as the subscription flag) that indicates whether the message receiving device 7 is currently subscribed to the corresponding topic. In this embodiment, the subscription flag is set to "1" if the message receiving device 7 is subscribed to the corresponding topic, and to "0" if the subscription to that topic has been canceled.

[0057] Therefore, in the example shown in Figure 10(A), the corresponding message receiving device 7 indicates that, for example, subscriber 35 named "Subscriber 1" is associated with the topic "Topic 1" and is currently subscribing to the topic "Topic 1" (the subscription flag is "1").

[0058] Furthermore, if the message receiving device 7 starts subscribing to a unified topic that combines the topics it had previously subscribed to, a record of that unified topic will be added to the subscription status list 45, as shown in Figure 10(B). At this time, the records of each topic that have been integrated into the unified topic are not deleted, and the subscription flags for these topics are updated to "0".

[0059] The reference topic list 46 is a list used to manage the topics that the local message receiver 7 is currently subscribed to, and all topics that the local message receiver 7 is currently subscribed to are registered therein. As shown in Figure 11, this reference topic list 46 is configured to include a number column 46A and a subscribed topic name column 46B. In the reference topic list 46, one record (row) corresponds to one topic that the local message receiver 7 is currently subscribed to.

[0060] The subscribed topic name field 46B stores the topic name of the corresponding topic that the message receiving device 7 is currently subscribed to. The number field 46A stores the number assigned to the corresponding topic on the reference topic list 46. In this embodiment, sequential numbers starting from "1" are used as such numbers. Therefore, in the example in Figure 11, it is shown that the corresponding message receiving device 7 is currently subscribed to three topics: "Topic 1", "Topic 2", and "Topic 3".

[0061] The integration request function unit 40C is a function unit that monitors the number of topics subscribed to by the message receiving device 7 using the reference topic list 46, and sends a topic integration request to the topic editor device 5 when the number of topics subscribed exceeds the aforementioned topic subscription threshold. The integration request function unit 40C also has the function of sending the aforementioned topic integration withdrawal request to the topic editor device 5 when an operation to delete subscriptions to some of the topics constituting the integrated topic is input.

[0062] The subscription switching instruction unit 40A is a functional unit that, when the topic editor device 5 notifies the subscription editor device 40A that the integration of integrated topics has been canceled, as described later, sends a subscription switching instruction to the subscription switching unit 40B, instructing the subscription to switch from the integrated topic to each of the individual topics that make up the integrated topic and which the subscription should continue.

[0063] Furthermore, the subscription switching function unit 40B is a function unit that generates necessary subscribers 35 or deletes unnecessary subscribers 35 in response to subscription switching instructions given by the subscription switching instruction function unit 40A.

[0064] On the other hand, the topic editor device 5 is equipped with a message processing unit 47 and an integrated management unit 48 as functional units. The storage device 17 of the topic editor device 5 also stores an integrated request list 49, an integrated status list 50, and a change schedule list 51 as management information.

[0065] The integration request list 49 is a list used to manage topic integration requests received by the topic editor device 5 to date, and as shown in Figure 12, it is composed of an integration request topic column 49A, a requesting manager name column 49B, and a request number column 49C. In the integration request list 49, one record (row) corresponds to one type of combination of topics (hereinafter referred to as a topic combination) that have been requested to be integrated in topic integration requests received by the topic editor device 5 to date.

[0066] The integration request topic field 49A stores the topic names of all topics that make up the corresponding topic combination, and the requesting manager name field 49B stores the names of each manager 40 that have so far requested the integration of topics in that topic combination. Furthermore, the number of requests field 49C stores the number of managers 40 that are currently requesting the integration of topics in that topic combination.

[0067] Therefore, in the example shown in Figure 12, topic merger requests to merge "Topic 1," "Topic 2," and "Topic 3" are sent from "Manager 1" and "Manager 4," respectively, and it is shown that at this time, there are "2" managers requesting the merger of these topics.

[0068] The Integration Status List 50 is a list used to manage the current integration status of topics, and as shown in Figure 13, it consists of an Integration Request Topic column 50A, a Requesting Manager Name column 50B, an Integrated Topic Name column 50C, and a Request Count column 50D. In the Integration Status List 50, one record (row) corresponds to one existing integration topic.

[0069] The "Integrated Topic Name" field 50C stores the topic name assigned to the corresponding integrated topic, and the "Integration Request Topic" field 50A stores the topic names of each topic that were integrated into that integrated topic. The "Requesting Manager Name" field 50B stores the manager names of each manager 40 that requested the integration of these topics, and the "Number of Requests" field 50D stores the number of managers 40 that have requested the creation of such an integrated topic at that time.

[0070] Therefore, in the example in Figure 13, it is shown that a merged topic named "Topic 5," which is a combination of three topics, "Topic 1," "Topic 2," and "Topic 3," still exists, and that two managers, "Manager 1" and "Manager 4," are still requesting the continued existence of that merged topic.

[0071] The change schedule list 51 is a list used by the topic editor device 5 to manage topic merge withdrawal requests received, and as shown in Figure 14, it is configured to include a merge request topic column 51A, a requesting manager name column 51B, and a reference number column 51C. In the change schedule list 51, one record (row) corresponds to one type of topic merge withdrawal request where the merge topic to be withdrawn (merged topic to be withdrawn) is the same.

[0072] The integration request topic field 51A stores the topic names of each topic that make up the integrated topic for which unintegration was requested in the corresponding topic integration withdrawal request, and the requesting manager name field 51B stores the manager names of all managers 40 that requested the unintegration of that integrated topic. Furthermore, the reference count field 51C stores the current number of subscriptions to that integrated topic.

[0073] Therefore, in the example in Figure 14, regarding a topic merger withdrawal request targeting a merged topic formed by merging three topics, "Topic 1," "Topic 2," and "Topic 3," given by Manager 40, "Manager 1," it is indicated that currently "1" message receiving device 7 is subscribing to that merged topic.

[0074] The message processing unit 47 is generated for each integrated topic by the integrated management unit 48 (described later), and has the function of reading and acquiring messages for each topic constituting the corresponding integrated topic from the message broker device 4, and transmitting these acquired messages to the message distribution unit 42 of the message broker device 4. These messages are then stored in the integrated topic message queue 33 provided in the message broker device 4 to correspond to the integrated topic.

[0075] Furthermore, the integrated management unit 48 manages topic integration requests given by the manager 40 of each message receiving device 7, and when the number of times the same topic integration request has been received exceeds the integration request threshold, it has the function of executing a process to integrate each corresponding topic according to that topic integration request, or giving an instruction to the manager 40 that sent the topic integration request to switch the topics it subscribes to to the integrated topic generated by such integration.

[0076] Furthermore, the integrated management unit 48 manages topic merger withdrawal requests given by the managers 40 of each message receiving device 7, and if the current number of subscribers to the merged topic is less than the merger cancellation threshold, it executes a process to cancel the merged topic, and also has the function of giving instructions to the managers 40 of the message receiving devices 7 that are subscribed to the merged topic to switch the topics they subscribe to from the merged topic to the individual topics that make up the merged topic.

[0077] (3) Various processes performed in relation to the topic integration and unintegration function Next, we will explain the specific processing details of the various processes performed in this message distribution system 1 in relation to the topic integration and deintegration functions described above. In the following, the processing entity of each process will be described as a program ("...part"), but it goes without saying that in practice, the corresponding CPUs 15 and 19 will execute the process based on that program.

[0078] (3-1) Topic Integration Request Processing Figure 15 shows the flow of a series of processes (hereinafter referred to as topic integration request processing) executed by the integrated request function unit of the manager 40 implemented in the message receiving device 7 when a user performs a predetermined operation on the message receiving device 7 and adds a topic to subscribe to.

[0079] When a topic that the message receiving device 7 should subscribe to is added, the integrated request function unit 40C starts the topic integration request processing shown in Figure 15. First, the integrated request function unit 40C obtains the subscription status list 45 (Figure 10(A)) by reading it from the storage device 21 (Figure 1) (S1).

[0080] Next, the integrated request function unit 40C determines, based on the acquired subscription status list 45, whether the current number of subscriptions to a topic in its own message receiving device 7 is equal to or greater than the aforementioned topic subscription threshold (S2). If the integrated request function unit 40C obtains a negative result in this determination, it terminates the topic integration request process.

[0081] In response, if the integration request function unit 40C obtains a positive result in the judgment in step S2, it sends a topic integration request to the topic editor device 5 requesting the integration of all topics currently subscribed to by its own message receiving device 7 (S3), and then terminates the topic integration request process.

[0082] (3-2) Integrated Management Processing On the other hand, Figure 16 shows the flow of a series of processes (hereinafter referred to as the integrated management process) executed by the integrated management unit 48 (Figure 9) of the topic editor device 5 upon receiving a topic integration request.

[0083] When the integrated management unit 48 receives a topic integration request, it starts the integrated management process shown in Figure 16, and first updates the integration request list 49 (Figure 12) (S10).

[0084] Specifically, if the integrated management unit 48 finds that a topic integration request with the same content as the topic integration request received this time (where all topics to be integrated are the same) is already registered in the integration request list 49, it adds the manager name of the manager 40 that sent the topic integration request this time to the requesting manager name field 49B (Figure 12) of the record corresponding to that topic integration request, and also increments the number stored in the request count field 49C (Figure 12) of that record (increases by 1).

[0085] Furthermore, if the integrated management unit 48 finds that no topic integration request with the same content as the topic integration request received this time is registered in the integration request list 49, it reserves an unused record in the integration request list 49 and stores the topic names of each topic that is being requested to be integrated in the topic integration request received this time in the integration request topic field 49A (Figure 12) of that record. The integrated management unit 48 also stores the manager name of the manager 40 that sent the topic integration request in the requesting manager name field 49B of that record, and stores "1" in the number of requests field 49C of that record.

[0086] Next, the integrated management unit 48 refers to the request count column 49C of the record updated in step S10 and determines whether the number stored in the request count column 49C is equal to or greater than the integrated request threshold (S11). If the integrated management unit 48 obtains a negative result in this determination, it terminates the integrated management process.

[0087] In response, if the integrated management unit 48 obtains a positive result in the judgment in step S11, it instructs the message broker device 4 to generate an integrated topic that integrates all topics requested for integration in the topic integration request received this time (S12). Thus, the topic management unit 41 of the message broker device 4, upon receiving this instruction, creates the integrated topic and registers it in the topic list 43 (Figure 9), and also generates an integrated topic message queue 33 (Figures 3 to 8) corresponding to that integrated topic.

[0088] Furthermore, the integrated management unit 48 generates a message processing unit 47 corresponding to the integrated topic and a message queue 37 (Figures 4 to 6) associated with the integrated topic within the topic editor device 5 (S13). Subsequently, the message processing unit 47 stores the messages of each topic constituting the integrated topic, which were read from the message broker device 4, into the corresponding message queue 37, and transmits the messages stored in the message queue 37 to the message broker device 4 as appropriate.

[0089] Next, the integrated management unit 48 identifies each manager 40 that has sent a topic integration request (including the current topic integration request) with the same content as the topic integration request that triggered the start of the current integrated management process, by referring to the integration request list 49, and sends an integration completion notification and subscription switching flag information to these identified managers 40 indicating that the integration of each requested topic has been completed (S14).

[0090] The integration completion notification also includes information on the topic names of each integrated topic and the topic name of the integrated topic. Furthermore, the "subscription switching flag information" here refers to information indicating how far the messages of each integrated topic have been read by the message receiving device 7, which is implemented in the manager 40 to which the integration completion notification was sent. The integration management unit 48 obtains this subscription switching flag information for each message receiving device 7 from the message broker device 4 and transmits this obtained subscription switching flag information to the corresponding manager 40.

[0091] Next, the integrated management unit 48 updates the integration status list 50 (Figure 13) (S15). Specifically, the integrated management unit 48 reserves unused records from the integration status list 50, stores the topic names of each topic integrated in the integration request topic field 50A (Figure 13) of that record, and stores the manager names of all managers 40 that requested the integration of these topics in the requesting manager name field 50B (Figure 13) of that record. The integrated management unit 48 also stores the topic name assigned to the integrated topic created by this integration in the post-integration topic name field 50C of that record, and stores the number of topic reception requests requesting the integration of these topics received so far in the request count field 50D of that record.

[0092] The integrated management unit 48 then terminates this integrated management process.

[0093] (3-3) Subscription switching process Figure 17 shows the flow of a series of processes (hereinafter referred to as the subscription switching process) executed by the subscription switching function unit 40B (Figure 9) of the manager 40, which receives the aforementioned integration completion notification and subscription switching flag information transmitted from the topic editor device 5.

[0094] When manager 40 receives the integration completion notification and subscription switching flue information, manager 40's subscription switching instruction function unit 40A sends a subscription switching instruction to subscription switching function unit 40B. This subscription switching instruction also includes information on the topic names of each integrated topic and the topic name of the integrated topic.

[0095] When the subscription switching function unit 40B receives this subscription switching instruction, it starts the subscription switching process shown in Figure 17, and first generates a subscriber 35 (Figure 9) corresponding to the integrated topic created at that time within its own message receiving device 7 (S20).

[0096] Next, the subscription switching function unit 40B reads the subscription switching flag information and sets the message that should be started for each topic constituting the integrated topic to the subscriber 35 generated in step S20 (S21).

[0097] Next, the subscription switching function unit 40B deletes all subscribers 35 within its own message receiving device 7 that were provided for each topic integrated into the integrated topic (S22), and then terminates the subscription switching process.

[0098] (3-4) Processing of Topic Integration Withdrawal Requests Figure 18 shows the flow of a series of processes (hereinafter referred to as the topic integration withdrawal request process) executed by the integrated request function unit 40C of the manager 40 implemented in the message receiving device 7 when the message receiving device 7 is operated by a user to instruct it to unsubscribe from some of the topics that make up the integrated pick that it is currently subscribed to.

[0099] When a user cancels their subscription to a topic, the integrated request function unit 40C starts the topic integration withdrawal request process shown in Figure 18. First, the integrated request function unit 40C sends a topic integration withdrawal request to the topic editor device 5, specifying the integrated topic that its message receiving device 7 is currently subscribed to (S30).

[0100] Next, the integrated request function unit 40C determines whether the total number of topics subscribed to by the message receiving device 7, other than the topic for which unsubscription has been instructed (hereinafter referred to as the unsubscription target topic), is equal to or greater than the aforementioned topic subscription threshold (S31). If the integrated request function unit 40C obtains a negative result in this determination, it terminates the topic integration withdrawal request process.

[0101] In response, if the integration request function unit 40C obtains a positive result in the judgment in step S31, it sends a topic integration request to the topic editor device 5 requesting the integration of each topic that the message receiving device 7 is subscribed to, excluding the topic to be unsubscribed (S32), and then terminates the topic integration withdrawal request process.

[0102] Furthermore, based on the topic integration request sent to the topic editor device 5 in step S32, the topic editor device 5 executes the integrated management process described above for Figure 16, and depending on the situation, it also executes the subscription switching process described above for Figure 17.

[0103] (3-5) Unintegration process Figure 19 shows the flow of a series of processes (hereinafter referred to as the unintegration process) executed by the integration management unit 48 of the topic editor device 5 upon receiving the aforementioned topic integration withdrawal request.

[0104] When the integrated management unit 48 receives a request to withdraw topic integration, it starts the integration removal process shown in Figure 19, and first updates the planned change list 51 (Figure 14) (S40).

[0105] Specifically, if a topic merge withdrawal request with the same content (same merged topic to be unmerged) is already registered in the change schedule list 51, the integrated management unit 48 stores the manager name of the manager 40 that sent the topic merge withdrawal request in the requesting manager name field 51B (Figure 14) of the record corresponding to that topic merge withdrawal request. The integrated management unit 48 also obtains the number of message receiving devices 7 that subscribe to the merged topic for which unmerging is requested in the topic merge withdrawal request from the merged status list 50, and stores the number obtained by subtracting "1" (the number of message receiving devices 7 on which the manager 40 that sent the topic merge withdrawal request is implemented) in the reference count field 51C of the record.

[0106] Furthermore, if no topic merge withdrawal request with the same content as the topic merge withdrawal request received this time is registered in the change schedule list 51, the integrated management unit 48 reserves an unused record in the change schedule list 51 and stores the topic names of each topic that make up the merged topic for which the merger cancellation is requested in the topic merge withdrawal request received this time in the merger request topic field 49A (Figure 12) of that record. In addition, the integrated management unit 48 obtains the number of message receiving devices 7 that are subscribed to the merged topic for which the merger cancellation is requested in the topic merge withdrawal request this time from the merger status list 50 and stores the number obtained by subtracting "1" from that number in the reference count field 51C of the record.

[0107] Next, the integrated management unit 48 sends a merge cancellation notice to all managers 40 whose manager names are stored in the requesting manager name field 51B of the record corresponding to the topic merge cancellation request in the change schedule list 51, informing them that they should cancel the merged topic for which the merge cancellation request was requested (S41).

[0108] Next, the integrated management unit 48 determines whether the number stored in the reference count column 51C of the record in the change schedule list 51 updated in step S40 (corresponding to the number of message receiving devices 7 currently subscribing to the integrated topic for which the unintegration is being requested in this topic unintegration withdrawal request) is equal to or greater than the unintegration threshold for unintegrating the integrated topic (S42).

[0109] The integrated management unit 48 then terminates the unintegration process if it obtains a positive result from this judgment. Therefore, in this case, the integrated topic for which unintegration was requested due to such topic unintegration withdrawal request is not unintegrated.

[0110] In response, if the integrated management unit 48 obtains a negative result in the judgment in step S42, it executes a process to cancel the integrated topic for which cancellation of integration has been requested due to the topic integration withdrawal request (S43-S45).

[0111] Specifically, the integrated management unit 48 first sends a topic deletion request to the message broker device 4 requesting that the integrated topic whose integration has been requested to be unintegrated by the topic integration withdrawal request be unintegrated (S43). Thus, when the message broker device 4 receives this topic deletion request, it deletes the message queue 33 for the integrated topic associated with the specified integrated topic, and also deletes the integrated topic from the topic list 43 (Figure 9).

[0112] Furthermore, the integrated management unit 48 deletes the message processing unit 47 (Figure 9) and message queue 37 (Figures 4-6) located within the topic editor device 5, corresponding to the integrated topic for which the unintegration has been requested in the topic unintegration withdrawal request (S44). Then, the integrated management unit 48 sends an unintegration completion notice to each manager 40 that sent the unintegration notice in step S42, indicating that the unintegration of the integrated topic has been completed (S45).

[0113] Next, the integrated management unit 48 updates the integration status list 50 (Figure 13) (S46). Specifically, the integrated management unit 48 deletes the records in the integration status list 50 that correspond to the integrated topics that have been unintegrated as described above.

[0114] The integrated management unit 48 also updates the change schedule list 51 (Figure 14) (S47). Specifically, the integrated management unit 48 deletes the records in the change schedule list 51 that correspond to the integrated topics whose integration was undone as described above.

[0115] The integrated management unit 48 then terminates this unintegration process.

[0116] (3-6) Subscription switching instruction processing Figure 20 shows the flow of a series of processes (hereinafter referred to as the subscription switching instruction process) executed by the subscription switching instruction function unit 40A of the manager 40 upon receiving the unintegration notification sent by the integrated management unit 48 in step S42 of the unintegration process described above in Figure 19.

[0117] When the subscription switching instruction unit 40A receives such a merger cancellation notification, it starts the subscription switching instruction process shown in Figure 20, and first determines whether its own message receiving device 7 is subscribed to the merger topic whose merger is to be canceled (S50).

[0118] Specifically, the subscription switching instruction function unit 40A determines whether the topic name of the merged topic whose merge is to be canceled, as notified by the merge cancellation notice, is stored in the subscription topic name field 45B (Figure 10(A)) of any record in the subscription status list 45 (Figure 10(A)).

[0119] If the subscription switching instruction function unit 40A obtains a negative result in this determination, it terminates the subscription switching instruction process.

[0120] In response, if the subscription switching instruction function unit 40A obtains a positive result in the judgment in step S50, it updates the reference topic list 46 (Figure 11) (S51). Specifically, the subscription switching instruction function unit 40A removes the integrated topic whose integration is to be canceled from the reference topic list 46, and retrieves each topic constituting the integrated topic from the subscription status list 45 and registers them in the reference topic list 46.

[0121] Next, the subscription switching instruction unit 40A instructs the subscription switching function unit 40B to switch the topics to be subscribed to from the current unsubscribed integrated topic to the individual topics that make up the unsubscribed integrated topic (but not the topics being unsubscribed from) (S52). The subscription switching instruction unit 40A then terminates this subscription switching instruction process.

[0122] Upon receiving this subscription switching instruction, the subscription switching function unit 40B executes the subscription switching process described above for Figure 17. In this process, step S20 generates subscribers 35 (Figure 9) for each topic that constitutes the merged topic from which the merge has been removed, and step S22 deletes the subscribers 35 for the merged topic from which the merge has been removed.

[0123] (4) Specific examples Next, with reference to Figures 21 to 26, a specific example of a series of processes executed in the message distribution system 1 based on the topic integration and deintegration function according to this embodiment will be described.

[0124] In Figures 21 to 26, "Subscriber 1" to "Subscriber 5" are subscribers 35 configured to subscribe to the same numbered topic ("1" to "5") from the topics "Topic 1" to "Topic 5," respectively, and "Manager 1" to "manager 4" are managers 40 implemented in different message receiving devices 7.

[0125] Furthermore, each message receiving device 7 with "manager 1" or "manager 4" implemented subscribes to "Topic 1" through "Topic 3," a message receiving device 7 with "manager 2" implemented subscribes to "Topic 1," "Topic 2," and "Topic 4," and a message receiving device 7 with "manager 3" implemented subscribes to "Topic 1" and "Topic 2."

[0126] Furthermore, in Figures 21 to 26, the integration request threshold set for the topic editor device 5 is "2", and the integration deintegration threshold is "1".

[0127] Here, if the topic subscription threshold set for each message receiving device 7 is "3", as shown in Figure 21, managers 40 named "manager 1" and "manager 4" send a topic integration request to the topic editor device 5 requesting the integration of three topics, "Topic 1", "Topic 2", and "Topic 3", and manager "manager 2" sends a topic integration request to the topic editor device 5 requesting the integration of three topics, "Topic 1", "Topic 2", and "Topic 4" (S60).

[0128] Upon receiving these topic integration requests, the topic editor device 5 determines that the total number of received topic integration requests, which request the integration of three topics, "Topic 1," "Topic 2," and "Topic 3," exceeds the integration request threshold of "2." Therefore, it instructs the message broker device 4 to generate an integrated topic by integrating these topics, and simultaneously generates a message processing unit 47 (Figure 9) and a message queue 37 (Figures 4-6) associated with this integrated topic (S61).

[0129] Furthermore, as shown in Figure 22, the topic editor device 5 starts subscribing to "Topic 1," "Topic 2," and "Topic 3," and sends the acquired messages for these topics to the message broker device 4. As a result, these messages are stored in the integrated topic message queue 33 provided within the message broker device 4, corresponding to "Topic 5."

[0130] Furthermore, the topic editor device 5 then sends a notification to manager 1 and manager 4, respectively, indicating that it has completed the creation of a unified topic called "Topic 5" by integrating "Topic 1", "Topic 2", and "Topic 3", along with a subscription switching flag, thereby instructing manager 1 and manager 4 to switch their topic subscriptions (S62).

[0131] Upon receiving this integration completion notification, "manager 1" and "manager 4" create a subscriber 35 named "Subscriber 5" corresponding to the integrated topic "Topic 5," and delete subscribers 35 named "Subscriber 1" through "Subscriber 3" that were associated with "Topic 1," "Topic 2," and "Topic 3," respectively (S63). Thus, "Subscriber 5" then begins subscribing to "Topic 5."

[0132] On the other hand, if the message receiving device 7 on which "manager 4" is implemented performs a predetermined operation and cancels its subscription to "Topic 2", then, as shown in Figure 23, "manager 4" sends a topic merge withdrawal request to the topic editor device 5, indicating that the number of topics subscribed to by the message receiving device 7 has fallen below the topic subscription threshold, and therefore withdraws the merge requests for "Topic 1", "Topic 2", and "Topic 3" (S64).

[0133] Upon receiving this request to withdraw topic integration, the topic editor device 5 determines whether the number of subscribers to "Topic 5" after the message receiver 7, which has "manager 4" implemented, has terminated its subscription to "Topic 5" is above the integration withdrawal threshold. Since the number of subscribers to "Topic 5" after the message receiver 7, which has "manager 4" implemented, has terminated its subscription to "Topic 5" is still above the integration withdrawal threshold, the topic editor device 5 continues the integration of "Topic 1", "Topic 2", and "Topic 3" as is (S65).

[0134] On the other hand, as shown in Figure 24, "manager 4" deletes "Subscriber 5," which was associated with "Topic 5" when "Topic 2" was unsubscribed, and generates subscribers 35 called "Subscriber 1" and "Subscriber 3," respectively, associated with "Topic 1" and "Topic 3," which were integrated into "Topic 5" (S66).

[0135] Subsequently, when the message receiving device 7, on which "manager 1" is implemented, performs a predetermined operation and cancels its subscription to "Topic 2," the number of topics subscribed to by the message receiving device 7 falls below the topic subscription threshold. Therefore, as shown in Figure 25, "manager 1" sends a topic merger withdrawal request to the topic editor device 5, indicating that it will withdraw the merger requests for "Topic 1," "Topic 2," and "Topic 3" (S67).

[0136] Upon receiving this topic merge withdrawal request, the topic editor device 5 determines whether the number of subscribers to "Topic 5" after the message receiving device 7, which has "manager 1" implemented, has terminated its subscription to "Topic 5" is equal to or greater than the merge deactivation threshold.

[0137] At this point, after the message receiving device 7, which has "manager 1" implemented, terminates its subscription to "Topic 5," the number of subscribers to "Topic 5" falls below the demerging threshold. Therefore, the topic editor device 5 instructs the message broker device 4 to demerge "Topic 1," "Topic 2," and "Topic 3," and deletes the message processing unit 47 and message queue 37 that it created internally to correspond to "Topic 5" (S68). This demerges "Topic 1," "Topic 2," and "Topic 3."

[0138] Furthermore, once the unmerging of "Topic 1," "Topic 2," and "Topic 3" is complete, the topic editor device 5 notifies "manager 1" of this fact. Upon receiving this notification, "manager 1" deletes "Subscriber 5" associated with "Topic 5," as shown in Figure 26, and generates subscribers 35 named "Subscriber 1" and "Subscriber 3," respectively, associated with "Topic 1" and "Topic 3," which were merged into "Topic 5" (S69).

[0139] (5) Effects of this embodiment As described above, in the message distribution system 1 of this embodiment, when the number of topics subscribed to by the message receiving device 7 exceeds the topic subscription threshold, these topics are merged into a single unified topic. This prevents the number of sessions between the message broker device 4 and each message receiving device 7 from exceeding the topic subscription threshold. Therefore, this message distribution system 1 can suppress the increase in management costs for session management that accompanies an increase in the number of topics subscribed to by the message receiving device 7.

[0140] Furthermore, in this message delivery system 1, topics are consolidated and merged autonomously as described above, so the increase in session management costs associated with an increase in the number of topic subscriptions can be appropriately suppressed without human intervention. This makes it possible to build a highly reliable message delivery system with low management costs.

[0141] (6) Other embodiments In the above-described embodiment, the message transmission device 2 was described as a transmission device that transmits operational data as a message from, for example, a manufacturing device installed in a factory or a construction machine operating at a construction site. However, the present invention is not limited to this, and various other transmission devices can be applied as the message transmission device 2.

[0142] Furthermore, while the above-described embodiment described the application of the present invention to a push-type message distribution system 1 in which a message receiving device 7 periodically acquires messages from a message broker device 4, the present invention is not limited to this. The present invention can also be applied to a push-type message distribution system 1 in which a message broker device 4 manages subscribers 35 that subscribe to each topic, and when a message is stored in the message queue 33 of any topic, it sends that message to each message receiving device 7 that subscribes to that topic. [Industrial applicability]

[0143] This invention can be widely applied to message delivery systems of various configurations that deliver messages using the Pub / Sub model. [Explanation of Symbols]

[0144] 1...Message distribution system, 2...Message transmission device, 4...Message broker device, 5...Topic editor device, 7...Message receiving device, 10...Publisher, 11,15,19...CPU, 33,37...Message queue, 35...Subscriber, 36...Application, 40...Manager, 40A...Subscription switching instruction function unit, 40B...Subscription switching function unit, 40C...Integrated request function unit, 41...Topic management unit, 42...Message distribution unit, 45...Subscription status list, 46...Reference topic list, 47...Message processing unit, 48...Integrated management unit, 49...Integrated request list, 50...Integrated status list, 51...Scheduled change list.

Claims

1. In a message distribution system in which messages transmitted from a transmitting device are managed by topic in a relay device, and messages for topics subscribed to by a receiving device are distributed from the relay device to the receiving device, Topic editor device for managing the aforementioned topics Equipped with, The receiving device is, When the number of topics that the user subscribes to exceeds a predetermined first threshold, the user sends a merge request to the topic editor device requesting the merger of each of the topics that the user subscribes to. The topic editor device is The relay device is instructed to integrate each of the topics requested to be integrated in the received integration request, and to start subscribing to each of the topics requested to be integrated in the said integration request, and to transmit each of the received messages to the relay device, while instructing the receiving device that sent the said integration request to subscribe to the integrated topic which is the result of integrating each of the topics requested to be integrated in the said integration request. The relay device is, In accordance with instructions from the topic editor device, the system generates an integrated topic by integrating each of the specified topics, manages the messages of each of the topics constituting the integrated topic as messages of the integrated topic, and distributes the messages of the integrated topic to the receiving device that subscribes to the integrated topic. A message delivery system characterized by the following features.

2. The topic editor device is The integrated request transmitted from each of the multiple receiving devices is managed, When the system receives more than a predetermined second threshold of merge requests with the same content, it instructs the relay device to merge each of the topics requested to be merged in the merge request, starts subscribing to each of the topics requested to be merged in the merge request, and transmits each received message to the relay device, while instructing the receiving device that sent the merge request to subscribe to the merged topic formed by merging each of the topics requested to be merged in the merge request. The message delivery system according to feature 1.

3. The receiving device is provided with a subscriber for each of the topics it subscribes to, which receives the messages of the associated topic. The receiving device is, When the topic editor device instructs the user to subscribe to the integrated topic, it generates the subscriber associated with the integrated topic and deletes the subscribers associated with each of the topics that make up the integrated topic. The message delivery system according to feature 1.

4. The receiving device is, If, after each of the topics that the user is subscribed to has been integrated into the integrated topic, the user wishes to stop subscribing to any of the topics that make up the integrated topic, the user sends an integration withdrawal request to the topic editor device requesting the withdrawal of the integration request corresponding to that integrated topic. The topic editor device is In response to the merge withdrawal request, the receiving device that transmitted the merge withdrawal request is notified that the merged topic has been unmerged, while the relay device is instructed to unsubscribe from the corresponding merged topic, and subscriptions to each of the topics constituting the merged topic are stopped. Furthermore, the receiving devices that have transmitted merge withdrawal requests with the same content as the merge withdrawal request up to the present are notified that the unmerging of the merged topic has been completed. The receiving device is, Upon receiving notification of the unmerging of the aforementioned merged topic or notification of the completion of the unmerging, the subscription to that merged topic will be stopped, and the subscription to the topics that remain subscribed to among the topics that make up that merged topic will be started. The message delivery system according to feature 1.

5. The topic editor device is If the number of subscribers to the integrated topic subject to the integrated withdrawal request is less than a predetermined third threshold, the relay device is instructed to cancel the corresponding integrated topic, and the subscriptions to each of the topics constituting the integrated topic are stopped. Furthermore, each of the receiving devices that has sent an integrated withdrawal request with the same content as the integrated withdrawal request up to that point is notified that the cancellation of the integrated topic has been completed. The message distribution system according to feature 4.

6. The receiving device is, After sending the merge withdrawal request to the topic editor device, if the number of topics that the user subscribes to, excluding the topic to be stopped, is equal to or greater than the first threshold, the user sends the merge request to the topic editor device requesting the merge of each of the topics that the user continues to subscribe to. The message distribution system according to feature 4.

7. The receiving device is provided with a subscriber for each of the topics it subscribes to, which receives the messages of the associated topic. The receiving device is, When the topic editor device notifies that the unlinking of the integrated topic is complete, the subscriber associated with the integrated topic is deleted, and subscribers are generated for each of the topics that make up the integrated topic and whose subscriptions will continue. The message distribution system according to feature 4.

8. A message distribution method performed in a message distribution system in which messages transmitted from a transmitting device are managed by topic in a relay device, and messages of the topics subscribed to by a receiving device are distributed from the relay device to the receiving device, The aforementioned message distribution system is It has a topic editor device for managing the aforementioned topics, The first step is that when the number of topics that the receiving device subscribes to exceeds a predetermined first threshold, it sends a merge request to the topic editor device requesting the merger of each of the topics it subscribes to; A second step in which the topic editor device instructs the relay device to integrate each of the topics requested to be integrated in the received integration request, starts subscribing to each of the topics requested to be integrated in the integration request, and transmits each of the received messages to the relay device, while instructing the receiving device that sent the integration request to subscribe to the integrated topic formed by integrating each of the topics requested to be integrated in the integration request, A third step in which the relay device generates an integrated topic by integrating each of the specified topics in accordance with instructions from the topic editor device, manages the messages of each of the topics constituting the integrated topic as messages of the integrated topic, and delivers the messages of the integrated topic to the receiving device that subscribes to the integrated topic. A message delivery method characterized by comprising the following features.

9. In the second step described above, the topic editor device, The system manages the merge requests transmitted from each of the multiple receiving devices, and when it receives more than a predetermined second threshold of merge requests with the same content, it instructs the relay device to merge each of the topics requested to be merged in the merge request, starts subscribing to each of the topics requested to be merged in the merge request, and transmits each received message to the relay device, while instructing the receiving device that transmitted the merge request to subscribe to the merged topic formed by merging each of the topics requested to be merged in the merge request. The message delivery method according to feature 8.

10. The receiving device is provided with a subscriber for each of the topics it subscribes to, which receives the messages of the associated topic. In the second step described above, the receiving device, When the topic editor device instructs the user to subscribe to the integrated topic, it generates the subscriber associated with the integrated topic and deletes the subscribers associated with each of the topics that make up the integrated topic. The message delivery method according to feature 8.

11. A fourth step is that if the receiving device, after each of the topics it is subscribed to has been integrated into the integrated topic, stops subscribing to any of the topics that make up the integrated topic, it sends an integration withdrawal request to the topic editor device requesting the withdrawal of the integration request corresponding to that integrated topic. A fifth step in which the topic editor device, in response to the merge withdrawal request, notifies the receiving device that transmitted the merge withdrawal request that the merged topic has been unmerged, instructs the relay device to unsubscribe from the corresponding merged topic, stops subscriptions to each of the topics that constitute the merged topic, and further notifies each of the receiving devices that have transmitted merge withdrawal requests with the same content as the merge withdrawal request up to that point that the unmerging of the merged topic has been completed. When the receiving device receives notification of the unintegration or completion of unintegration of the integrated topic, it stops subscribing to the integrated topic and starts subscribing to the topics that it continues to subscribe to among the topics that make up the integrated topic. The message delivery method according to claim 8, characterized by comprising the following:

12. In the fifth step described above, the topic editor device, If the number of subscribers to the integrated topic subject to the integrated withdrawal request is less than a predetermined third threshold, the relay device is instructed to cancel the corresponding integrated topic, and the subscriptions to each of the topics constituting the integrated topic are stopped. Furthermore, each of the receiving devices that has sent an integrated withdrawal request with the same content as the integrated withdrawal request up to that point is notified that the cancellation of the integrated topic has been completed. The message delivery method according to feature 11.

13. The receiving device is, After sending the merge withdrawal request to the topic editor device, if the number of topics that the user subscribes to, excluding the topic to be stopped, is equal to or greater than the first threshold, the user sends the merge request to the topic editor device requesting the merge of each of the topics that the user continues to subscribe to. The message delivery method according to feature 11.

14. The receiving device is provided with a subscriber for each of the topics it subscribes to, which receives the messages of the associated topic. In the fifth step described above, the receiving device, When the topic editor device notifies that the unlinking of the integrated topic is complete, the subscriber associated with the integrated topic is deleted, and subscribers are generated for each of the topics that make up the integrated topic and whose subscriptions will continue. The message delivery method according to feature 11.

Citation Information

Patent Citations

  • Data distribution system

    JP2015125639A