JP2019176275A - Communication method, communication system, communication apparatus, and computer program - Google Patents

Abstract

To provide a communication method, a communication system, a communication apparatus, and a computer program, which achieve flexibly a delivery warrant of a message.SOLUTION: In a publish/subscribe type communication method, a server device as a broker receives a message on selection of a delivery assurance attribution indicating that the message is delivered with any one of a 0th delivery assurance that should deliver one time at a maximum, a 1st delivery assurance that should deliver one time at least, and a 2nd delivery assurance that must deliver one time to a client device as a subscriber in each message. Even if it becomes a processing impossible state itself, the server device receives the selection of an operation assurance attribution whether the delivery of the message should be assured, and switches a reception processing in response to the message received from the client device or the other server device in accordance with a combination of the selection of the delivery assurance attribution and the selection of the operation assurance.SELECTED DRAWING: Figure 1

Description

  The present disclosure relates to a communication method, a communication system, a communication apparatus, and a computer program for achieving arrival guarantee in transmission / reception of a publish / subscribe type message.

  Publish / Subscribe (Subscribe) type message transmission / reception system with a simple configuration that requires less traffic in various fields such as IoT (Internet of Things) system It's being used. In Pub / Sub type message transmission / reception, a server called broker is used to send and receive messages between a publisher (publisher) who is the sender of messages (data) and a subscriber (subscriber) who is the recipient of messages. Mediate. In order to mediate the message transmission / reception, information for distinguishing a message transmission destination called a topic is used. First, a subscriber designates a topic and subscribes to a message with the topic as a transmission destination. By this processing called subscription, the broker associates the subscriber identification information with the topic identification information. When the publisher sends a message specifying a topic, the broker delivers it to the subscriber corresponding to the specified topic. As a result, the publisher can send a message without being aware of who and how many recipients (subscribers) are. Since the Pub / Sub type message transmission / reception system is likely to be used on a low-bandwidth network in view of its application target, it is necessary to consider delay and loss.

  The Pub / Sub message transmission / reception system exchanges messages after establishing a TCP / IP session between publisher / broker, between broker / subscriber, and between broker / broker. Therefore, in the TCP layer, a reception confirmation packet (ACK) is used, and retransmission control is performed from the transmission side depending on the presence or absence of ACK from the reception side. A technique has also been proposed in which control is performed by a relay device so that congestion does not occur due to retransmission by ACK (Patent Document 1). Since the Pub / Sub message transmission / reception system exchanges over TCP / IP in this way, messages that have not been reached due to loss or delay can be transmitted by techniques such as retransmission in the TCP layer unless the TCP-based session is disconnected. Guaranteed. However, there are cases where it is desired that the message reaches the other party even if the session is interrupted. Therefore, in the Pub / Sub type message transmission / reception system, arrival guarantee at the time of session disconnection is specified. For example, in the MQTT (MQ Telemetry Transport) model, “At most once” (at least once, 0 times or once), “At least Once” (at least once, at least once), “Exactly once” ( Protocols that achieve three types of guarantees (delivered exactly once, exactly once) are prepared (Non-Patent Document 1).

JP 2006-287331 A

IBM Corporation, "4.1. Quality of Service (QoS) Level and Flow", [online], MQTT V3.1 protocol specification (Japanese), Internet <URL: http://public.dhe.ibm.com/software /dw/jp/websphere/wmq/mqtt31_spec/mqtt-v3r1_en.pdf>

  With the development of IoT related technology, the number of IoT devices has become enormous and diversified. There is a demand for a network infrastructure that can exchange messages between these IoT devices and devices including communication devices other than IoT devices in a lightweight and secure manner. Of course, a Pub / Sub message transmission / reception system is suitable for such network infrastructure.

  In order to realize the Pub / Sub type message transmission / reception system as a secure network infrastructure, it is preferable that a plurality of broker instances exist. Further, considering the failure of the broker itself and the communication failure, it is desirable that the communication path from the publisher to the subscriber reaches a network in which a plurality of patterns can be selected. In this case, the number of brokers through which a message passes from the publisher to the subscriber is not necessarily one. The arrival guarantee in the above-mentioned MQTT model guarantees the arrival of a message at the time of a halfway disconnection in a one-to-one session between publishers and brokers or between brokers and subscribers. For messages that have passed through multiple brokers, there is no consideration for arrival guarantees that take into account the case where the communication path that passes through them has changed or the broker has gone down.

  The present invention has been made in view of such circumstances, and an object of the present invention is to provide a communication method, a communication system, a communication device, and a computer program that flexibly realize message arrival guarantee.

  The communication method according to an aspect of the present disclosure is a communication method in which one or more server devices that mediate between a plurality of client devices that are publishers or subscribers transmit and receive publish / subscribe type messages. The device receives the message received from the client device that is the publisher to reach the client device that is the subscriber at most once, the zero-order arrival guarantee that the message should reach at least once, the first-order arrival guarantee that the message should arrive at least once, Whether the arrival guarantee attribute to be reached in the secondary arrival guarantee that should be reached once is accepted for each message, and whether the arrival of the message should be guaranteed even when it becomes unprocessable The combination of the selection of the guaranteed operation attribute and the selection of the guaranteed operation attribute In response, switching the reception processing for a message received from the client device, or other server devices.

  A communication apparatus according to an aspect of the present disclosure is a server apparatus that mediates transmission / reception of a publish / subscribe type message, and a zeroth arrival guarantee that a received message should reach a subscriber at least once, at least A first arrival assurance attribute accepting unit that accepts selection of an arrival guarantee attribute that is to be reached by a first arrival guarantee that should be reached once or a second arrival guarantee that should be reached once; Depending on the combination of the operation guarantee attribute accepting unit that accepts the selection of the operation guarantee attribute whether or not the arrival of the message should be guaranteed even when it becomes unprocessable, and the selection of the operation guarantee attribute and the operation guarantee selection, A reception processing switching unit that switches reception processing for the received message.

  A computer program according to an aspect of the present disclosure is a computer program that causes a computer including a communication unit to execute transmission / reception of a publish / subscribe type message, and the received message reaches the subscriber at most once. Select the arrival guarantee attribute to be reached by the 0th order arrival guarantee to be reached, the first arrival guarantee to be reached at least once, or the second arrival guarantee to be reached at least once Received depending on the combination of the process to accept, the process to accept the selection of the operation guarantee attribute whether or not the message should be guaranteed even if it is in the unprocessable state, and the selection of the guarantee guarantee attribute and the operation guarantee The process of switching the reception process for the received message is executed.

  A communication system according to an aspect of the present disclosure includes a plurality of client apparatuses that transmit and receive publish / subscribe messages as publishers or subscribers, and one or a plurality of servers that mediate transmission and reception of messages between the plurality of client apparatuses In a communication system including a device, the server device receives a message received from a client device that is a publisher to reach a client device that is a subscriber at least once. A first arrival guarantee attribute accepting unit that accepts selection of a arrival guarantee attribute that is to be reached by a first arrival guarantee that should be reached or a second arrival guarantee that must be reached once; Even if it becomes impossible, it is possible to guarantee the operation of whether or not message arrival should be guaranteed. An operation guarantee attribute accepting unit that accepts an attribute selection, and a reception process switching unit that switches a reception process for a message received from a client device or another server device in accordance with a combination of an arrival guarantee attribute selection and an operation guarantee selection. The client device includes: a first selection unit that selects the operation guarantee attribute with respect to a server device that communicates; and a second selection unit that selects an arrival guarantee attribute of the message when the message is transmitted or received. Is provided.

  According to the present disclosure, not only the message arrival guarantee for each session but also the message arrival guarantee from the publisher to the subscriber can be realized even in various configurations.

It is a schematic diagram of the communication system in this Embodiment. It is a block diagram which shows the hardware constitutions of each apparatus which comprises a communication system. It is a sequence diagram which shows the arrival guarantee in an MQTT model. It is a flowchart which shows an example of the process sequence of the server apparatus when keep connection is selected. It is explanatory drawing which shows the maintenance of the subscribe state by keep connection. It is a figure which shows the example of a connection between apparatuses. The example of the message transmitted between apparatuses in the connection state of FIG. 6 is shown. It is a figure which shows the cutting state with respect to FIG. It is a figure which shows an example of a process when a message is transmitted from the publisher in the disconnection state shown in FIG. It is a figure which shows an example of a process when a message is transmitted from the publisher in the disconnection state shown in FIG. The process after reconnection is shown. An example of processing when QoS = 1 is shown. A processing example when QoS = 2 is shown. A processing example when QoS = 2 is shown. It is a flowchart which shows an example of the process sequence performed when a server apparatus detects session disconnection. It is a figure which shows the state from which the client apparatus was disconnected from the server apparatus. It is a figure which shows the process sequence at the time of returning from the cutting | disconnection state of FIG. It is a figure which shows the example of the other state by which the client apparatus was cut | disconnected from the server apparatus. It is a figure which shows the process sequence at the time of returning from the cutting | disconnection state of FIG. It is a flowchart which shows an example of the message delivery processing procedure by the server apparatus which is a broker in QoS = 1. It is explanatory drawing which shows a transmission order. It is explanatory drawing which shows the other example of a transmission order. It is a figure which shows the connection structure of a server apparatus and a client apparatus. It is a flowchart which shows an example of the process sequence in the server apparatus when the brokers are cut | disconnected. It is explanatory drawing which shows the example of a process when the session between brokers in the connection structure shown in FIG. 23 is cut | disconnected. It is explanatory drawing which shows the example of a process when the session between brokers in the connection structure shown in FIG. 23 is cut | disconnected. It is explanatory drawing which shows the example of a process when the session between brokers in the connection structure shown in FIG. 23 is cut | disconnected. It is a flowchart which shows an example of the message processing procedure in the process of cutting | disconnection between brokers. It is a flowchart which shows an example of the transmission procedure in the server apparatus which guarantees broker down. It is a figure which shows the process at the time of guaranteeing a broker down by QoS = 1. It is a figure which shows the process at the time of guaranteeing a broker down by QoS = 1. It is a figure which shows the process at the time of guaranteeing a broker down by QoS = 1. It is a figure which shows the process at the time of guaranteeing a broker down by QoS = 1. It is a flowchart which shows an example of the process sequence at the time of starting of a server apparatus. It is a figure which shows a process when the server apparatus (b2) which is a broker goes down. It is a figure which shows a process when the server apparatus (b2) which is a broker goes down. It is a figure which shows the example of the process performed after a server apparatus (b2) starts after the state shown in FIG. It is explanatory drawing of the packet ID corresponding | compatible information in QoS = 2. It is a flowchart which shows an example of the message processing procedure using packet ID corresponding | compatible information. It is a figure which shows the example of the content of packet ID corresponding | compatible information. It is a figure which shows the example of the content of packet ID corresponding | compatible information. It is a figure which shows the example of the content of packet ID corresponding | compatible information. It is a flowchart which shows an example of the process sequence at the time of the session disconnection detection with the subscriber in a server apparatus (b2). It is explanatory drawing which shows the example of a process when the session between brokers is cut | disconnected. It is explanatory drawing which shows the example of a process when the session between brokers is cut | disconnected. It is explanatory drawing which shows the example of a process when the session between brokers is cut | disconnected. It is a flowchart which shows an example of the message transmission process after the re-establishment of the session between brokers in QoS = 2. It is a figure which shows the process at the time of guaranteeing broker down by QoS = 2.

  Hereinafter, a communication method and a communication system according to the present disclosure will be specifically described with reference to the drawings illustrating embodiments thereof.

  FIG. 1 is a schematic diagram of a communication system 100 according to the present embodiment. The communication system 100 includes a plurality of server devices 1 and a plurality of client devices 2. The server device 1 and the client device 2 can communicate with each other via the network N. In particular, a plurality of server devices 1 can be connected to each other for communication. At this time, the number of server apparatuses 1 participating in the network N is, for example, several tens. The client device 2 can establish communication connection (establish a session) with any one of the plurality of server devices 1. All of the plurality of server devices 1 can access the common database 3. The database 3 is provided so as to be connected to the inside of the server device 1 or the outside of the server device 1 via a communication medium. The contents of the plurality of databases 3 are synchronized, and the server apparatus 1 may acquire information from any database 3.

  Each of the plurality of server devices 1 is a server computer and functions as a broker in a Pub / Sub type message transmission / reception system. The plurality of client devices 2 are so-called IoT devices, and include a wireless communication unit and sensors or switches. The client device 2 may be a communication terminal device such as a smartphone. Each of the client devices 2 functions as one or both of a publisher and a subscriber. For example, the client device 2 that is a smartphone transmits control contents to the client device 2 that is a switch device from a remote location, or the measurement result is transmitted from the client device 2 that is a sensor device to the client device 2 that is a smartphone. In the former pattern, the client device 2 that is a smartphone functions as a publisher and the client device 2 that is a switch device functions as a subscriber. In the latter pattern, the client device 2 that is a sensor device functions as a publisher and the client device 2 that is a smartphone. Acts as a subscriber.

  In the communication system 100, by permitting the client device 2 to use a plurality of server devices 1 group, the client device 2 controls other client devices 2 via the network N, and collects information from many client devices 2. It is possible to realize a service that makes it possible. Here, when controlling the client apparatus 2 which is a switch apparatus from the client apparatus 2 which is a smart phone, the case where the two server apparatuses 1 mediate between these as a broker is considered. When a message including control information is lost because the session between the client device 2 and the server device 1 or between the two server devices 1 is disconnected or the server device 1 stops operating (down), the switch There is a possibility that the contents are different from those intended for control. In the communication system 100 according to the present embodiment, not only the message arrival guarantee between the server apparatus 1 and the client apparatus 2 establishing a session but also the exchange of messages via the plurality of server apparatuses 1 is performed. Achieves arrival guarantees that take even downs into account.

  FIG. 2 is a block diagram illustrating a hardware configuration of each device constituting the communication system 100. The server device 1 uses a server computer. The server apparatus 1 is not always realized as one logical apparatus for one server computer in terms of hardware. In most cases, this is realized by a virtual machine in which a plurality of servers operate logically on one server computer. The same applies to the client device 2 and the database 3 to be described later. However, in order to simplify the description, in the following description, the server device 1 and the client device 2 are described as physically using one computer, and the database 3 is described as using one storage device.

  The server device 1 includes a control unit 10, a first storage unit 11, a second storage unit 12, a temporary storage unit 13, and a communication unit 14, respectively. The control unit 10 uses a processor such as a CPU (Central Processing Unit) and a GPU (Graphics Processing Unit) to execute each process based on the server program 1P stored in the first storage unit 11, and a general-purpose server computer is used as a Pub. Functions as a broker in the / Sub type message transmission / reception system. Note that the server device 1 according to the present embodiment basically operates in accordance with the MQTT model broker. The temporary storage unit 13 temporarily stores information generated by the processing of the control unit 10 using a volatile memory such as a DRAM (Dynamic Random Access Memory).

  The first storage unit 11 uses a non-volatile memory such as a hard disk or a flash memory. In addition to the server program 1P, the first storage unit 11 stores information that the control unit 10 refers to when processing.

  Similar to the first storage unit 11, the second storage unit 12 uses a part of the nonvolatile memory built in the server device 1 or uses an external storage device. The 2nd memory | storage part 12 is utilized as the database 3 which should be shared between the server apparatuses 1 in the communication process mentioned later. Details of the contents of the database 3 will be described later.

  The communication unit 14 realizes communication connection to the network N using a network card or a wireless communication device. The communication unit 14 performs communication according to TCP / IP, but may use a protocol instead of this. The server device 1 realizes communication connection via the network N by the communication unit 14, establishes a one-to-one session with another server device 1, and creates a mesh network as shown in FIG. To construct.

  The network N is a generic name including a public network that is a so-called Internet, a communication carrier network, a carrier network of a carrier that realizes an IoT service, a base station that is a connection base to them, an access point, and the like. The server device 1 is connected to the network N from the operator network of the network N, and the client device 2 is connected to the network N from the public network and the communication carrier network.

  The database 3 is realized using the second storage unit 12 of the server device 1 as described above, or connected to the network N using an external storage device (hard disk and storage processing unit) independent of the server device 1. It is good also as composition which has.

  The client device 2 is realized by various computers, but includes at least a control unit 20, a storage unit 21, and a communication unit 23. The control unit 20 functions as a publisher or broker in a Pub / Sub type message transmission / reception system by each processing based on the terminal program 2P stored in the storage unit 21 using a CPU, a microprocessor, etc. and a clock. Make

  The storage unit 21 uses a nonvolatile memory such as a flash memory. The storage unit 21 stores a terminal program 2P for realizing Pub / Sub message transmission / reception, and stores information that the control unit 20 refers to during processing.

  The communication unit 22 implements communication connection to the network N using a network card or a wireless communication device.

A specific method for realizing message arrival guarantee in the communication system 100 will be described step by step with reference to flowcharts and explanatory diagrams.
1. Premises for communication between devices (0) Session between devices (1) Basics of QoS (reach guarantee) (2) Keep connection (3) Session between brokers Multiple assurance levels (1) QoS = 0 (zero)
(2) QoS = 1, but not guaranteed if the broker is down (3) QoS = 1, guaranteed even if the broker is down (4) QoS = 2, but not guaranteed if the broker is down (5) QoS = 2, guarantees if the broker goes down

[1. Premises for communication between devices]
(0) Session Basically, a session is established between the client device 2 and the server device 1, and between the server device 1 and the server device 1, and messages are exchanged within the session. The server apparatus 1 can establish a session with a plurality of client apparatuses 2 and the server apparatus 1 and identifies a communication partner for each session (identifies who the session is with).

(1) Basics of QoS (guarantee guarantee) As described above, the plurality of server apparatuses 1 basically conform to the broker in the MQTT model. Therefore, the server device 1 executes processing for message exchange between the client device 2 and the other server device 1 based on the arrival guarantee of the MQTT model. FIG. 3 is a sequence diagram showing arrival guarantee in the MQTT model. In the MQTT model, data is sent from the sender as a publish message. The publish message contains the topic ([topic]), the data to be sent (payload) ([data / payload]), and the guarantee level ([qos] )including. Depending on the arrival guarantee level, a packet ID ([packet_id]) for identifying the packet is included. In this and the following description, [] represents an example of a field name, and an appropriate numerical value or logical value is entered and used for each. In the sequence diagram of FIG. 3, the message arrangement between the sender and the receiver of the message is shown when the QoS level is 0 (zero), 1 and 2, respectively. The sender can specify the QoS level (qos) from 0, 1, and 2 when transmitting (publish) the message.

  As shown in FIG. 3A, when data (data) is transmitted as a publish message for a topic (publisher) as a publisher, when “0 (zero)” is specified as the QoS level, The receiver does not perform any processing other than the reception processing. As a result, it is impossible for the sender to confirm whether the message has arrived, and the situation cannot be known even if the message has not arrived. However, when the latest data is transmitted each time, QoS = 0 is sufficient.

  As shown in FIG. 3B, when “1” is specified as QoS when transmitting data on a topic for which the sender is the publisher (qos = 1), the packet ID (packet_id) of the packet to be transmitted is set as the sender. The number is assigned and specified in the session with the receiver (packet_id = 0x10 in FIG. 3B). In this case, the receiver returns the message “puback” with the packet ID specified, and the sender side holds (temporarily stores) the transmitted data together with the packet ID until receiving this puback message. If a sender sends data about a topic and the session is disconnected with the recipient before receiving a puback message for that transmission, the sender re-establishes the session with the recipient, The temporarily stored publish message is retransmitted by specifying the stored packet ID. Thus, the sender can know the fact that the receiver has received the data, and the receiver can always receive the data even if the session is disconnected. However, in this case, it is impossible to distinguish whether the session was disconnected after the data arrived at the recipient, or whether the session was disconnected before it arrived. Will be received multiple times.

  As shown in FIG. 3C, when the publisher sender sends a publish message for a certain topic, when “2” is specified as QoS, the packet to be transmitted is the same as when “1” is specified. ID is numbered and used for transmission (in FIG. 3C, packet_id = 0x11). In this case, the receiver returns a pubrec message specifying the packet ID, and discards the data transmitted by specifying the same packet ID. Therefore, even if data is retransmitted, it can be discarded and data can be received only once. The sender holds the transmitted data together with the packet ID until the pubrec message is received, and discards the temporarily stored data when the pubrec message is received. Since the packet ID stored together with the discarded data can be used for transmission of new data, the sender transmits a pubrel message declaring this together with the packet ID. The receiver transmits a pubcomp message indicating that the pubrel message has been received, and transmission / reception of a message having a QoS level of “2” is completed. If the session is disconnected even when QoS = 2, the sender re-establishes the session with the receiver, then resends the publish message if no pubrec message has been received, and pubrel if no pubcomp message has been received. Resend the message.

  In the case where the session is disconnected during the exchange of messages shown in FIGS. 3B and 3C, if the publish message or pubrel message is transmitted from the sender side, these messages are retransmitted on the receiver side. Regardless of this, a pubrec message or a pubcomp message is sent as a response. On the receiver side, the pubrec message or pubcomp message is not retransmitted even though the publish message or pubrel message has not been received.

  Note that the arrival guarantee in MQTT shown in FIGS. 3A to 3C is a provision for message arrival guarantee between two devices, a sender and a receiver. Therefore, even if a message from the publisher to the broker to be connected is transmitted with the QoS level “2” for the same data on the same topic, the arrival at the subscriber is guaranteed at the QoS level “2”. Do not mean. On the other hand, in the communication system 100 according to the present embodiment, while using the arrival guarantee in MQTT, not only the two devices that directly establish a session but also the arrival guarantee to the subscriber. Optimize by route. Furthermore, the message arrival is guaranteed not only when the session is disconnected, but also when the broker goes down and the temporary storage is discarded. For the realization of these arrival guarantees, see [2. This will be described later.

(2) Keep Connection In the communication system 100, when a session is established from the client device 2 as a subscriber to the server device 1, an option “keep” can be selected. The keep connection corresponds to establishing a session by selecting "false" with the option "CleanSesson" in the MQTT model. If the “keep” option is set to true when the client apparatus 2 requests communication connection to the server apparatus 1, even if the session with the server apparatus 1 is disconnected, the server is disconnected while disconnected. A message arriving at the device 1 can be received later.

  Processing for realizing keep connection will be described. FIG. 4 is a flowchart illustrating an example of a processing procedure of the server apparatus 1 when the keep connection is selected. When detecting a communication connection request from the client device 2 based on the server program 1P, the control unit 10 of the server device 1 executes the following processing.

  The control unit 10 temporarily stores the client ID (user_id) of the client apparatus 2 that has been connected for communication and the connection option (“keep” option (keep = true or false)) from the client apparatus 2 that has been connected for communication (step) S1).

  First, the control unit 10 refers to session information (step S8 to be described later) stored in the database of the second storage unit 12 based on the client ID (step S2), and session information corresponding to the connected client device 2 Is determined to be new (step S3). When it is determined that the session information does not exist in the database and is new (S3: YES), the control unit 10 newly stores state information indicating that the connection is being made in association with the client ID in the temporary storage unit 13. Store (step S4), thereby starting a new session.

  Next, when receiving the designation of the topic to be subscribed from the client apparatus 2 that has established the session together with the designation of the guarantee level of arrival (QoS) (step S5), the control unit 10 receives the designated topic and the designated topic. QoS is associated with the client ID and stored in the temporary storage unit 13 (step S6).

  The control unit 10 determines whether or not the “keep” option of the communication connection from the target client device 2 is true (step S7), and if it is determined to be true (S7: YES), the client ID The designated topic (character string) and QoS targeted in step S5 are stored as session information in the database 3 ("keep_sub" table) of the second storage unit 12 (step S8). In step S8, if the session information to be stored is the same as the information already stored, the control unit 10 may leave it as it is.

  Thereafter, each time data is transmitted from the publisher to the specified topic, the control unit 10 executes a process of distributing this data to the client device 2 that is a subscriber (step S9), and the session with the client device 2 is disconnected. It is determined whether or not it has been done (step S10). When it is determined that it has not been disconnected (S10: NO), the control unit 10 returns the process to step S9 and continues the distribution process for the specified topic.

  When it is determined that the connection has been disconnected (S10: YES), the status information of the corresponding client ID is deleted (step S11), the delivery destination of the designated topic is changed to the database (step S12), and the process ends. Thereafter, the control unit 10 stores the data (payload) included in the message about the specified topic in the database 3 (“store” table and “store_target” table) in association with the topic identification information.

  When it is determined that the “keep” option of the communication connection is not true (that is, false) (S7: NO), the control unit 10 adds this to the subscriber every time data is transmitted from the publisher to the specified topic. The process of delivering to the client device 2 is executed (step S13). And the control part 10 judges whether the session with the client apparatus 2 was cut | disconnected (step S14). If it is determined that it has not been disconnected (S14: NO), the control unit 10 returns the process to step S13, and continues the distribution process for the topic. If it is determined that it has been disconnected (S14: YES), the status information of the corresponding client ID is deleted (step S15), and the process is terminated. In this case, information is not stored in the database of the second storage unit 12.

  When the session information exists in step S3 and is determined to be existing (S3: NO), since the target client device 2 is reconnected, the control unit 10 associates the same client ID with the database. The stored specified topic is read and the state information is restored (step S16).

  Then, the control unit 10 determines whether or not the “keep” option at the time of reconnection is true (step S17). If it is determined to be true (S17: YES), the control unit 10 extracts the data (payload) stored in the database of the second storage unit 12 for the specified topic and distributes it to the client device 2 that has reconnected. (Step S18). The control unit 10 advances the process to step S9.

  When it is determined that it is not true (false) in step S17 (S17: NO), the session information corresponding to the specified topic and the client ID stored in the database of the second storage unit 12 is deleted (step S19). Then, the process proceeds to step S13.

  FIG. 5 is an explanatory diagram showing maintenance of a subscribed state by keep connection. FIG. 5 shows events such as connection and disconnection from the client device 2 as a subscriber to the server device 1 of the broker in time series from the upper part to the lower part of the figure, and shows changes in the subscribe state due to each event. If you connect with the "keep" option set to true, messages sent from the publisher to the specified topic during that period can be delivered after reconnection, The client device 2 can receive the message without omission.

  With reference to FIG. 6 to FIG. 14, a specific method for realizing message distribution processing by keep connection will be described. FIG. 6 is a diagram illustrating a connection example between apparatuses. A client device 2 with identification information “p1” (hereinafter referred to as server device 1 or client device 2 (identification information)) communicates with server device 1 (b1) (broker) as a publisher (session A), and the client device 2 (s2) shows an example in which communication connection (session B) is made to the server apparatus 1 (b1) as a subscriber. The client device 2 (s1), which is a subscriber, has a keep connection (communication connection with the “keep” option set to true) to the server device 1. When the topic “t1” is specified from the client device 2 (s1), the server device 1 (b1) is associated with the identification information ([user_id]) for each subscriber, and the specified topic ([topic]) and Session information including the designated QoS is stored in the database 3 ("keep_sub" table). In the example of FIG. 6, for the client device 2 (s1) as a subscriber, (user_id = s1), the specified topic (topic = t1) and the specified QoS ([qos]) are stored.

  In FIG. 6, the client device 2 (s2) is also connected to the server device 1 (b1) as a subscriber (session C). Since the client device 2 (s2) is connected to the server device 1 (b1) with the “keep” option set to false (non-keep), it corresponds to the database 3 (“keep_sub” table). Session information is not stored. When the client device 2 (s2) specifies the topic “t1” in the same manner as the client device 2 (s1), each time a publish message is transmitted from the client device 2 (p1) that is the publisher for the topic “t1”, A publish message is transmitted from the server device 1 (b1), which is the broker, to the client device 2 (s1, s2) with the designated QoS.

  FIG. 7 shows a specific example of a message transmitted between apparatuses in the connection state of FIG. For example, the publisher client device 2 (p1) transmits a publish message including a payload (data / payload) of “a” for the topic “t1”, specifying QoS (1 or 2) each time it is transmitted. To do. [Qos] in FIG. 7 indicates that the specified value of QoS is included. The publish message is given a packet ID (packet_id = 0x100) that is assigned on the origin side for each session. In the state shown in FIG. 7, the state information of the client device 2 (s1) is online, and the topic “t1” is subscribed. The server device 1 (b1) refers to the topic “t1” of the arrived message, and publishes the payload (data / payload = a) toward the client device 2 (s1) that is the subscriber that specifies the topic. Send a message. The QoS of the publish message from the server device 1 (b1) to the client device (s1) is specified when the client device 2 (s1) specifies the topic to be subscribed to the server device 1 (b1) as session information. It is arbitrated to the smaller of the stored QoS and the QoS specified when sent from the publisher. Further, the packet ID (packet_id = 0x101) given to the packet of the message transmitted from the server device 1 (b1) is numbered by the server device 1 (b1) as the sender. Similarly, a publish message including a payload (data / payload = a) is transmitted to the client apparatus 2 (s2) (packet ID (packet_id = 0x103) is separately numbered).

  FIG. 8 is a diagram showing a cut state with respect to FIG. FIG. 8 shows that the sessions B and C between the client device 2 (s1, s2) and the server device 1 have been disconnected from the connection state shown in FIG. The server device 1 temporarily stores that the session destination with the client device 2 (s1) is detected and the distribution destination is the database 3 for the topic corresponding to the corresponding session information (s1). On the other hand, even if the server device 1 detects the disconnection of the session with the client device 2 (s2), since the session is non-keep, the corresponding status information (s2) is not temporarily stored.

  9 and 10 show an example of processing when a message is transmitted from the publisher in the disconnected state shown in FIG. Similarly to FIG. 7, the client apparatus 2 (p1) transmits a publish message including the payload “a” for the topic “t1”, specifying QoS (1 or 2). In the figure, [qos] indicates that the specified QoS value is included in the message. In this case, the server device 1 (b1), which is the broker, stores that the delivery destination is the database 3 for the message of the topic “t1” corresponding to the session information of the identification information “s1”. Store a message for each topic in the “store” table. This message is stored as a saved message. The stored message includes, for example, an identifier ([store_id]) for identifying each message, a topic ([topic]), and message content ([data / payload]). The stored message may include the reception time ([TS]) at the broker. In the example of FIG. 9, a stored message having the content “a” (data / payload = a) is stored for the topic (topic = t1) to which the identifier “123” (store_id = 123) is attached.

  As shown in FIG. 10, the server device 1 (b1) continues to store distribution destination information (distribution destination information) of the stored message (“store”) stored in the database 3 for each piece of identification information of the distribution destination device. Store in database 3 ("store_target" table). One save message ("store" table) is stored for one publish execution, but there are as many delivery destination information ("store_target" tables) as the number of delivery destinations of the saved message. Become. Delivery destination information includes delivery destination identification information ([user_id]), packet ID at the time of transmission ([packet_id]), message identifier ([store_id]), and flag indicating whether or not the message has been sent ([already_sent]) , And QoS at the time of transmission ([qos]). In the example of FIG. 10, distribution destination information indicating that the stored message (id = 123) has not been transmitted to the client device 2 (user_id = s1) (already_sent = false) is stored. The packet ID of the message is stored in association with it. In the example of FIG. 10, it is known that the session B with the delivery destination is disconnected when the publish message is received. In this case, the packet ID is set to NULL (outside the range (0x0001-0xffff) that can be used by MQTT). Is set. QoS is stored in association with the delivery destination. This QoS is the QoS with the smaller value between the QoS specified when the subscriber to be subscribed to specifies the topic to be subscribed to and the QoS specified when the message is sent from the publisher.

  Then, the server apparatus 1 returns a puback message (QoS = 1) or a pubrec message (QoS = 2) for the publish message to the client apparatus 2 of the publisher.

  FIG. 11 shows processing after reconnection. When the client apparatus 2 (s1) communicates again with the server apparatus 1 (may be another server apparatus 1) (session B), the server apparatus 1 side uses the session information ("keep_sub" table) stored in the database 3 The session information such as the specified topic is read out to restore the state information. Then, the server apparatus 1 searches the transmission destination information (“store_target” table) stored in the database 3 for an unsent message (already_sent = false) for the client apparatus 2 (user_id = s1). It is referred that the stored message to which the identifier “123” is attached to the client apparatus 2 (s1) is not yet transmitted. The server device 1 reads the payload (data / payload = a) of the stored message having the identifier “123” from the database 3 (“store” table), and transmits it as a publish message to the client device 2 (s1) that is the sub-client. At this time, in the distribution destination information for the client apparatus (s1), the packet ID is not assigned (NULL) because it is disconnected in advance, and the packet ID (packet_id = 0x102) is newly obtained. It is numbered. The packet ID of the distribution destination information is also updated with the numbered packet ID. Regarding reconnection from the client device 2 (s2), since the previous connection was non-keep, the state information is not restored and a new session (session C) is established. In addition, the server device 1 does not recognize the specified topic of the client device 2 (s2) unless the process of specifying the topic to subscribe from the client device 2 (s2) is performed.

  The server device 1 (b1) deletes the delivery destination information (“store_target”) stored in the database 3 when it can be transmitted to the delivery destination. Specifically, for example, a puback message is received from a distribution destination, and the distribution destination information is deleted when reception at the distribution destination is confirmed with certainty. The memory deletion timing is not limited to this, and may be appropriately designed. The stored message with the identifier “123” is already transmitted because the distribution destination of only the distribution destination information of the identification information “s1” corresponds. The server device 1 (b1) deletes the stored message from the database 3 (“store” table). However, processing differs depending on the specified QoS. FIG. 12 shows a processing example when QoS = 1. When QoS is “1 (At least Once)” for the message for the client device 2 (s1) in the distribution destination information (“store_target” table) of the database 3, the server device 1 (b1) is shown in FIG. After confirming that the puback message has been returned from the client device 2 (s1) after sending the message (publish), the database 3 ("store_target" table and "store" table) is associated with "123" for "s1" Erase the record.

  13 and 14 show processing examples when QoS = 2. The information stored in the delivery destination information (“store_target” table) stored in the database 3 is an example in the case where the QoS is “2 (Exactly once)” for the message for “s1”. After confirming that the pubrec message has been returned from the client apparatus 2 after transmitting the publish message shown in FIG. 11, the server apparatus 1 stores the distribution destination information (“store_target” table) in the database 3 as shown in FIG. “False” of a flag (already_sent) indicating non-transmission is rewritten to “true”, and a pubrel message is transmitted to the client apparatus 2. In the distribution destination information, the packet ID is updated by “0x102” that is assigned when the pulish message is transmitted. Then, as shown in FIG. 14, when the server apparatus 1 confirms the reception of the pubcomp message from the client apparatus 2 in response to the pubrel message, it is the first time here that the server apparatus 1 retrieves the client apparatus 2 from the database 3 ("store_target" table and "store" table). The stored message including the identifier “123” for (s1) is deleted. If the server device (b1) is disconnected before receiving the pubcomp message, the delivery destination information is stored in the database 3 with a flag indicating whether or not the transmission destination information has already been transmitted (already_sent = true). . After the re-establishment, the server apparatus (b1) resumes the process from the transmission of the pubrel message again. At this time, the pubrel message is transmitted with reference to the packet ID of the distribution destination information. Even when it overlaps with transmission by midway message information, which will be described later, the same message can be rejected on the receiving side by storing the packet ID and using it at the time of retransmission, and "Exactry once" can be realized. .

  As shown in FIGS. 6 to 14, the server apparatus 1 performs an operation of realizing keep connection using information stored in the database 3 (“store” table and “store_target” table). Thereby, the guarantee of the arrival of the message to the subscriber with respect to the disconnection of the session in the case where there is one broker agent that mediates is realized.

  When keep connection is selected, the server apparatus 1 further exchanges messages for guaranteeing arrival in the MQTT model shown in FIG. 3 with the client apparatus 2 connected with QoS = 1 or = 2. Performs processing considering the case where the session is disconnected.

  FIG. 15A is a flowchart illustrating an example of a processing procedure executed when the server apparatus 1 detects session disconnection. 15A and 15B is a procedure in the server device 1 on the sender side shown in FIGS. 3A to 3C. The processing procedure shown in the flowchart of FIG. 15A is executed after step S10 in the processing procedure shown in the flowchart of FIG.

  Specifically, when transmitting the publish / pubrel message, the control unit 10 of the server device 1 writes the packet to be transmitted in a transmission box (hereinafter referred to as a transmission buffer) of the MQTT-compliant network controller (communication library). By the operation of the network controller, the packet written in the transmission box is written in the socket to the counterpart of the corresponding session, and transmission is performed. When a message (puback / pubrec, pubcomp) to be responded to the message is received by the operation of the network controller, a process for deleting the publish / pubrel message from the transmission buffer is performed.

  When detecting disconnection with the client device 2 as a subscriber (step S101), the control unit 10 determines whether or not a message remains in the transmission buffer (step S102). If it is determined that it remains (S102: YES), the control unit 10 reads the packet image of the remaining message as it is and stores it as intermediate message information in the database 3 ("keep_mqtt" table) (step S103). ). The midway message information includes the identification information (user_id) of the destination client apparatus 2, the transmission time (time stamp = [TS]), and the message packet image as it is. The packet image includes a packet ID, QoS, and the like assigned when a message is transmitted to the client device 2. When the session is disconnected (discarded), the message remaining in the transmission buffer is deleted (discarded) even though the corresponding message has not been received (step S104), and the process ends.

  If it is determined in step S102 that there is no remaining (S102: NO), the control unit 10 ends the process as it is.

  FIG. 15B is a flowchart illustrating an example of a processing procedure executed when the server apparatus 1 detects session resumption. The processing procedure shown in the flowchart of FIG. 15B is executed before step S18 in the processing procedure shown in the flowchart of FIG.

  The control unit 10 detects a communication connection from the client device 2 (step S105). Since the control unit 10 identifies the partner of the communication connection and restores the state information, as the midway message information, a message in the middle of transmission targeting the reconnected client device 2 (connection partner) is stored in the database 3 ( It is determined whether or not it is stored in the “keep_mqtt” table (step S106). If it is determined in step S105 that the data is not stored (S106: NO), the control unit 10 advances the process to the next step S18.

  When it is determined that it is stored in step S105 (S106: YES), the control unit 10 sends the packet image at the time of transmission stored as an intermediate message in the database 3 to the reconnected client device 2 as it is. Transmit (step S107). When the midway message read from the database 3 is transmitted, the control unit 10 deletes the storage of the corresponding midway message from the database 3 (“keep_mqtt” table) (step S108), and terminates the retransmission process when resuming. The timing for deleting the midway message is not limited to this, and is appropriately designed when a corresponding message (puback / pubrec) is received.

  Processing in the flowcharts of FIGS. 15A and 15B will be described with reference to FIGS. FIG. 16 is a diagram illustrating a state where the client device 2 is disconnected from the server device 1. FIG. 16 shows an example in which arbitration is performed with QoS = 1. As shown in FIG. 16, after the server device 1 (b1), which is a broker, transmits a publish message to the client device 2 (s1), the session is disconnected before the puback message is returned (S101). The control unit 10 of 1 (b1) determines that the publish message remains in the transmission buffer (S102: YES). Accordingly, the server apparatus 1 (b1) stores the publish message as an intermediate message in the database 3 (“keep_mqtt” table) (S103). In FIG. 16, specifically, the time stamp ([TS]), the identification information (s1) of the client device (s1), and the publish message (topic = t1, packet_id = 0x101, data / payload = a, qos = 1) It is memorized as it is. As a result, the server apparatus 1 (b1) deletes the remaining publish message from the transmission buffer because it has not received the puback message (S104).

  FIG. 17 is a diagram showing a processing procedure when returning from the cut state of FIG. When the client device 2 (s1) is connected to the server device 1 (b1) or another server device 1 for communication, the server device 1 (b1 or other) detects this (S105), and is directed to the client device 2 (s1). It is determined whether the message is stored as intermediate message information in the database 3 (“keep_mqtt” table) (S106). In the case of FIG. 16, since the publish message for the client device 2 (s1) is stored, the control unit 10 of the server device 1 (b1) as the communication connection destination reads this from the database 3 (“keep_mqtt” table). Then, the packet is retransmitted as a packet including the packet ID or the like (S107). The publish message stored as the midway message is once deleted from the database 3 (“keep_mqtt” table) (S108). The client device 2 (s1) receives the publish message and transmits a puback message. In a state where the transmission of the puback message is completed, the untransmitted message is deleted from the transmission buffer on the server device 1 side and the midway message information in the database 3 (“keep_mqtt” table), and the initial state is restored. As a result, when the client device 2 as a subscriber is reconnected to any server device 1 when the message is disconnected in the middle of the message exchange, the message exchange related to the arrival guarantee in the MQTT that has been interrupted is performed. Complete.

  FIG. 18 is a diagram illustrating an example of another state in which the client device 2 is disconnected from the server device 1. FIG. 18 shows an example in which arbitration is performed with QoS = 2. When the QoS after the arbitration is “2” (the message transmission from the publisher and the designation from the subscriber are both “2”), between the server device 1 that is a broker and the client device 2 that is a subscriber. The disconnection pattern when the message exchange to be considered in the session is not completed is before the reception of the pubrec message indicated by the symbol X and before the reception of the pubcomp message indicated by the symbol Y. Before the pubrec message indicated by the symbol X is received, the server apparatus 1 determines that the publish message remains in the transmission buffer (S102: YES), as in the process shown in FIG. In the “keep_mqtt” table), the packet image of the publish message for the client apparatus 2 (s1) is stored as the midway message information (S103). The publish message is also deleted from the transmission buffer (S104). Before the pubcomp message indicated by the symbol Y is received, the server apparatus 1 determines that the pubrel message remains in the transmission buffer (S102: YES), so the database 3 ("keep_mqtt" table) A packet image of a pubrel message for the client device 2 (s1) is stored as message information (S103).

  FIG. 19 is a diagram showing a processing procedure when returning from the cut state of FIG. Also in this case, when the client device 2 (s1) communicates with the server device 1 (b1) or another server device 1, the server device 1 (b1 or other) detects this (S105), and the client device 2 (s1) ) Is stored in the intermediate message information in the database 3 ("keep_mqtt" table) (S106). When returning from the point where it was disconnected at the timing of the symbol X in FIG. 18, since the publish message for the client device 2 (s1) is stored as midway message information, the server device 1 (b1) of the connection destination The controller 10 reads this from the database 3 ("keep_mqtt" table) and retransmits it as a packet including the packet ID and the like as it is (S107). When returning from the point where it was disconnected at the timing before receiving the pubrec message with the code Y, the pubrel message for the client device 2 (s1) is stored. The control unit 10 of the server apparatus 1 (b1) reads this from the database 3 (“keep_mqtt” table) and retransmits it as a packet including the packet ID and the like as it is (S107). On the other hand, in the client apparatus 2 (s1), when the retransmission of the publish message is received after the reconnection, the client apparatus 2 (s1) discards the publish message and returns a pubrec message if it has already been received. When the retransmission of the pubrel message is received, the pubcomp message is returned to the server apparatus 1.

  Similarly, when the session with the client device 2 that is the publisher is disconnected before the transmission of the puback / pubrec message or the pubcomp message is completed, the server device 1 (b1) This is stored as intermediate message information in the database 3 ("keep_mqtt" table). When the client device 2 (s1) as a publisher reconnects, the control unit 10 of the server device 1 (b1) refers to the database 3 ("keep_mqtt" table) and stores a message to the communication partner. If so, the packet image is transmitted as it is.

  As described above, when disconnection is detected during the processing procedure of the MQTT model, a message is stored in the database 3 (“keep_mqtt” table) as intermediate message information. As a result, when a session is established again, the state immediately before that is restored. Even if the client device 2 (s1) as a subscriber makes a communication connection to a different server device 1, the intermediate message information stored in the database 3 ("keep_mqtt" table) is shared and synchronized by each server device 1. It is possible to restore the same situation.

(3) Communication Connection Between Brokers In the communication system 100, as shown in FIG. 1, a plurality of server devices 1 that are brokers are connected to each other in a mesh form, for example, several tens. When the server device 1 is started as a broker, it first establishes a communication connection with another connectable server device 1, exchanges information (“connections” table) on the client device 2 connected to itself, and shares Information synchronization processing is performed with reference to the database 3. Further, the connection between the server devices 1 is realized by the above-described keep connection. Note that the server device 1 performs subscribing on a topic specified by the client device 2 that is connected to the server device 1 by communication. The execution destination is another server device 1 to which the publisher of the specified topic is connected. In any case, the server device 1 designates QoS as “2 (Exactly once)”. When the session between the server apparatuses 1 is disconnected, even if a message required by the client apparatus 2 connected to the server apparatus 1 is transmitted in the meantime, a message held by another server apparatus 1 is acquired. It is possible to deliver.

[2. Multiple assurance levels]
In the communication system 100 according to the present embodiment, the message arrival guarantee to the subscribers is the keep connection between the server apparatuses 1 and the QoS between the servers when all the sessions are stably maintained without being disconnected. Realized by setting 2. The factors that hinder the arrival guarantee are the disconnection of the session and the down of the server device 1 that is a broker. As will be described later, the database 3 is used not only for the keep connection but also for guaranteeing the arrival, but the database 3 is guaranteed to be down by redundancy. In the communication system 100 according to the present embodiment, on the network N that passes through a plurality of brokers, the message (in accordance with the QoS level specified at the time of sending or subscribing to the publish message and the operation selection at the time of down in the broker ( Data) arrival.

  Whether the server device 1 that is a broker guarantees message processing up to that time when the server device 1 is down, that is, when the entity of the server device 1 disappears due to an error or the process is terminated by stopping the processing. Select whether to start or not. The server device 1 is premised on storing all processing in the database 3 when guaranteeing even when the server device is down.

  QoS is one of the options that are selected every time a publish message is sent to the server device 1 that is a broker to which the client device 2 is communicatively connected, or when specifying a topic to subscribe to. Recognize and execute subsequent processing. Note that the QoS for the specified topic of the client device 2 as a subscriber is maintained unless the subscription is canceled.

Processing contents according to the selection will be described in order. The assurance level is as follows.
(1) QoS = 0 (zero)
(2) QoS = 1, but not guaranteed if the broker is down (3) QoS = 1, guaranteed even if the broker is down (4) QoS = 2, but not guaranteed if the broker is down (5) QoS = 2, guarantees if the broker goes down

(1) QoS = 0 (zero)
A process related to transmission of each message regarding the message when the message is transmitted from the client apparatus 2 as the publisher with QoS = 0 (zero) will be described. When a publish message is sent from the client device 2 that is the publisher and QoS = 0 is specified, the setting of QoS = 2 for the subscribing between the servers and the QoS of the specified topic from the client device 2 that is the subscriber Regardless of the designation, QoS is arbitrated to “0 (zero)” in all sessions that are the route of this message. In this case, based on the transmitted publish message, the server device 1 that is a broker only transmits this message once to each of the client devices 2 or other server devices 1 that subscribe to the specified topic. Only the publish message shown in FIG. 3A is transmitted between the brokers, and the puback message and the pubrec / pubrel / pubcomp message are not exchanged.

  When the client device 2 as a subscriber designates “0 (zero)” as the QoS for the specified topic, the QoS of the message from the server device 1 as the broker to the client device 2 is “0 (zero)”. The server device 1 that transmits a message to the client device 2 receives the publish message of the topic designated by the client device 2 from the publisher or another server device 1 once and sends the publish message to the client device 2 once. Only transmit and finish the transmission / reception process. In this case, message transmission / reception between the client device 2 as a publisher and a broker to which the client device 2 is connected for communication, and message transmission / reception between brokers are performed by QoS (1 or Performed based on 2).

(2) QoS = 1, operation outside the broker down guarantee On the assumption that message arrival is not guaranteed when the broker goes down, the publisher device 2 sends a publish message specifying QoS = 1. The processing in the case will be described. In the following description, the message arrival to the subscriber when the client device 2 that is the subscriber that specifies the topic of the message specifies “1” or more as the QoS when the topic is specified will be described. In the case where the QoS for subscribing between servers is set to 2 and the QoS for the specified topic from the client device 2 as a subscriber is “1” or more, this QoS = 1 is set regardless of the QoS specification. QoS is arbitrated to “1” for all sessions that are message paths. Since the message transmission to the subscriber who designates “0 (zero)” at the time of specifying the topic is completed only by transmitting the publish message once as described in (1), the description is omitted.

(2.1) Normal Operation First, the order of processing in each server device 1 for a message of QoS = 1 will be described. When the server apparatus 1 receives a message from the client apparatus 2 as the publisher based on the server program 1P stored in the first storage unit 11, the server apparatus 1 responds to the publisher according to the designated QoS (puback message). return it. If the timing of this response is an MQTT model, the order may be maintained for each session (see FIG. 3). On the other hand, the server apparatus 1 in the communication system 100 has an order for message transmission / reception timing with the client apparatus 2 as a subscriber or the server apparatus 1 as another broker based on the publish message transmitted from the publisher. Returns a response to the publisher.

  FIG. 20 is a flowchart illustrating an example of a processing procedure of message delivery by the server device 1 that is a broker. The processing procedure shown in the flowchart of FIG. 20 corresponds to the details of step S9 in the procedure shown in the flowchart of FIG.

  The control unit 10 of the server apparatus 1 determines whether or not a publish message has been received from one or a plurality of client apparatuses 2 that have established a communication connection as a publisher, or from another server apparatus 1 (step S201). If it is determined that the data has not been received (S201: NO), the control unit 10 returns the process to step S201.

  If the control unit 10 determines that it has been received (S201: YES), the control unit 10 extracts the topic of the received publish message (step S202), and designates the extracted topic as another device to which it has subscribed. It is determined whether or not the server apparatus 1 is included (step S203).

  When it is determined in step S203 that no other server device 1 is included (S203: NO), the control unit 10 is a subscriber who is connected to the communication and designates the extracted topic. The publish message received in step S201 is transmitted to the client device 2 (step S204). In step S <b> 204, the control unit 10 sets the transmission destination to the database 3 when there is a client device 2 that has selected keep connection and the session is disconnected. Subsequently, the control unit 10 returns a puback message to the transmission source (publisher or other server device 1) of the received publish message (step S205), and ends the publish message distribution process. In step S204, when writing to the database 3 because the subscriber who specified the extracted topic has disconnected the communication connection, the writing to the database 3 is performed.

  When it is determined that the other server device 1 is included (S203: YES), the control unit 10 proceeds to step S201 to the client device 2 and the other server device 1 that are subscribers that specify the extracted topic. The publish message received in step S206 is transmitted (step S206). Even in step S206, when the database 3 is the delivery destination, writing to the database 3 is performed instead of transmission.

  The control unit 10 determines whether or not the puback message has been received from all the other server apparatuses 1 among the transmission destinations of the publish message in step S206 (step S207). When it is determined that the puback message is not received from all the execution destination server devices 1 (S207: NO), the control unit 10 waits until the puback message is received.

  If it is determined in step S207 that the puback message has been received from all of the execution destination server apparatuses 1 (S207: YES), the control unit 10 sends the message received in step S201 to the publisher or other server apparatus 1 that has transmitted the message. A puback message is returned (step S208), and the publish message distribution process is terminated.

  It should be noted in the procedure shown in the flowchart of FIG. 20 that when transmitting a publish message for the extracted topic, there is one or more other server apparatuses 1 that subscribe to the topic at the transmission destination. In this case (S203: YES), the puback message is not returned to the publisher or other server device 1 that sent the message until the puback message is received from all the other server devices 1 (S207: YES). . When no other server device 1 is included in the transmission destination, the puback message is transmitted immediately as shown in step S205, and this provides order. As a result, it is guaranteed that the transmission process to the client apparatus 2 is completed, and even if the transmission is made via another server apparatus 1, it is guaranteed that the transmission process to the client apparatus 2 ahead is completed.

  Until the puback message is received from all of the other server devices 1 (S207: YES), the control of not returning the puback message to the publisher or the other server device 1 that sent the message is sent to each server device 1. In consideration of the fact that a plurality of client devices 2 are connected for communication and a large number of messages are transmitted and received for a large number of topics, it is preferable to carry out the following specifically. When receiving the publish message, the control unit 10 initializes a count corresponding to the one message, and performs a transmission process to the client device 2 and the server device 1 using the topic of the one message as a designated topic. And the count is increased for each transmission process. When sending to the client device 2, the count of the target is decreased when the completion of the publish message transmission process (writing to the socket) is detected. When writing to the database 3, the completion of writing is detected. At that point, the target count is decreased. When a publish message is transmitted to a plurality of client devices 2, the number of counts increased each time a socket is written to each of the client devices 2 decreases when the transmission to all client devices 2 is detected. . When no other server apparatus 1 is included in the transmission destination, the completion of transmission to all client apparatuses 2 is detected, and the puback message is transmitted to the transmission source of the one message when the count number reaches the initial value. Is done. When the other server apparatus 1 is included, the count number remains increased when the transmission process to the other server apparatus 1 is completed. At the timing when the reception of the puback message from the other server apparatus 1 can be detected, the control unit 10 decreases the count corresponding to the one message and counts by receiving the puback message from all the other server apparatuses 1. When the number reaches the initial value, a puback message is transmitted to the transmission source of the one message.

  The procedure shown in the flowchart of FIG. 20 will be specifically described. FIG. 21 is an explanatory diagram showing the transmission order. In the explanatory diagram of FIG. 21, an example in which only one broker is interposed between the client device 2 that is a publisher and the client device 2 that is a subscriber whose designated topic is a topic of a message transmitted from the publisher is given. Explains. In the explanatory diagram of FIG. 21, a numerical value indicating the order of each message is given. As the numerical value is smaller, the processing is executed earlier in time, meaning that the same thing may be performed simultaneously or before and after. Specifically, in the example shown in FIG. 21, a publish message is transmitted from the client device 2 (p1) first (timing (10)). In response to this, the server device 1 receives the client at the timing (30) after the message transmission timing (20) to the client device 2 (s1) which is a subscriber having the topic “t1” of the message as the designated topic. A puback message is returned to the device 2 (p1). Whether or not the puback message is returned from the client device 2 (s1) depends on the design of the client device 2 and is unknown. Therefore, the server device 1 (b1) sends the puback message to the client that is the publisher without waiting for this. Return to device 2 (p1).

  In addition, the server device 1 that is communicatively connected to the client device 2 that is a publisher, when the server device 1 that is another broker is connected to the server device 1, designates the topic of the publish message transmitted by the publisher. A message is transmitted to the server device 1. Then, the server device 1 in the communication system 100 waits for another server device 1 to return a puback message, and then returns a puback message to the publisher. The other server apparatus 1 (s) returns a puback message after transmitting a corresponding publish message to the client apparatus 2 which is a subscriber connected to each other. Note that all connections between the server apparatuses 1 in the communication system 100 are keep connections as described above.

  FIG. 22 is an explanatory diagram showing another example of the transmission order. In the explanatory diagram of FIG. 22, two brokers are interposed between the client device 2 (p1) as a publisher and the client device 2 (s1) as a subscriber whose designated topic is the topic of a message transmitted from the publisher. An example is given. In the explanatory diagram of FIG. 22, each message is given a numerical value indicating the order. As the numerical value is smaller, the processing is executed earlier in time, meaning that the same thing may be performed simultaneously or before and after.

  In the example shown in FIG. 22, specifically, a case where a publish message is transmitted from the client apparatus 2 (p1) with QoS = 1 specified at the first timing (10) will be described. The server apparatus 1 (b1) transmits the publish message transmitted from the client apparatus 2 (p1) to the other server apparatuses 1 (b2 and b3) connected to itself at the timing of (20). When the other server device 1, for example, the server device 1 (b2) receives the publish message transmitted from the server device 1 (b1), the client device 2 (s1) which is a subscriber having the topic “t1” as the designated topic. The publish message is transmitted to the server device 1 (b1) at timing (40), and then the puback message is returned to the server device 1 (b1). Whether or not the puback message is returned from the client device 2 (s1) at the timing of (40) depends on the design of the client device 2 and is unknown, so the server device 1 (b2) does not wait for this and puback The message is returned. The server apparatus 1 (b1) determines whether or not a puback message has been returned before or after the timing of (40) from any of the server apparatuses 1 (b2 and b3) that transmitted the message of the topic “t1”. When the server apparatus 1 (b1) confirms that the puback message has been returned from all the server apparatuses 1 (b2 and b3) that are the transmission destinations of the message about the topic “t1,” the client apparatus 2 that is the publisher A puback message is returned to (p1) at the timing of (50). As a result, the client device 2 (p1) that is the publisher has received the puback message from the server device 1 (b1) at the timing (50), so that the client device 2 that is the subscriber having this as the designated topic is notified. You can recognize that a publish message has arrived (not an acknowledgment). In this sense, the communication system 100 can guarantee not only the arrival guarantee for each session but also the arrival of the message to the subscriber with QoS = 1.

(2.2) Disconnection Disconnection in the case where a publish message with QoS = 1 specified is sent and QoS is arbitrated to “1” in all sessions on the assumption that the broker is not guaranteed if it is down The processing at the time will be described for each cutting point. FIG. 23 is a diagram illustrating a connection configuration of the server device 1 and the client device 2. FIG. 23 shows that two brokers are connected between a client device 2 (p1) that is a publisher and a client device 2 (s1) that is a subscriber having a topic of a message transmitted from the publisher as a designated topic with QoS = 1. The connection structure in the case of interposition is shown. In the connection configuration of FIG. 23, the client device 2 (p1), which is a publisher, is communicatively connected to the server device 1 (b1), which is a broker (session E). The client device 2 (s1) that is a subscriber is connected to a server device 1 (b2) that is another broker (session F). Two brokers are also connected for communication (session G).

(2.2.1) Between Publisher and Broker A description will be given of arrival guarantee when session E in FIG. 23 is disconnected. Regarding the disconnection of communication between the publisher and the broker (session E) when a publish message specifying QoS = 1 is transmitted from the client device 2 that is the publisher, the client device 2 (p1) that is the publisher Consider a case where a publish message is disconnected after being sent.

  In this case, the client device 2 (p1), which is a publisher, keeps the publish message temporarily stored in the transmission buffer until a puback message for the transmitted publish message is returned (FIG. 3). The server apparatus 1 (b1) completes the transmission of the publish message to the other server apparatus 1 (b2) for the publish message received before being disconnected, and the other server apparatus 1 at the timing of (40). There is a possibility that the puback message was received from (b2) and an attempt was made to send the puback message. However, the server device 1 (b1) cannot transmit this puback message because the session E is disconnected.

  The client device 2 (p1) executes a communication connection request to the server device 1 (here, b1, which may be another broker) which is a broker. When the session E is established in response to the request, the client device 2 (p1) transmits the publish message temporarily stored in the transmission buffer to the connection destination server device 1 (b1) in a new session. The connection destination server apparatus 1 (b1) processes the publish message retransmitted from the reconnected client apparatus 2 as a new publish message. Even in this case, arrival guarantee is achieved without any problem in the process of QoS = 1, and the client apparatus 2 (p1) as the publisher can recognize that the message has been transmitted to the client apparatus 2 (s1) as the subscriber.

(2.2.2) Between Broker and Subscriber The arrival guarantee when the session F in FIG. 23 is disconnected will be described. When the session F is disconnected before the server apparatus 1 (b2) transmits the publish message to the client apparatus 2 (s1) at the timing (30), the keep connection process (FIGS. 10 to 12) Delivered from database 3 after reconnection.

  If the session F in FIG. 23 is disconnected before sending the puback message from the client device 2 (s1) to the server device 1 (b2) at the timing of (40), the database 3 (“keep_mqtt” table) The interrupted exchange is resumed by the processing referring to the midway message information (FIGS. 15 to 17), and the message exchange is completed.

(2.2.3) Broker-Broker Session As described above, keep connection is selected for the session between brokers. FIG. 24 is a flowchart illustrating an example of a processing procedure in the server device 1 when the brokers are disconnected. Note that the processing shown in the flowchart of FIG. 24 is basically executed by the server device 1 on the publisher side (that is, the sender side in FIG. 3). The processing of the server device 1 on the subscriber side is executed with a part omitted.

  When the control unit 10 of the server apparatus 1 detects disconnection of the session with the other server apparatus 1 (step S301), the client apparatus 2 keep-connected to the other server apparatus 1 as a subscriber is stored in the database 3 ("keep_sub" table). ) From the session information (step S302).

  The control unit 10 treats the extracted status information of the client device 2 as the client device 2 connected to itself, and temporarily stores it (step S303). However, for this client device 2, the message delivery destination is set in the database 3 (see FIG. 8 as in the disconnected state after keep connection). Then, the control unit 10 determines whether or not a publish message for another server device 1 (subscriber side) remains in the transmission buffer according to the processing procedure shown in the flowchart of FIG. 15A (step S304). When it is determined that it remains (S304: YES), the control unit 10 does not use this publish message as halfway message information, but originally a client device 2 that has established a session with another server device 1. Is stored in the database 3 as a message that should have been sent to (step S305). The publish message remaining in the send buffer is deleted. Since the message is stored in the database 3, the control unit 10 transmits the puback message to the transmission source (publisher side) of the original publish message (step S306). At this time, the payload included in the publish message is stored in the database 3 (“store” table) together with the identifier as a saved message. Information indicating that the message should be transmitted to the subscriber via the disconnected other server device 1 is stored in the database 3 (“store_target_broker_user” table) as distribution destination information of the stored message. The distribution destination information via the broker includes an information identifier (ID), identification information (broker_id) of the server device 1 that has detected the disconnection, and a packet ID used when transmitted to the other server device 1 that has been disconnected. (Broker_pid), identification information (user_id) of the destination client apparatus 2, and an identifier (store_id) of the stored message that should have been transmitted. Also, in the distribution destination information via the broker, the packet ID at the time of retransmission (pid, whether it is retransmitted) used in the processing of QoS = 2 described later, and whether transmission to the retransmission destination is completed (already_sent, etc. Information on whether or not a pubrec message is received from the server apparatus 1 is included. Of course, the table name is an example.

  If it is determined in step S304 that the message does not remain (S304: NO), the puback message for the publish message has been received, and the puback has been transmitted to the transmission source (publisher side) of the original publish message. Advances to the next Step S307.

  When the control unit 10 of the server apparatus 1 reestablishes a session with the other server apparatus 1 (step S307), as described in “(1.3.) Communication connection between brokers”, the synchronization process between brokers Is executed (step S308). It should be noted that the period from when disconnection is detected until the session is established again is usually within 10 seconds, for example, 3 to 5 seconds. Note that the control unit 10 establishes all the sessions between the re-established brokers as new ones, and refreshes all the packet IDs and the like assigned in the session before disconnection.

  The control unit 10 of the server apparatus 1 identifies the identification information of the client apparatus 2 that is a subscriber temporarily stored as being connected to the server apparatus 1 and the connection destination information of each client apparatus 2 stored in the database 3 (“ "connections") (step S309). The connection destination information (“connections”) is information that is stored each time the server device 1 establishes a session with the client device 2, and the client device 2 (both subscriber and publisher) is connected to any server device 1 for communication. It is the information which memorized whether it is doing. Even if the connection destination information about the client device 2 that is kept connected is disconnected, it is retained in the database 3 until a non-keep connection is made. When the communication connection destination is changed, it is overwritten with the identification information of the connection destination server device 1.

  As a result of the collation in step S308, the control unit 10 of the server device 1 is connected to itself, and the connection stored in the database 3 for the client device 2 (if there are a plurality of devices) whose status information is online. Based on the previous information, it is determined whether or not the connection destination is itself (step S310).

  When it is determined that it is not itself (S310: NO), the control unit 10 deletes the information of the client device 2 that is the target subscriber from the information of the client device 2 connected to itself (step S311), Terminates the restart process.

  If it is determined in step S310 that it is itself (S310: YES), the control unit 10 determines whether it is determined in step S304 that it remains (step S312). If it is determined that it remains (S312: YES), the control unit 10 reads out the stored message that should have been transmitted in step S305 (step S313), and transmits it to the client device 2 that is a subscriber (step S313). S314). Thereafter, the control unit 10 receives a puback message from the destination client device 2 (step S315), and deletes the distribution destination information and the stored message (step S316). If it is not determined in step S312 that it remains (S312: NO), the control unit 10 ends the message processing at the time of re-establishing the session.

  In the server device 1 on the subscribing side, steps S302 and S303 are omitted.

  The processing shown in the flowchart of FIG. 24 will be specifically described. 25 to 27 are explanatory diagrams illustrating an example of processing when the session G between brokers in the connection configuration illustrated in FIG. 23 is disconnected. FIG. 25 shows an example of contents of information stored in the database 3 when the session G is disconnected. The server apparatus 1 (b1) transmits a publish message to the server apparatus 1 (b2) at the timing (20) based on the message from the publisher at the timing (10). The server device 1 (b1) detects disconnection of the session with the destination server device 1 (b2) (S301). The server device 1 (b1) stores the identification information of the client device 2 (s1) that should be connected as a subscriber to the server device 1 (b2) to which the disconnected session is connected as a database 3 ("keep_sub" table). (S302). The server device 1 (b1) temporarily stores the status information of the identification information “s1” of the client device 2 by specifying the distribution destination in the database 3 (S303). The publish message transmitted at the timing of (20) remains in the transmission buffer because the puback message cannot be received (S304: YES), and the server apparatus 1 (b1) reads the remaining publish message, It is stored in the database 3 ("store" table and "store_target_broker_user" table) as a message (stored message and delivery destination information via the broker) that should have been transmitted from the server apparatus 1 (b2) (S305). In the example of FIG. 25, the stored message with the identifier “345” and the distribution destination information including the identifier “345” of the stored message (broker_id = b1, broker_pid = 0x123, user_id = s1, pid = NULL, store_id = 345, already_sent = false) is stored. Since the server device (b1) stores the publish message in the database 3, the server device (b1) transmits a puback message to the client device (p1) which is the publisher at the timing of (30). As a result, the server apparatus 1 (b1) can return a puback message to the client apparatus 2 as a publisher after ensuring that the message can be transmitted via all the server apparatuses 1.

  At this time, if the server apparatus 1 (b2), which is the broker to which the client apparatus 2 (s1) is connected, receives a publish message from the server apparatus 1 (b1) before disconnecting the session G, then Soon, the server device 1 (b2) performs processing such as transmitting a publish message to the client device 2 (s1) and receiving a puback message. If the puback message cannot be sent in response to the publish message, it can be refreshed by disconnecting the session.

  FIG. 26 shows an example when the session G is re-established from the state shown in FIG. In the example of FIG. 26, when the server apparatus 1 (b2) has not received the publish message before the session G is disconnected, or the session F is disconnected at that timing, the publish message from the publisher arrives. A case where it has not been described will be described. When the synchronization processing is completed between the server apparatuses 1 (b1, b2) (S308), the server apparatus 1 (b1) receives the identification information “s1” of the client apparatus 2 (s1) storing the state information and the database 3 Is compared with the identification information “s1” in the connection destination information (“connections”) of each client device 2 stored in (S309). Since the server apparatus 1 (b1) is not the connection destination in the connection destination information for the client apparatus 2 (s1) (S310: NO), the server apparatus 1 (b1) deletes the status information about the client apparatus 2 (s1) (S311).

  Also on the server device 1 (b2) side, when a session with the server device 1 (b1) is re-established (S307), synchronization processing is performed (S308). The server apparatus 1 (b2) uses the identification information “s1” of the client apparatus 2 (s1) storing the state information and the connection destination information (“connections”) of each client apparatus 2 stored in the database 3. The identification information “s1” is collated (S309). The server apparatus 1 (b2) determines that the client apparatus 2 (s1) is a connection destination (S310: YES). The server device 1 (b2) reads the publish message based on the stored message stored in the database 3 ("store" and "store_target_broker_user" table) and the delivery destination information via the broker (S313), and assigns the packet ID. For example, it transmits to the client apparatus 2 (s1) at the timing of (50) (S314). Thereafter, when the server device (b2) receives the puback message returned from the client device 2 (s1) at the timing of (60) (S315), the stored message and the delivery destination information are deleted (S316). As a result, even when the broker / broker is disconnected, it is possible to achieve message arrival at the subscriber side with QoS = 1 (“At least One”). If the publish message has been received on the server device 1 (b2) side when the session G is disconnected and has been transmitted to the client device 2 (s1) as a subscriber, the broker / broker A publish message having the same content is transmitted separately with a new packet ID based on the stored message stored by the disconnection and the delivery destination information. However, since QoS = 1 is received at least once, there is no problem.

  FIG. 27 is an explanatory diagram showing another example of processing after the session G between brokers is re-established. In FIG. 27, the session G is re-established from the state shown in FIG. 25, but before that, the client device 2 (s1), which is a subscriber who has established a session with the server device 1 (b2), An example in the case where a situation occurs in which the connection destination is changed to the server device 1 (b1) during disconnection is shown. In FIG. 27, the client device 2 (s1) requests the server device 1 (b1) to establish a session, and if this is accepted, the server device 1 (b1) rewrites the connection destination information in the database 3 to the identification information “b1”. . Thereafter, synchronization processing is executed, and connection information is shared between the server apparatuses 1 (b1 and b2). In this case, the server apparatus 1 (b1) uses the identification information “s1” of the client apparatus 2 storing the state information and the connection destination information (“connections”) of each client apparatus 2 stored in the database 3. The identification information “s1” is collated (S309), and it is determined that the connection destination information itself is the connection destination (S310: YES). The server device 1 (b1) reads the publish message that should have been transmitted from the server device 1 (b2) stored in the database 3 (“store” and “store_target_broker_user” table) at the timing of (50), for example. (S313) A publish message is transmitted to the client apparatus 2 (s1) with a new packet ID (S314). The stored message and the delivery destination information stored in the database 3 are deleted when the server device 1 (b1) receives the puback message transmitted from the client device 2 (s1) at the timing (60) (S315). (S316).

  In the example shown in FIG. 27, when the server device 1 (b2) side re-establishes a session with the server device 1 (b1) (S307), synchronization processing is performed (S308). The server device 1 (b2) collates the identification information “s1” in the connection destination information (“connections”) of each client device 2 stored in the database 3 with the status information (S309), and if it is not the connection destination itself Judgment is made (S310: NO). The server apparatus 1 (b2) deletes the status information about the client apparatus 2 (s1) (S311). The processing for the client device 2 (s1) is left to the server device 1 (b1) side as described above.

  As described above, even when the session between brokers is disconnected during the exchange of the message for guaranteeing arrival in the MQTT model, the message arrives in the path from the client device 2 as a publisher to the client device 2 as a subscriber. The guarantee can be QoS = 1.

  Next, a process when a publish message is newly received from the publisher or another server device 1 on the publisher side during the session re-establishment during steps S305 and S306 in the flowchart of FIG. 24 will be described. FIG. 28 is a flowchart illustrating an example of a message processing procedure during disconnection between brokers. Of the processing procedures shown in the flowchart of FIG. 28, the same steps as those in the flowchart of FIG.

  When the control unit 10 of the server device 1 that is the broker receives the publish message (S201) and determines that this message is to be transmitted to another server device 1 (S203: YES), any of the server devices 1 that are the transmission destinations. It is determined whether or not the session between the two is disconnected (step S211). When it is determined that the session is not disconnected (S211), the control unit 10 transmits a publish message to the other server apparatus 1 (S206), and determines that the puback message has been received from all the other server apparatuses 1. From (S207: YES), a puback message is returned to the transmission source (S208).

  When it is determined in step S211 that the session is disconnected (S211: YES), the control unit 10 stores the session information about the client device 2 that is a subscriber whose communication connection destination is the partner server device 1 in the database 3 (“ Reference is made from the “keep_sub” table) (step S212). Based on the referenced session information, the control unit 10 updates the subscriber status information extracted and stored (step S213). For example, if the subscriber stored in step S303 in the flowchart of FIG. 24 has stopped subscribing during disconnection, this may be reflected and excluded from the distribution destination of subsequent publish messages. Based on the updated status information, the control unit 10 relates to the client device 2 that is a subscriber whose distribution destination is the database 3, and stores the publish message received in step S201 in the database 3 ("store" and "store_target" tables). The distribution destination information is stored (step 214). Then, the control unit 10 ends the processing of the message being disconnected.

  When returning from the disconnection, any server device 1 may distribute the publish message from the database 3 in accordance with the connection destination of the subscriber in step S310 and subsequent steps in the flowchart of FIG.

  As shown in the flowchart of FIG. 28, the control unit 10 of the server device 1 is disconnected (in most cases, between 3 seconds and 5 seconds), and each time a publish message is received, the connection destination of each client device 2 during that time The state information in which the information itself is temporarily stored is adapted. During the disconnection, the subscriber client device 2 whose communication destination is the server device 1 that is the partner of the disconnected session stops subscribing (unsubscribe), newly subscribes, and other topics Even in the case of subscribing, the message can be transmitted without fail by adapting the state information.

  When broker down is not guaranteed, information is stored in the database 3 at a minimum, so that it is possible to avoid a reduction in transmission / reception speed while guaranteeing QoS = 1. Instead, when all of the server devices 1 that are brokers are down, all temporary storage of status information (such as online or database) of the client device 2 connected to itself is lost. Since a session between brokers is newly established at the time of startup, all information stored corresponding to the session is lost when the session is down. Since collation in step S309 and the like cannot be performed, the message with QoS = 1 is lost.

(3) QoS = 1, broker down guarantee Assuming that message arrival is guaranteed even when the broker goes down, QoS is adjusted so that QoS is “1” in all sessions on the path as in (2). Explain how the publish message with = 1 specified reaches the subscriber. That is, (2) Similarly, when the client device 2 which is a subscriber specifies the topic with QoS = 1 or = 2, the publisher sends a publish message specifying QoS = 1 for the topic. It is. The processing for transmitting this message to a subscriber who designates “0” at the time of specifying a topic has been described in (1), and will not be described.

(3.1) During normal operation When message arrival is guaranteed when the broker is down, it cannot be detected by itself, so it cannot be switched to processing when it is down. Therefore, whether to guarantee arrival when down is selected when an instance of the broker (server apparatus 1) is generated. The server device 1 that is a broker activated by selecting to perform arrival guarantee even when it goes down is basically a client that is a publisher as long as there is at least one client device 2 that is kept connected to itself. Each time a publish message is received from a device or another server device 1, the storage message and the delivery destination information are stored in the database 3 (“store” and “store_target” tables). Each time the server apparatus 1 receives a puback message for a publish message, the server apparatus 1 executes a process of updating or deleting the stored message and the delivery destination information (see FIGS. 7 to 12). When the client apparatus 2 as a subscriber is connected to the server apparatus 1 by communication, the server apparatus 1 keeps the order of transmitting the puback message to the client apparatus 2 as a publisher after transmitting the publish message. Similarly, when the server apparatus 1 transmits a publish message to another server apparatus 1, the server apparatus 1 receives the puback message from all the other server apparatuses 1 and then sends the puback message to the client apparatus 2 side that is the publisher. The order of transmission is maintained (see FIGS. 20 to 22).

  FIG. 29 is a flowchart illustrating an example of a transmission procedure in the server apparatus 1 that guarantees broker down. The processing procedure shown in the flowchart of FIG. 29 corresponds to the details of step S9 in the procedure shown in the flowchart of FIG. Also, among the processing procedures shown in the flowchart of FIG. 29, the steps common to the processing procedure shown in the flowchart of FIG. 20 when broker down is not guaranteed are assigned the same step numbers and detailed description is omitted. .

  When the publish message is received in step S201 (S201: YES), and the control unit 10 of the server device 1 determines that no other server device 1 is included in the transmission destination (SS203: NO), It is determined whether or not there is a client apparatus 2 that is a subscriber connected by communication by selecting keep connection as the transmission destination for the topic extracted in S202 (step S221). When it is determined that there is no client device 2 that has selected keep connection (S221: NO), the control unit 10 of the server device 1 transmits a publish message to the client device 2 that is connected to and communicates with itself (S221: NO). In step S204, a puback message is returned to the transmission source (S205). If it is determined in step S221 that there is a client device 2 that has selected keep connection (S221: YES), the control unit 10 determines whether the publish message and the session message are disconnected regardless of whether or not a session disconnection has occurred. The information of the delivery destination that is the keep connection is stored in the database 3 (“store” and “store_target” tables) as a stored message and delivery destination information (step S222), and then a publish message is transmitted to the target client device 2. (S204).

  Then, the control unit 10 of the server device 1 transmits the puback message to the publish message transmission source side (S205), and then determines whether or not the control unit 10 determines again that it exists in step S221 (step S223). ). If it is determined that it does not exist (S223: NO), the control unit 10 ends the process of receiving one publish message as it is.

  If it is determined in step S223 that it exists (S223: YES), the control unit 10 pubacks from the existing client device 2, that is, the client device 2 that keeps connected to itself by specifying the extracted topic. It is determined whether a message has been received (step S224). If it is determined that it has not been received (S224: NO), the process of the next step S225 is not performed until the control unit 10 determines that it has been received. When it is determined that the puback message has been received (S224: YES), the control unit 10 deletes the publish message and keep connection destination information stored in step S222 from the database 3 (step S225), and The reception process ends.

  When it is determined in step S203 that another server device 1 is included (S203: YES), the control unit 10 extracts the topic extracted in step S202 from the session information ("keep_sub") shared in the database 3 It is determined whether or not there is a subscriber connected for communication by selecting keep connection as the transmission destination from the other server apparatus 1 of the transmission destination (step S226). If it is determined in step S226 that it does not exist (S226: NO), the control unit 10 transmits the publish message as it is to another server device 1 (S206). In this case, the control unit 10 receives the puback message from all the other server apparatuses 1 that subscribe to the topic (S207: YES), and then transmits the puback message to the transmission source (S208). The message reception process ends.

  If it is determined in step S226 that the session exists (S226: YES), the control unit 10 stores the publish message (stored message) and keep connection distribution destination information in the database regardless of whether or not the session is disconnected. 3 ("store" and "store_target_broker" table) (step S227), and then transmits a publish message to the other server apparatus 1 (S206).

  The control unit 10 of the server apparatus 1 receives the puback message from all the other server apparatuses 1 that subscribe to the topic (S207: YES), and then transmits the puback message to the transmission source (S208). In step S226, the control unit 10 again determines whether or not it is determined that there is a client device 2 that is a subscriber connected by communication by selecting keep connection (step S228). If it is determined that it does not exist (S228: NO), the control unit 10 ends the process of receiving one publish message as it is.

  If it is determined in step S228 that it exists (S228: YES), the publish message and keep connection destination information (stored message and delivery destination information) stored in step S227 are deleted from the database 3 (step S229). Terminates publish message reception processing.

  The processing shown in the flowchart of FIG. 29 will be specifically described with reference to the drawings. FIG. 30 to FIG. 33 are diagrams showing processing when guaranteeing broker down with QoS = 1. FIG. 30 shows processing in the client apparatus 2 (p1) as a publisher and the server apparatus 1 (b1) that has established sessions A, B, and C with the client apparatus 2 (s1, s2) as subscribers. ing. When the server apparatus 1 (b1) receives a publish message for the topic “t1” from the publisher client apparatus 2 (p1) at the timing (10) (S201: YES), the server apparatus 1 (b1) specifies the topic “t1” and keep connection The received publish message is transmitted at the timing of (20) to the client apparatus 2 (s1) connected by communication selection (S204). Before that, the server device 1 (b1) stores the destination message in the database 3 (“store” and “store_target” table) including the stored message including the message content “a” and the identification information “s1”. Are stored together with the packet ID number assigned when the publish message is transmitted (S222). The server apparatus 1 transmits the publish message of the topic “t1” at the timing of (20) because the client apparatus 2 (s2) also specifies the topic “t1” (S204), but the client apparatus 2 (s2) Since the keep connection is not selected, the distribution destination information of the identification information “s2” is not stored in the database 3.

  FIG. 31 shows processing after a lapse of time from the state of FIG. First, the server apparatus 1 transmits a puback message to the client apparatus 2 (p1) as the publisher at the next timing (30) by transmitting the publish message to the client apparatus 2 (s1, s2). When a puback message is transmitted from the client device 2 (s1) before or after this (for example, at timing (35)), the server device 1 uses the packet ID and the transmission source of the puback message as a key in the database 3 (“store_target "Destination information is searched from" table "). The search result for the client device 2 (s2) not selecting the keep connection is zero (empty), but the client device 2 (s1) selecting the keep connection is searched as shown in FIG. . The server apparatus 1 (b1) deletes the record upon receiving this puback message (S225). When the server apparatus 1 (b1) determines that the delivery destination information is empty for the same stored message (identifier: 123 information in the “store” table), the server apparatus 1 (b1) uses this as the stored message that is no longer referenced. Delete from the “store” table) (S225).

  FIG. 32 shows processing in the server apparatus 1 (b1) that is the broker that has established the session E with the client apparatus 2 (p1) that is the publisher for the topic “t1”. The server device 1 (b1) mediates a message with another server device 1 (b2) to which the client device 2 (s1), which is a subscriber having the topic “t1” as a designated topic, is connected. The server apparatus 1 (b1) receives a publish message for the topic “t1” from the client apparatus 2 (p1), which is the publisher, at the timing of (10) (S201: YES). In this case, the server apparatus 1 (b1) has a client apparatus 2 (s1) that is connected to the server apparatus 1 (b2) by specifying the topic “t1” and selecting keep connection. (S226: YES). The server apparatus 1 (b1) transmits the publish message received from the publisher at the timing of (20) (S206), but before that, the stored message and distribution to the database 3 ("store" and "store_target_broker" tables) The previous information is stored (S227). In the example of FIG. 32, the distribution destination information (source_id = b1, target_id = b2) including the storage message with the identifier “567”, the identifier “567” of the storage message, and the packet ID “0x123” used at the time of transmission. , packet_id = 0x123, store_id = 567, already_sent = false) are stored.

  FIG. 33 shows processing after a lapse of time from the state of FIG. The server apparatus 1 (b2) transmits the puback message at the next timing (40) by transmitting the publish message transmitted from the server apparatus 1 (b1) to the client apparatus 2 (s1) as the subscriber. Even if the puback message is transmitted at the timing of (45) from the client device 2 (s1), the puback message is transmitted from the server device 1 (b2) without waiting for this. When the server apparatus 1 (b1) receives the puback message from all the other server apparatuses 1 (b2) (S207: YES), the puback message is sent to the client apparatus 2 (p1) as the publisher, for example, at the timing of (50). Is transmitted (S208). When the server apparatus 1 (b1) receives the puback message from the server apparatus 1 (b2), the distribution destination information from the database 3 ("store_target_broker" table) with the packet ID and the source of the puback message (target_id = b2) as a key Search for. In step S226, it is determined that there is a client device 2 (s1) that is in communication connection by selecting keep connection (S228: YES), and distribution destination information should be searched. (B1) deletes the distribution destination information of the search result from the database 3 (“store_target_broker” table) (S229). When the server apparatus 1 (b1) determines that the delivery destination information is empty for the same stored message (identifier: 567 in the “store” table), the server apparatus 1 (b1) stores the stored message that is no longer referred to in the database 3 (“store” table). ) (S229).

  The server apparatus 1 (b1), which is a broker activated by selecting to guarantee the arrival of a message even when the broker is down, is processed as shown in FIG. 29 to FIG. 33 even if no disconnection or broker down occurs after the activation. Execute. Every time a publish message is received, writing to the database 3 is executed, and every time a puback message is received, deletion is executed. Therefore, when there is a client device 2 connected to keep, there is a certain amount of message transmission / reception. It takes time. In this regard, the database 3 is configured by KVS (Key-Value Store), and all the creations, updates, and deletions are stored as events, thereby reducing the time required for processing to the database 3 as much as possible. It becomes possible.

(3.2) When disconnection or down occurs When a session disconnection occurs, each of the server devices 1 can detect the disconnection, and executes the same processing as the processing shown in the flowchart of FIG. When guaranteeing message arrival even when the broker is down with QoS = 1, each server device 1 repeatedly stores and deletes data in the database 3 even during normal operation for the client device 2 with keep connection as described above. is doing. When the cause of the disconnection is a broker down of another server apparatus 1, in the case of guaranteeing the message even when the broker is down, it is not the database remaining in the transmission buffer of the network controller, but the database 3 (“store_target_broker” It is determined whether the stored message and the delivery destination information that have not been deleted remain in the table. That is, the server device 1 determines whether or not a message remains in the database 3 instead of the transmission buffer in step S304 in the flowchart of FIG. When it is determined that the message remains (S304: YES), the control unit 10 uses the message remaining in the database 3 as a client device 2 that has already established a session with another server device 1. Is stored (moved) in the database 3 ("store_target_broker_user" table) as a message (stored message and delivery destination information via the broker) that should have been sent to (S305).

  The server apparatus 1 that is a down broker cannot detect its own down, and the temporary storage information in the transmission buffer of the network controller is also lost. Therefore, the server apparatus 1 that has been down cannot perform the saving and saving process for the remaining messages as shown in steps S304 and S305 in the flowchart of FIG. In addition, the server apparatus 1 that has been down cannot save and save the message that is being disconnected shown in steps S211 to S214 in the flowchart of FIG. Therefore, the restarted server device 1 refers to the message stored in the database 3 by the other server device 1 and transmits the message transmitted during down to the client device 2.

  FIG. 34 is a flowchart illustrating an example of a processing procedure when the server apparatus 1 is activated. When activated, the control unit 10 of the server device 1 establishes a session with each of the client device 2 and the other server device 1 (step S401), and executes synchronization processing with the other server device 1 in the established session (step S402). ).

  The control unit 10 of the server apparatus 1 identifies the identification information of the client apparatus 2 that is a subscriber temporarily stored as being connected to itself, and the connection destination information (“connections” of each client apparatus 2 stored in the database 3. ]) Is collated (step S403). The process of step S403 is the same as the process of step S308 shown in the flowchart of FIG.

  As a result of the collation in step S403, the control unit 10 of the server apparatus 1 is connected to itself and is stored in the database 3 for the client apparatus 2 (each of which has a plurality of status information) whose status information is online. Based on the connection destination information, it is determined whether or not the connection destination is itself (step S404).

  The control unit 10 of the server device 1 is not itself (S404: NO), and the control unit 10 deletes the information of the client device 2 that is the target subscriber from the status information of the client device 2 connected to itself. (Step S405), the process at the time of starting is terminated, and the process proceeds to the process at the time of normal operation (see FIG. 4 or FIG. 20).

  When the control unit 10 of the server apparatus 1 determines that it is itself in step S404 (S404: YES), it is transmitted to the client apparatus 2 that is in communication connection by another server apparatus 1 via itself. Information (distribution destination information via broker) is extracted from the database 3 ("store_target_broker_user" table) (step S406). Further, the control unit 10 extracts a message stored in the database 3 (“store” and “store_target” table) for the client apparatus 2 that is a subscriber connected for communication (step S407). The control unit 10 transmits a publish message based on the information extracted in steps S406 and S407 to the client device 2 in the order of the stored times (step S408). After that, the control unit 10 receives the puback message from the destination client device 2 (step S409), and when receiving this, deletes the distribution destination information and the stored message (step S410). The start-up process is completed by sending the publish message. In addition, when information is not extracted by step S406 and S407, the process of step S408-S410 is not performed.

The process shown in the flowchart of FIG. 34 will be described for each cutting location.
(3.2.1) Between Publisher and Broker When the message between the publisher and the subscriber shown in the explanatory diagram of FIG. 23 is mediated by the two brokers, the server device 1 (broker that exists near the publisher) ( Explain the session between publisher and broker when b1) goes down. In this case, the client device 2 (p1), which is the publisher, can realize QoS = 1 by retransmitting the publish message with a new packet ID to the server device 1 (b1), which is the broker that is newly connected for communication. .

  The server device 1 (b1) serving as the broker receives a publish message from the client device 2 (p1) serving as the publisher, and before sending this message to the server device 1 (b2), the database 3 (“store_target_broker” table ) Is stored in the message. At this time, the server apparatus 1 (b1) stores the packet ID used when the publish message is received from the client apparatus 2 (p1) as an event log in the database 3, and the flowcharts of FIGS. The exchange may be continued after the restart according to the processing procedure shown. When the server device 1 (b1) goes down before receiving the puback message from all the other server devices 1 (b2), the server device 1 (b2) detects disconnection while it is down, and the database 3 ( The delivery destination information stored in the “store_target_broker” table) can be moved to the database 3 (“store_target_broker_user” table) as information indicating that the message is a message transmitted via itself (b1). At this time, the server device 1 (b1) transmits a puback message to the client device 2 (p1), which is the publisher, in response to the movement to the database 3. After the re-establishment, the server device 1 (b2) is directed to the client device 2 (s1) based on information indicating that the message is a message transmitted from itself (b2) stored in the database 3 (“store_target_broker_user” table). Execute publish message transmission.

(3.2.2) Between Brokers and Subscribers Next, a session between brokers and subscribers in a case where the server apparatus 1 (b2), which is a broker existing near the subscriber, goes down will be described. This corresponds to the session F shown in the explanatory diagram of FIG. FIG. 35 is a diagram showing processing when the server device 1 (b2) as the broker goes down. Specifically, an example is shown in which the server device 1 (b2) is down before sending a publish message to the client device 2 (s1) and receiving a puback message. In the example of FIG. 35, it is assumed that the puback message is transmitted to the server apparatus 1 (b1).

  In the example of FIG. 35, after the puback message is transmitted to the server device 1 (b1) which is the broker, the session is disconnected due to the down. The message stored in the database 3 and the transmission destination ("store" and "store_target_broker" before the server apparatus 1 (b1, activated with guarantee) transmits the publish message to the server apparatus 1 (b2) at the timing (20). "Table) information has been deleted. Messages and distribution stored in database 3 ("store" and "store_target" tables) before sending publish message at timing (30) when server device 1 (b2) is restarted with down guarantee Based on the destination information, the publish message is retransmitted to the client apparatus 2 (s1) (same as in FIG. 11). At this time, the packet ID is referred to from the information stored in the database 3 and transmitted. Information is deleted from the database 3 (“store” and “store_target” tables) by transmitting a puback message with the packet ID from the client device 2 (s1).

(3.2.3) Between Brokers and Brokers Next, a session between brokers in a case where the server apparatus 1 (b2), which is a broker existing near the subscriber, goes down will be described. FIG. 36 is a diagram showing processing when the server device 1 (b2) as the broker goes down. Specifically, when server device 1 (b2) goes down before and after receiving the publish message from broker server device 1 (b1) and before sending the publish message to client device 2 (s1). An example is shown.

  In the example of FIG. 36, the message stored in the database 3 and the transmission destination before the server apparatus 1 (b1, activated with guarantee) transmits the publish message to the server apparatus 1 (b2) at the timing (20). Information of ("store" and "store_target_broker" table) remains. When the server apparatus 1 (b1) detects that the session G is disconnected due to the server apparatus 1 (b2) being down (step S301 in FIG. 24), the client apparatus that has established a session with the server apparatus 1 (b2) The distribution destination information via the broker is stored (moved) in the database 3 (“store_target_broker_user” table) as a message that should have been transmitted to 2 (s1) (S305). Then, the server device 1 (b1) transmits a puback message to the client device 2 (p1), which is the publisher, by storing in the database 3 (S306).

  FIG. 37 is a diagram showing an example of processing performed after the server device 1 (b2) is started after the state shown in FIG. The server devices 1 (b1, b2) perform processing such as session establishment, synchronization processing, and collation with each other (S307 to S309 in FIG. 24, S401 to S403 in FIG. 34). The restarted server device 1 (b2) determines that the connection destination is the client device 2 (s1) (S404: YES). The server device 1 (b2) extracts a message (distribution destination information via the broker) that should have been transmitted to the client device 2 (s1) whose connection destination is itself from the database 3 (“store_target_broker_user” table) (S406). ), And transmits at timing (50) using the new packet ID (“0x133”) (S408). At this time, the server device 1 (b2) again stores the stored message and distribution destination information (user_id = s1, packet_id = 0x133, store_id = 789, already_sent = false, qos = 1) in the database 3 (“store” and “store_target” table). ) Is stored. Thereafter, the puback message is transmitted from the client apparatus 2 (s1) at the timing (60), and the server apparatus 1 (b2) receives this message (S409), so that the stored message and the delivery destination information are deleted. (S410).

  In this way, even when the server device 1 as the broker goes down as well as disconnecting the session, the message sent from the publisher with QoS = 1 specified can reach the subscriber with QoS = 1 (“At least Once”).

(4) QoS = 2, operation not guaranteed by broker down Next, publish message is sent from client device 2 as publisher specifying QoS = 2 on the assumption that message arrival is not guaranteed when the broker goes down The processing when this is done will be described. In the following description, the message arrival to the subscriber when the client device 2 that is the subscriber who designates the topic of the message has designated “2” as the QoS when the topic is designated will be described. Note that message transmission to subscribers of the same message who have specified “0” at the time of specifying a topic is completed by only transmitting the publish message once as described in (1). Description is omitted. In addition, transmission of a message to a subscriber who designates “1” when a topic is designated is performed based on the content obtained by replacing the order of the puback message described in (2) with a pubrec message. That is, in principle, control is performed such that the pubrec message is not returned to the transmission source until the puback message is received from all the other server apparatuses 1.

(4.1) During normal operation
When guaranteeing a message transmitted with QoS = 2, the server device 1 as a broker stores and uses packet ID correspondence information (pidmap). As shown in FIG. 1, in the communication system 100, a plurality of brokers (usually one or two) mediate message distribution. If the broker to which the client device 2 that is the publisher is connected is different from the broker to which the client device 2 that is the subscriber is connected, that is, if there are two or more brokers for sending and receiving messages, the message is It goes through a session between these brokers. As shown in FIG. 3, the server apparatus 1 conforms to the MQTT model, and exchanges messages using the packet ID as a key for each session. The server device 1 according to the present disclosure stores, as packet ID correspondence information (pidmap), a correspondence relationship between packet IDs used between different sessions for transmission of the same message regarding a session established by itself. By storing packet ID correspondence information from the normal time, as described later, even when the session is disconnected in the middle of message exchange or when the server is down, it is possible to return to the previous state. It becomes possible.

  FIG. 38 is an explanatory diagram of packet ID correspondence information in QoS = 2. In the explanatory diagram of FIG. 38, a connection configuration in the case where two brokers are interposed between the client device 2 that is a publisher and the client device 2 that is a subscriber whose designated topic is the topic of a message transmitted from the publisher. The example of the information memorize | stored in each server apparatus 1 is shown. In FIG. 38, the client device 2 (p1) is connected to the server device 1 (b1) as a publisher (session J), and the client device 2 (s2) is connected to the same server device 1 (b1) as a subscriber. (Session M). The client device 2 (s1) is communicatively connected to the server device 1 (b2) as a subscriber (session K). The server apparatuses 1 (b1, b2), which are two brokers, are also connected for communication (session L). In the example of FIG. 38, the message transmitted from the client device 2 (p1) reaches the client device 2 (s2) via the session J and the session M, and the client via the session J, the session L, and the session K. The device 2 (s1) is reached.

  Each of the server devices 1 stores three types of packet ID correspondence information in the temporary storage unit 13. First, the three types of packet ID correspondence information include the packet ID in the message from the client device 2 to the server device 1 that is the client device 2 ("u" in the meaning of reception from the user), and the client device 2 from the server device 1 that is itself. It includes the correspondence (pid_map_u2u) between the packet ID in the message to the apparatus 2 and “u” in the sense of transmission to the user. Second, the packet ID in the message from the client device 2 to the server device 1 that is itself (“u” in the sense of reception from the user), and the message from the server device 1 that is itself to the other server device 1 It includes the correspondence (pid_map_u2b) between the packet ID and ("b" in the sense of transmission to the broker). Third, the packet ID in the message from the other server device 1 to the server device 1 itself (“b” in the meaning of reception from the broker), and the message from the server device 1 to the client device 2 It includes the correspondence (pid_map_b2u) between the packet ID and ("u" in the sense of transmission to the user). Each packet ID correspondence information includes identification information of the sender of the message to itself ([source_user (broker) _id]), identification information of the receiver of the message from itself ([target_user (broker) _id]), and the transmission Packet ID from the sender ([source_pid], indicated by [s_pid] in the figure), packet ID for the receiver ([target_pid], indicated by [t_pid] in the figure), and logic indicating completion of message transmission Contains the value ([sent]).

  In the case of the connection configuration shown in FIG. 38, the server device 1 (b1) serving as the broker has the following two types of packet ID correspondence information for the publish message transmitted from the client device 2 (p1) serving as the publisher. Packet ID correspondence information is used. One is the packet ID correspondence for the correspondence between the packet ID of the message from the client device 2 (p1) and the packet ID of the message to the client device 2 (s2) that is a subscriber connected to the client device 2 (p1). Information (pid_map_u2u). One is a packet for correspondence between the packet ID of the message from the client device 2 (p1) and the packet ID of the message to the server device 1 (b2), which is another broker connected to itself. ID correspondence information (pid_map_u2b). In the example shown in FIG. 38, the server device 1 (b1) has a correspondence relationship between the packet ID from the client device 2 (p1) as a publisher and the packet ID of a message to the client device 2 (s2) as a subscriber. First packet ID correspondence information (pid_map_u2u) (source_user_id = p1, target_user_id = s2) is used. Similarly, the server device 1 (b1) has a correspondence between the packet ID from the client device 2 (p1) as a publisher and the packet ID of a message to the server device 1 (b2) as another broker. Second packet ID correspondence information (pid_map_u2b) (source_user_id = p1, target_broker_id = b2) is used.

  Similarly, in the connection configuration shown in FIG. 38, the server apparatus 1 (b2) has a packet ID of a message from the other server apparatus 1 (b1) and a client apparatus 2 (s1) that is a subscriber connected to itself. The packet ID correspondence information (pid_map_b2u) (source_broker_id = b1, target_user_id = s1) is used for the correspondence with the packet ID of the message.

  FIG. 39 is a flowchart illustrating an example of a message processing procedure using packet ID correspondence information. The processing procedure shown in the flowchart of FIG. 39 corresponds to the details of step S9 in the procedure shown in the flowchart of FIG.

  The control unit 10 of the server apparatus 1 determines whether or not a publish message has been received from one or a plurality of client apparatuses 2 that have established a communication connection as a publisher, or from another server apparatus 1 (step S501). If it is determined that the data has not been received (S501: YES), the control unit 10 returns the process to step S501.

  If the control unit 10 determines that it has been received (S501: YES), it specifies the packet ID of the received publish message (step S502). The control unit 10 extracts the topic of the received publish message (step S503), and determines whether another server device 1 is included in the transmission destination for the extracted topic (step S504).

  When it is determined in step S503 that the other server device 1 is not included (S504: NO), the control unit 10 specifies the extracted topic for the publish message received in step S501, and establishes communication connection to itself. It is determined whether or not a record having the client device 2 as a receiver as a receiver can be retrieved from the stored packet ID correspondence information (pid_map_u2u) (step S505). In step S505, the control unit 10 searches for a record using the sender ([source_user (broker) _id]), the receiver ([target_user (broker) _id]), and the packet ID ([source_pid]) specified in step S502. .

  If it is determined in step S505 that the search could not be performed (S505: NO), since it is a new message, the control unit 10 assigns a packet ID in the session with the recipient (step S506), and creates a record. Store (step S507). The control unit 10 transmits the publish message received in step S501 to the client device 2 that is a subscriber, using the packet ID numbered in step S506 (step S508).

  When it is determined that the search has been completed (S505: YES), the control unit 10 determines whether or not the message transmission completion in the record indicates completion (step S509). If it is determined that it has not been completed (S509: NO), the publish message is retransmitted (step S508). In step S508, if there is a packet ID for the receiver in the retrieved record, the packet ID is used for transmission. If there is no packet ID, the packet ID is numbered and transmitted here.

  When it is determined that the transmission is completed (S509: YES), the control unit 10 skips the transmission process and proceeds to the next step S510).

  In step S508, the control unit 10 sets the transmission destination as the database 3 when there is a client device 2 that has selected keep connection and the session is disconnected. When the transmission destination is the database 3, since the packet ID in step S505 cannot be numbered, the packet ID correspondence information may be stored without the packet ID (S507).

  Subsequently, the control unit 10 returns a pubrec message to the transmission source (publisher or other server apparatus 1) of the received publish message (step S510). The control unit 10 determines whether a pubrec message has been received from the recipient of the publish message (step S511). If it is determined that it has not been received (S511: NO), the control unit 10 returns the process to step S511 and waits until it is determined that it has been received. When it is determined that the packet is received (S511: YES), the control unit 10 uses the packet ID correspondence information record as the sender of the pubrec message, the recipient identification information ([target_user (broker) _id]), and the pubrec message packet. The search is performed using the ID ([target_pid]), and the retrieved record is updated on the assumption that the message has been transmitted (step S512).

  Next, the control unit 10 determines whether or not the pubrel message has been received from the sender of the publish message (step S513). If it is determined that it has not been received (S513: NO), the control unit 10 returns the process to step S513 and waits until it is determined that it has been received. When it is determined that the packet is received (S513: YES), the control unit 10 records the packet ID correspondence information in the sender identification information ([source_user (broker) _id]) of the sender pubrel message and the packet of the pubrel message. Search by ID ([source_pid]), delete the searched record (step S514), and terminate the distribution process of one publish message.

  When it is determined in step S504 that the other server device 1 is included (S504: YES), the control unit 10 is directed to the other server device 1 in the same manner as the processing described in steps S505 to S509 described above. Processes S515 to S519 are performed on the stored packet ID correspondence information (pid_map_u2b). In step S518, when the control unit 10 transmits to the client device 2 that is a subscriber that is in communication connection with the specified topic in addition to the other server device 1, it is similarly published. A message is transmitted (S518).

  When another server device is included in the transmission destination, the control unit 10 determines whether or not the pubrec message has been received until the pubrec message is received from all the other server devices 1 after step S518 (step S520). When it is determined that the data has not been received (S520: NO), the control unit 10 returns the process to step S520 and does not proceed to the next step S521. When it is determined that the packet is received (S520: YES), the control unit 10 uses the packet ID correspondence information record as the sender of the pubrec message, the identification information of the receiver ([target_user (broker) _id]), and the packet of the pubrec message. The search is performed using the ID ([target_pid]), and the retrieved record is updated assuming that the message has been transmitted (step S521). Then, it is determined whether or not the pubrec message has been received from all the other server devices 1 (step S522). If it is determined that the message has not been received from all (S522: NO), the control unit 10 returns the process to step S520 and does not perform the process of the next step S523 until another pubrec message is received. If it is determined in step S522 that the pubrec message has been received from all the other server devices 1 (S522: YES), the control unit 10 has received the pubrec message from the client device 2 that is communicatively connected to itself. In this case, the process proceeds to step S523, and the pubrec message from the client apparatus 2 is individually processed.

  When it is determined in step S522 that the pubrec message has been received from all the other server devices 1 (S522: YES), the control unit 10 pubrecs to the transmission source (publisher or other server device 1) of the received publish message. A message is returned (step S523). Subsequently, the control unit 10 determines whether or not the pubrel message has been received from the sender of the publish message (step S524). If it is determined that it has not been received (S524: NO), the control unit 10 returns the process to step S524, and waits until it is determined that it has been received. If it is determined that it has been received (S524: YES), the control unit 10 records the packet ID correspondence information in the sender's pubrel message sender identification information ([source_user (broker) _id]) and the pubrel message packet. The search is performed using the ID ([source_pid]), the searched record is deleted (step S525), and the distribution process for one publish message is terminated.

  The processing procedure shown in the flowchart of FIG. 39 will be specifically described with reference to FIGS. 40 to 42 are diagrams showing examples of contents of the packet ID correspondence information. First, in FIG. 40, after the client device 2 (p1) as a publisher transmits a publish message, the client device 2 (s1) as a subscriber passes through the server devices 1 (b1, b2) as two brokers. Indicates packet ID correspondence information (“pidmap”) up to the time when a publish message is transmitted. As shown in FIG. 40, when the server apparatus 1 (b1) receives a publish message at timing (10) from the client apparatus 2 (p1) which is the publisher (S501: YES), a session with the client apparatus 2 (s2) is performed. Then, the packet ID “0x126” is numbered (S516). The server apparatus 1 (b1) associates the packet ID correspondence information (pid_map_u2u) with the packet ID “0x112” from the sender of the identification information “p1” and the packet ID “0x126” to the receiver of the identification information “s2”. (Source_user_id = p1, target_user_id = s2, s_pid = 0x112, t_pid = 0x126, sent = false) are created and stored (S517). The control unit 10 transmits a publish message to the recipient of the identification information “s2” at the timing (20) using the numbered packet ID “0x126” (S518). Since the pubrec message is transmitted from the recipient of the identification information “s2” at the timing of (30), the server apparatus 1 (b1) receives this (S520), and the transmission complete logical value (initial value of sent) ("False") is updated with "true" (S522).

  The server apparatus 1 (b1) assigns a packet ID “0x125” in a session with the server apparatus 1 (b2) to transmit a publish message to the other server apparatus 1 (b2) (S516 and S506). The server apparatus 1 (b1) associates the packet ID correspondence information (pid_map_u2b) with the packet ID “0x112” from the sender of the identification information “p1” and the packet ID “0x125” to the receiver of the identification information “b2”. (Source_user_id = p1, target_broker_id = b2, s_pid = 0x112, t_pid = 0x125, sent = false) are stored (S517). The control unit 10 transmits a publish message to the server apparatus 1 (b2) at the timing (20) using the numbered packet ID “0x125” (S518). At the timing shown in FIG. 40, since the pubrec message from the recipient of the identification information “b2” has not been received, the transmission completion logical value (sent) in the corresponding record remains the initial value “false”.

  In the example shown in FIG. 40, when the publish message is transmitted to the client apparatus 2 (s1), which is also a subscriber, in the server apparatus 1 (b2), the packet ID “0x134” is numbered (S506). The control unit 10 sets the correspondence between the packet ID “0x125” from the sender of the identification information “b1” and the packet ID “0x134” to the receiver of the identification information “s1” in the packet ID correspondence information (pid_map_b2u). A record shown (source_broker_id = b1, target_user_id = s1, x_pid = 0x125, t_pid = 0x134, sent = false) is created and stored (S507). The control unit 10 of the server apparatus 1 (b2) transmits a publish message to the client apparatus 2 (s1) at the timing (30) using the numbered packet ID “Z” (S508).

  FIG. 41 shows packet ID correspondence information (“pidmap”) up to the point (timing (40)) when the pubrec message is transmitted from the server apparatus 1 (b2) after FIG. In FIG. 41, when the server apparatus 1 (b2) transmits a publish message to the client apparatus 2 (s1) at the timing (30), the server apparatus 1 (b2) transmits a pubrec message to the server apparatus 1 (b1) in order (S510). ). As a result, the server apparatus 1 (b1) receives the pubrec message from the server apparatus 1 (b2), which is the recipient, for the publish message transmitted by itself (S520), and therefore the corresponding packet ID correspondence information (pid_map_u2b) The logical value (sent) of the record transmission completion is updated to “true” (S521). The server device 1 (b1) receives the pubrec message from all the other server devices 1 (S522: YES), and thereafter transmits the pubrec message to the client device 2 (p1) that is the publisher.

  In the example of FIG. 41, since the server apparatus 1 (b2) also receives the pubrec message from the client apparatus 2 (s1) as the receiver, the logical value of the transmission completion of the record of the corresponding packet ID correspondence information (pid_map_b2u) (Sent) is updated to “true” (S512).

  FIG. 42 shows the packet ID correspondence information (“pidmap”) after the publish message distribution process from the client device 2 (p1), which is the publisher, is completed. Since the server apparatus 1 (b1) determines that the pubrec message has been received from all the other server apparatuses 1 based on the pubrec message received at the timing (40) (S522: YES), the publisher at the timing (50). The pubrec message is transmitted to the client apparatus 2 (p1) that is (S523).

  The client device 2 (p1) that is the publisher receives the pubrec message from the server device 1 (b1) that is the receiver for the packet ID “0x112”, and therefore transmits the pubrel message. Since the server apparatus 1 (b1) has received the pubrel message (S524: YES), the server apparatus 1 (b1) searches the packet ID correspondence information with the identification information “p1” of the sender and the packet ID “0x112” of the pubrel message, and “pid_map_u2u” and Both the two records that match in “pid_map_u2b” are deleted (S525), and the distribution process is terminated.

  When the server apparatus 1 (b1) receives the pubrec message for the message of the packet ID “0x125” having the server apparatus 1 (b2) as the receiver by the operation of the network controller, the server apparatus 1 (b1) transmits the pubrel message. As a result, the server apparatus 1 (b2) also receives the pubrel message (S513: YES), and searches for the packet ID correspondence information using the sender identification information “b1” and the packet ID “0x125” of the pubrel message, and “pid_map_b2u ”Are deleted (S514), and the distribution process is terminated.

  As shown in the above-described processing, the order of processing in each server device 1 is maintained even when QoS = 2 is adjusted, as in the case of QoS = 1. In addition, packet ID correspondence information Each is memorized. When QoS = 2, the publish message is retransmitted using the same packet ID at the time of reconnection because the session is disconnected, but each server device 1 uses the same packet ID from the same sender. The publish message is not retransmitted if a pubrec message is received from the recipient. As a result, even when the message from the publisher to the subscriber crosses different sessions, the arrival of the message can be guaranteed with QoS = 2.

(4.2) When a disconnection occurs On the premise that no guarantee is made if the broker goes down, between the client device 2 that is the publisher and the server device 1, between the two server devices 1, and between the server device 1 and the client that is the subscriber A case where the session with the device 2 is disconnected in the middle of message exchange will be described. In the following description, an example in which any one or a plurality of sessions J to M in the configuration illustrated in FIG. 38 is disconnected will be described.

(4.2.1) Between Publisher and Broker Consider a case in which a session between a publisher and a broker is disconnected with respect to transmission of data from the publisher client device 2 to a subscriber arbitrated with QoS = 2. In this case, after the publish message is transmitted from the client device 2 (p1) which is the publisher shown in FIG. 40, before the pubrec message is transmitted from the server device 1 (b1), the client device 2 (p1) In this case, the session J between the server apparatuses 1 (b1) is disconnected.

  In this case, the client device 2 (p1), which is the publisher, temporarily stores the publish message in the transmission buffer until a pubrec message for the transmitted publish message is returned (FIG. 3). When the session J is established again, the client apparatus 2 (p1) transmits the publish message temporarily stored in the transmission buffer to the connection destination server apparatus 1 (b1) using the same packet ID again in the session J. To do. When the message arrival guarantee to the subscriber is arbitrated to QoS = 2, the publish message originating from the same publish message after the second time is received and processed repeatedly by the client device 2 as the subscriber. Must be avoided.

  Even in the case where the session J is disconnected in the state of FIG. 40 by the processing of the server device 1 in the present embodiment, first, the message arrival of (s1) to the client device 2 as the subscriber is “Exactly once” (exactly 1 (QoS = 2). The server apparatus 1 (b1) sends the publish message received from the client apparatus 2 (p1), which is the publisher before being disconnected, to the other server apparatus 1 (b2) to which the client apparatus 2 (s1) is connected. When the transmission of the publish message is completed, a packet ID correspondence information record (pid_map_u2b) is temporarily stored. Therefore, when the retransmitted publish message is received from the publisher, the server device 1 (b1) includes a record including the same packet ID from the same sender and the other server device 1 (b2) as the receiver. Searchable (source_user_id = p1, source_pid = 0x112, target_broker_id = b2).

  When the record can be retrieved, before the pubrec message is transmitted from the destination server apparatus 1 (b2) to the server apparatus 1 (b1), that is, to the client apparatus 2 (s1) connected to the destination. If it is before transmission of the publish message, the logical value (sent) of transmission completion in the retrieved record is “false”. In this case, the server apparatus 1 (b1) retransmits the publish message using the packet ID (target_pid = 0x125) to the recipient (target_broker_id = b2) included in the retrieved record. When the server apparatus 1 (b2) that has received the retransmission of the publish message from the server apparatus 1 (b1) has not received the pubrec message from the client apparatus 2 (s1) that is connected for communication, the publish message is similarly set. And resend. According to the MQTT model in session K, the client apparatus 2 (s1) discards the retransmitted publish message without receiving it until it receives the pubrel message. There is no.

  If the server apparatus 1 (b2) has already transmitted a publish message based on the message transmitted from the publisher before the session J is disconnected to the client apparatus 2 (s1) connected for communication, the server apparatus 1 transmits the pubrec message. Returning to (b1) or trying to return. The server apparatus 1 (b1) will soon receive this pubrec message, and the logical value (sent) of transmission completion in the retrieved record is updated to “true”. When the logical value (sent) of transmission completion of the retrieved record is “true” when the publish message is retransmitted from the publisher, the server device 1 (b1) publishes to the server device 1 (b2). Do not resend the message. As described above, when the publish message based on the publish message transmitted from the publisher before the session J is disconnected has been transmitted to the client apparatus 2 (s1), the server apparatus 1 (b2) is also based on the same publish message. The publish message is not resent. No duplicate messages arrive at the client device 2 (s1).

  When the logical value (sent) of transmission completion of the retrieved record is “false” when the publish message is retransmitted from the publisher, the server device 1 (b1) publishes toward the server device 1 (b2). Although the message is resent, the server apparatus 1 (b2) has already received and processed the publish message with the same packet ID. Therefore, the resent publish message is discarded by the arrival guarantee for each session based on the MQTT model. The No duplicate messages arrive at the client device 2 (s1).

  The server apparatus 1 (b1) is connected to another server apparatus 1 (to which the client apparatus 2 having the identification information “s1” is communicatively connected to the publish message received from the client apparatus 2 (p1) which is the publisher before being disconnected. When sending a publish message to b2), if the session L with the other server apparatus 1 (b2) is disconnected, the message and its delivery destination are stored in the database 3 ("store" and "store_target_broker" tables). Is stored as described later. At this time, the server apparatus 1 (b1) sets the identification information “b2” of the other server apparatus 1 that should have been the recipient and the packet ID to the receiver as “NULL”, and the logical value of the transmission completion A record of packet ID correspondence information (pid_map_u2b) with “true” is created and stored. In this case, the other server device 1 (b2) can recognize that the message addressed to itself stored in the database 3 (“store” and “store_target_broker” table) is stored, and the reception process is performed. It should be. Even if the message is retransmitted from the publisher after the session J is disconnected, a record including the same packet ID from the same sender and having the other server device 1 (b2) as the receiver can be searched. Moreover, since the transmission completion is “true”, it is avoided that retransmission is performed even if the session L is reconnected. This prevents duplicate messages from reaching.

  When the session J is disconnected in the state of FIG. 40, the message arrival to the client device 2 (s2), which is a subscriber directly connected to the server device 1 (b1), is also “Exactly once” (QoS = 2).

  If the server apparatus 1 (b1) has completed transmission of the publish message to the client apparatus 2 (s2) for the publish message received from the client apparatus 2 (p1) that is the publisher before being disconnected, the packet ID Corresponding information record (pid_map_u2u) is temporarily stored. Therefore, when the retransmitted publish message is received from the publisher, the server apparatus 1 (b1) can search for a record including the same packet ID from the same sender and having the client apparatus 2 (s2) as the receiver. (Source_user_id = p1, source_pid = 0x112, target_user_id = s2).

  If the record can be retrieved, before the pubrec message is transmitted from the destination client device 2 (s2) to the server device 1 (b1), the logical value (sent) of the transmission completion in the retrieved record is "False". In this case, the server apparatus 1 (b1) retransmits the publish message using the packet ID (target_pid = 0x126) for the recipient included in the retrieved record. Since the client apparatus 2 (s2) that has received the retransmission of the publish message from the server apparatus 1 (b1) receives the retransmitted publish message and discards it without receiving it until the pubrel message is received. Duplicate reception processing is not performed.

  If the record can be retrieved and the pubrec message is transmitted from the destination client device 2 (s2) to the server device 1 (b1), the transmission completion logical value (sent) in the retrieved record is “true” Is. The server apparatus 1 (b1) does not retransmit the publish message based on the retransmitted publish message. No duplicate messages arrive at the client device 2 (s2).

  When the server apparatus 1 (b1) transmits a publish message to the client apparatus 2 (s2) for the publish message received from the client apparatus 2 (p1) that is the publisher before being disconnected, the client apparatus 2 A case where the session M with (s2) is disconnected can be considered. Since this case is a disconnection between broker and subscriber, it will be described later.

  When the disconnection timing is other than the state shown in FIG. 40, the server apparatus 1 (b1) performs processing based on the presence or absence of a message remaining in the transmission buffer of the network controller in the MQTT model in each session (FIG. 15 to FIG. 17), the interrupted exchange is resumed and the message exchange is completed. As shown in FIGS. 41 and 42, after the pubrec message reaches the publisher, the exchange of the pubrel message and the pubcomp message in each session is executed.

  In this way, not only QoS = 2 for each session but also message arrival guarantees across session J, session L and session K, and session J and session M are achieved with QoS = 2 even when session J is disconnected. can do.

(4.2.2) Between Broker and Subscriber In the state shown in FIG. 40, there is a session K established between the client device 2 (s1) as a subscriber and the server device 1 (b2) as a broker. The arrival guarantee of QoS = 2 when disconnected is described. FIG. 43 is a flowchart illustrating an example of a processing procedure when detecting disconnection of a session with a subscriber in the server apparatus 1 (b2).

  When the control unit 10 of the server apparatus 1 (b2) detects disconnection with the client apparatus 2 that is a subscriber connected to itself (step S601), the MQTT halfway message information processing illustrated in the flowchart of FIG. 15A is performed. According to the procedure, it is determined whether or not the publish message for the client apparatus 2 to which the disconnected session is connected remains in the transmission buffer (step S602). If it is determined that it remains (S602: YES), the control unit 10 uses the publish message as halfway message information (packet image and identification information of the destination client device 2) in the database 3 ("keep_mqtt" table). (Step S603). The publish message remaining in the send buffer is deleted.

  The control unit 10 stores in the database 3 a record in which the client device 2 to which the disconnected session is connected is stored in the database 3 among the temporarily stored packet ID correspondence information (pid_map_b2u or pid_map_u2u). Are stored in association with each other (step S604). The control unit 10 deletes the stored record from the temporary storage (step S605).

  The control unit 10 determines whether or not the client device 2 that is the connection destination of the disconnected session has transmitted a communication connection request to itself again (step S606). When it is determined that it has been transmitted (S606: YES), the control unit 10 executes the processing procedure (S1-S3: NO, S16) shown in the flowchart of FIG. The control unit 10 refers to a record of packet ID correspondence information stored in itself and having the connection destination client device 2 as a receiver from the database 3 (pid_map_b2u) (step S607). The control unit 10 returns the read record (pid_map_b2u or pid_map_u2u) to the temporary storage by the temporary storage unit 13 as part of the restoration of the state information in step S16 (step S608).

  Subsequently, the control unit 10 determines whether or not the transmission of the publish message to the connection destination client device 2 is completed according to the processing procedure shown in the flowchart of FIG. 15B (step S609). If it is determined that the transmission has not been completed (S609: NO), the control unit 10 sends message information (intermediate message information (“keep_mqtt”) that should have been transmitted from the database 3 to the client device 2 to be connected. Table)) is read from the database 3 (step S610). The control unit 10 transmits a publish message with a packet image including the read packet ID as it is (step S611). Then, the control unit 10 refers to the packet ID correspondence information, transmits a pubrec message corresponding to the retransmitted publish message to the server device 1 (b1) on the publisher side (step S612), and ends the process at the time of detecting disconnection. Continue to exchange messages based on the MQTT model. The process of step S18 shown in the flowchart of FIG. 4 ends, and the server apparatus 1 (b2) continues the distribution process (S9).

  If it is determined in step S609 that the transmission has been completed (SS609: YES), the control unit 10 ends the process at the time of detecting the disconnection as it is. If it is determined in step S606 that no transmission has been made (S606: NO), the control unit 10 ends the process at the time of detection of disconnection. In this case, the control unit 10 advances the process to S9 in the flowchart of FIG. 4 and continues the distribution process. If it is determined in step S606 that the data is not transmitted, the connection information (“connections”) of each client device 2 stored in the database 3 may be checked to determine that it is not itself.

  On the other hand, processing in the server apparatus 1 to which the disconnected client apparatus 2 (s1) newly requested communication connection will be described. The new connection destination server apparatus 1 executes the processing procedure shown in the flowchart of FIG. 4 in response to a new communication connection request. In this case, since the session information is stored in the database 3 (“keep_sub” table), the connection destination server apparatus 1 restores the state information in step S16.

  The server device 1 retrieves the packet ID correspondence information (pid_map_b2u) related to transmission from the database 3 to the connection destination client device 2 (s1), and when retrieved, retrieves it and restores it as part of the state information (S16). The server device 1 which is a new connection destination searches the stored message and the delivery destination information or midway message information (the “store” and “store_target_broker_user” table or “keep_mqtt” table) in the database 3 according to the processing procedure of FIG. If it is determined that there is a message (S106: YES), the message is read and transmitted to the client device 2 (S107). The control unit 10 deletes the transmitted message from the database 3 (S108). The control unit 10 transmits a pubrec message from the packet ID correspondence information to the transmission source of the publish message (other server device 1 or publisher), and completes the exchange of the pubrel message and the pubcomp message. Thereby, the distribution from the database 3 (S18) is terminated.

  The processing procedure shown in the flowchart of FIG. 43 will be specifically described. The session K in FIG. 40 may be disconnected before the server apparatus 1 (b2) transmits a publish message to the client apparatus 2 (s1) at the timing (30). In this case, the message distributed while being disconnected by the keep connection process (FIGS. 9, 10 to 14) is stored as a stored message and distribution destination information (“store” and “store_target” tables). (When the client apparatus 2 (s2) is kept connected). After reconnection, the data is distributed from the database 3 by processing of the server device 1 (b2) or a new server device 1 (when the client device 2 (s1) is kept connected). Since the server apparatus 1 after the reconnection can restore the packet ID correspondence information for the disconnected client apparatus 2, it is determined whether the client apparatus 2 has already received the publish message (the pubrec message is transmitted). And QoS = 2 can be achieved without sending duplicate messages.

  There may be a case where the session K is disconnected before the pubrec message is received after the server device 1 (b2) transmits the publish message to the client device 2 (s1) at the timing (30). In this case, the server device 1 (b2) or the new server device 1 after the reconnection interrupts the processing by referring to the midway message information ("keep_mqtt" table) in the database 3 (FIGS. 15 to 19). Exchange is resumed and message exchange is completed.

  Further, in the example shown in FIG. 40, when the server apparatus 1 (b1) transmits a publish message to the client apparatus 2 (s2) for the publish message received from the client apparatus 2 (p1) as the publisher, The case where the session M with the client apparatus 2 is disconnected is also a disconnection between broker and subscriber. In the case where the session M is disconnected, the message to be received by the client device 2 (s2) during the disconnection is stored in the database 3 (“store” and “store_target” tables) together with the distribution destination information with the identification information “s2”. (When the client apparatus 2 (s2) is kept connected). At this time, the server apparatus 1 (b1) sets the identification information “s2” of the client apparatus 2 that should have been the receiver as the transmission destination, the packet ID to the receiver as “NULL”, and sets the logical value of transmission completion. A record of packet ID correspondence information (pid_map_u2u) to be “true” is created and stored.

  In this case, when the session M is reconnected, the client from the database 3 (“store” and “store_target” table) based on the stored message and the delivery destination information stored by the keep connection process (FIG. 4). Distribution processing to the device 2 (s2) is performed. The server device 1 (b1) that is the reconnection destination can restore the packet ID correspondence information. Even if the message is retransmitted from the publisher after session J is disconnected, a record with the same sender, the same packet ID, and the client device 2 (s2) as a receiver can be searched. Since the transmission completion is “true”, even if the session M is reconnected, no retransmission is performed. In this way, duplicate arrival of messages is avoided.

  In this case, even when the client apparatus 2 (s2) is connected to another server apparatus 1 by communication, it is distributed from the database 3 ("store" and "store_target" tables). Also in this case, the packet ID correspondence information (pid_map_u2u) restored by another server device 1 recognizes that transmission has already been performed, and avoids duplicate transmission.

(4.2.3) Broker-Broker A description will be given of arrival guarantee when a session established between two brokers mediating a message from a publisher to a subscriber is disconnected. As described above, the keep connection is selected for the session between brokers. Regarding disconnection of a session between brokers (disconnection of session L in FIG. 40), storage of a save message for a keep connection (“store”) and other disconnected server devices described in (2.2.3) Processing is performed using the storage of distribution destination information (“store_target_broker_user” table) via the broker indicating that the message is transmitted via 1 together with the packet ID correspondence information.

  In the case of QoS = 2, the processing by the server device 1 when the session between brokers is disconnected is basically the same as the processing procedure shown in the flowchart of FIG. 24 for QoS = 1. However, when QoS = 2, the pubrec message is sent instead of the puback message transmitted in step S306, and the trigger of step S315 for deleting the stored message in step S316 is receiving the pubcomp message instead of the puback message. In step S305, “the message that should have been originally transmitted to the client device 2 that has established a session with the other server device 1” and its distribution destination information (“store” and “store_target_broker_user”) are stored. Information on whether or not transmission is completed (whether or not a pubrec message is received at that time) is stored in the table.

  A process when the broker is disconnected will be described with a specific example. A process when a session between brokers is disconnected will be described with a specific example. 44 to 46 are explanatory diagrams illustrating an example of processing when a session between brokers is disconnected. The connection configuration of the device shown in the example of FIG. 44 is the same as the example shown in FIG. 38 except that the client device 2 (s2) is omitted.

  FIG. 44 shows an example of contents of information stored in the temporary storage unit 13 and the database 3 of the server device 1 when the session between the server devices 1 (b1, b2) serving as brokers is disconnected. The example shown in FIG. 44 is the same as the processing described with reference to FIG. 25 in the case of QoS = 1 until disconnection is detected. 44 is different in that each server device 1 stores packet ID correspondence information.

  FIG. 45 shows the processing after the session L between brokers is re-established from the state shown in FIG. 44, and the session between the server device 1 (b2) and the client device 2 (s1) as a subscriber. The process when K is maintained is shown. As described with reference to FIG. 44, the stored message and the delivery destination information via the broker are stored in the database 3 (“store” and “store_target_broker_user” table). Thereby, in the case of QoS = 1, when the session L between the brokers is disconnected, it is unknown whether a message is transmitted from the server device 1 (b2) to the client device 2 (s1). A message was transmitted from the device 1 (b2) just in case, and it was possible to reliably transmit the message. In the case of QoS = 2, it is possible to perform one transmission (Excactry once) by combining these information and the packet ID correspondence information.

  Specifically, in the case of QoS = 2, first, when the session K is maintained as shown in FIG. 45, the packet ID is taken from the server apparatus 1 (b2) to the client apparatus 2 (s1) as the subscriber. Since the packet ID correspondence information (pid_map_b2u) is stored, the publish message from the publisher should have arrived at the client device 2 (s1) as it is (sent = true). Even if the session K is disconnected, the publish message to be transmitted is controlled by the server device 1 (b2), which is the broker, based on the keep connection and the midway message information (keep_mqtt). Should be delivered to 2 (s1). Accordingly, in order to transmit once with QoS = 2, when the corresponding packet ID correspondence information is stored, transmission from the stored message and the delivery destination information via the broker should be avoided. Therefore, the server device 1 (b2) receives a message transmitted from the database 3 (“store” and “store_target_broker_user” table) to the client device 2 (s1) with the packet ID “0x125” addressed to itself (b2). When it is recognized that there is, processing is performed so as not to transmit from here. Specifically, the server device 1 (b2) has a packet ID correspondence information record with the packet ID “0x125” of the message from the server device 1 (b1) addressed to itself and the identification information “s1” as the receiver. To check. When the session L between brokers is disconnected, the exchange on MQTT is not resumed after re-establishment, and no pubrel message is received, so the corresponding packet ID correspondence information record should remain without being deleted. is there. Therefore, the server device 1 (b2) uses the packet ID correspondence information (pid_map_b2u) indicating the correspondence between the packet ID of the message received from the server device 1 (b1) and the packet ID used when transmitting the message to the subscriber. The records corresponding to the distribution destination information via the broker (source_broker_id == broker_id (b1), target_user_id = user_id (s1), source_pid == broker_pid (0x125)) can be extracted by searching. In this case, the server device 1 (b2) does not perform transmission from the delivery destination information (“store_target_broker_user”) stored in the database 3 via the broker. In the case of QoS = 1, if the message is stored in the database 3, it was retransmitted, but in the case of QoS = 2, it should have already been transmitted as described above. Thus, duplication of publish messages based on the same message can be avoided. The server device 1 (b2) deletes the packet ID correspondence information (pid_map_b2u) corresponding to the distribution destination information via the broker remaining because the pubrel message cannot be received together with the distribution destination information. If the record corresponding to the delivery destination information via the broker cannot be extracted by search, the server apparatus 1 (b2) performs transmission from the delivery destination information via the broker. In this case, the pubrec message from the destination client apparatus 2 When the pubcomp message is received, the delivery destination information (“store_target_broker_user”) is deleted.

  FIG. 46 shows processing after the session L between brokers is reestablished from the state shown in FIG. In FIG. 46, the client device 2 (s1), which is a subscriber, disconnected the session with the server device 1 (b1) and connected to the server device 1 (b1) while the brokers were disconnected. An example of the case is shown.

  In the case shown in FIG. 46, the server apparatus 1 executes a specific process. FIG. 47 is a flowchart illustrating an example of message transmission processing after re-establishing a session between brokers with QoS = 2. The processing in FIG. 47 is performed only when a determination process is added between step S309 and step S310 in the processing procedure shown in the flowchart of FIG. 24 and YES is determined in the determination process. The determination process is whether or not the client apparatus 2 which is a subscriber connected to the broker of the other party of the disconnected session has disconnected the communication connection with the other broker.

  The control unit of the server apparatus 1 refers to the distribution destination information via the broker stored in the database 3 (“store” and “store_target_broker_user” table) (step S801). The distribution destination information via the broker is information stored in the server device 1 (the server device 1 (b1) in FIG. 40) which is the broker (sender) on the publisher side. The control unit 10 is information indicating whether or not transmission in the distribution destination information via the broker has been completed (whether a pubrec message has been received from another server device 1 or [already_sent]), and information regarding whether or not retransmission has been performed. Reference is made to (if the packet ID at the time of retransmission is not NULL) (step S802). The control unit 10 determines whether or not the packet has been retransmitted (whether or not the packet ID at the time of retransmission is NULL) (step S803). If it is determined that the packet has been retransmitted (S803: YES), the transmission is completed. Whether or not the process is completed is determined by referring to the logical value of whether or not the process is performed (step S804). If it is determined that the transmission has been completed (S804: YES), the control unit 10 transmits a pubrel message using the packet ID at the time of retransmission in the distribution destination information (step S805), and is based on the subsequent MQTT model. Continue message processing and end processing.

  When it is determined in step S804 that the transmission is incomplete (S804: NO), the control unit 10 retransmits the publish message using the packet ID at the time of retransmission in the distribution destination information (step S806), and the subsequent MQTT. Continue message processing based on the model and end processing.

  If it is determined in step S803 that it has not been retransmitted (S803: NO), the control unit 10 sends the distribution destination information referred to in step S801, the sender ([source_user (broker) _id]), and the receiver ([[ It is determined whether or not a record of packet ID correspondence information having the same target_user (broker) _id]) can be extracted from the database 3 by searching (step S807).

  If it is determined in step S807 that the information cannot be extracted by the search (S807: NO), processing according to the presence / absence of the packet ID correspondence information stored in the read delivery destination information (when there is no information) It is determined whether or not the information indicating whether or not execution is also possible (step S808).

  When it is determined that it is impossible (S808: NO), the control unit 10 ends the process as it is. If it is determined that it is possible (S808: YES), in this case, transmission of the pubrec message from the subscriber-side broker to the publisher-side broker is incomplete (the publish message may not be transmitted). . The control unit 10 assigns a new packet ID (step S809), transmits a publish message to the server device 1 using the assigned packet ID (step S810), and ends the process.

  If it is determined in step S807 that it can be extracted by the search (S807: YES), since the packet ID correspondence information exists as described in FIG. 45, it is distributed to the subscriber by the control of another broker. Therefore, the processing is left to the server device 1. Therefore, the control part 10 complete | finishes a process as it is.

  This will be specifically described with reference to FIG. On the server device 1 (b1) side, regarding the message between brokers, it is determined that the push message remains in the processing procedure shown in the flowchart of FIG. This is because the pubrec message for the publish message at the timing (20) has not been received. However, in this case, it is unclear whether or not the message transmission to the subscriber based on the remaining publish message is performed via the reestablished server device 1 (b2). Since the server apparatus 1 (b2) is disconnected from the client apparatus 2 (s1), the server apparatus 1 (b1) executes the process of FIG. 47 for messages between brokers. In the example of FIG. 46, since packet ID correspondence information is stored (S807), nothing is transmitted and the process ends.

  In the example shown in FIG. 46, in the server apparatus 1 (b1), when the client apparatus 2 (s1) requests the server apparatus 1 (b1) to establish a session and accepts this, the connection destination information in the database 3 is identified with the identification information “ Rewrite as “b1”. Thereafter, synchronization processing is executed, and connection information is shared between the server apparatuses 1 (b1 and b2). The server apparatus 1 (b1) has the identification information “s1” of the client apparatus 2 storing the state information and the identification information “connections” of each client apparatus 2 stored in the database 3. s1 ”(S309 in FIG. 24), and it is determined that the connection destination information itself is the connection destination (S310: YES). Then, the server device 1 (b1) establishes itself as a sender in the packet ID correspondence information stored (moved) in the database 3 by the server device 1 (b2) in the processing of steps S311 to S313 as described later. The client apparatus 2 (s1) that has received the request is searched for a record, and when the record is searched, the logical value ([sent]) of transmission completion stored in the record is referred to. If the logical value is transmission complete, the pubrel message is transmitted using the packet ID ([target_pid]) for the recipient of the record. If the transmission is not complete, the publish message may be retransmitted using the packet ID. it can.

  In the example shown in FIG. 46, on the server device 1 (b2) side, when a session with the server device 1 (b1) is re-established (FIG. 24, S307), synchronization processing is performed (S308). The server device 1 (b2) collates the identification information “s1” in the connection destination information (“connections”) of each client device 2 stored in the database 3 with the status information (S309), and if it is not the connection destination itself Judgment is made (S310: NO). The server apparatus 1 (b2) deletes the status information about the client apparatus 2 (s1) (S311). Then, the server device 1 (b2) stores (moves) the packet ID correspondence information (pid_map_b2u in the drawing) in the database 3 in relation to the client device 2 (s1) according to the procedure shown in the flowchart of FIG. S604). Thereafter, since it is determined that the communication connection has not been made again (S606: NO), subsequent processing for the client device 2 (s1) is left to the server device 1 (b1) side.

  As described above, even when the session between brokers is disconnected during the exchange of the message for guaranteeing the arrival in the MQTT model, the client guarantees the arrival of the message with QoS = 2 specified by the client device 2 as the publisher. QoS = 2 can be set not only in the session from the apparatus 2 to the broker but also in the path to the client apparatus 2 as a subscriber.

(5) QoS = 2, Broker Down Guarantee On the premise that message arrival is guaranteed even if the broker is down, QoS is “2” in all sessions that are routes, as in (4). Describes reaching a subscriber of a publish message with a specified. In the following description, similarly to (4), the description is omitted when the client apparatus 2 as a subscriber specifies a QoS other than “2” for the topic of the message.

  FIG. 48 is a diagram showing processing when guaranteeing broker down with QoS = 2. The configuration of the apparatus shown in FIG. 48 is the same as the example shown in FIG. 38 for explaining the case where broker down is not guaranteed. As is clear when FIG. 48 is compared with FIG. 38, the difference is the storage destination of the packet ID correspondence information. When guaranteeing further broker down with QoS = 2, in addition to storing the database 3 (store, store_target) in keep connection, each server device 1 does not temporarily store the packet ID correspondence information in the temporary storage unit 13, Is stored in the database 3 in association with each other, and it is possible to recover temporary storage between sessions having different packet IDs after recovery.

(5.1) During normal operation When the message is guaranteed to arrive when the broker is down, it cannot be detected by itself, so it cannot be switched to the processing when it is down. In this case, the server apparatus 1 stores and uses information (transmission buffer and packet ID correspondence information) temporarily stored and used in the database 3. In the case of QoS = 2, the server apparatus 1 basically executes the processing procedure shown in the flowchart of FIG. 39 even when the broker down is guaranteed. However, as shown in the flowchart of FIG. 29 that describes the case where the storage destination of the packet ID correspondence information is the database 3 and the case of QoS = 1, the client device connected with keep before sending the publish message When 2 is connected to itself, a process of storing a message in the database 3 (“store” and “store_target” or “store_target_broker”) is executed. That is, the server apparatus 1 performs the processing of S221, S222, S223-S225, S226, S227, and S228-S229 in the processing procedure shown in the flowchart of FIG. Performed before S518). Note that the processing relating to the puback message in FIG. 29 is replaced with the processing of the pubrec message.

  The packet ID correspondence information in the case of QoS = 2 shown in FIG. 48 is that the storage destination is the database 3, and the specific content (identification information (broker_id) of the server device 1 that performed the storage processing) is first associated. The processing procedure is the same as that in the case where down is not guaranteed (explained in (4.1) with reference to FIG. 38) except that the storage is different.

(5.2) At disconnection A case where disconnection or down occurs in the case of guaranteeing the arrival of a message in which QoS = 2 is specified even when the broker is down will be described with a specific example. Basically, as shown in FIG. 48, the processing is the same as that in the case where down is not guaranteed except that the storage destination of the packet ID correspondence information is always the database 3. When QoS = 2 guarantees message arrival even when the broker is down, it is stored as a stored message in the database 3 in advance every time a publish message is sent, and is deleted every time it is completed. Since the correspondence information is also stored in the database 3, even when it is down, the state information can be recovered from the database 3 by referring to the information at the time of recovery. In this case, specifically, the server apparatus 1 executes the processing procedure of the flowchart of FIG. 34 shown in the description of the down guarantee in QoS = 1 in (3) at the time of recovery. At this time, the corresponding message in step S409 is read as reception of a pubcomp message. That is, the stored delivery destination information and the stored message are deleted when the server apparatus 1 receives the pubcomp message.

  When guaranteeing the arrival of a message with QoS = 2 even when the broker is down, a lot of information related to the transmission / reception of the message is stored in the database 3. The process of updating and deleting the database 3 takes time. Therefore, in this case, in particular, it is expected that the processing speed can be improved by configuring the database 3 with KVS and writing all the events.

  As described above, the communication system 100 according to the first embodiment realizes message arrival guarantee from the publisher to the subscriber in consideration of broker down. Although it is possible to achieve complete arrival guarantee by storing all of the server devices 1 as brokers in the database 3, the processing speed is reduced, and the Pub / Sub message transmission / reception system The advantage of light load cannot be enjoyed. In the communication system 100 according to the present embodiment, when a client device 2 of a user who uses the system establishes a communication connection to a broker (keep) and starts a broker, that is, selects a broker to be connected from a subscriber (when the broker is down). Guarantee level), when subscribing to a broker (specifying QoS when subscribing), and when sending a message (specifying QoS when publishing), it is possible to select a guarantee level for each. is there.

  The embodiments of the present disclosure are to be considered in all respects as illustrative and not restrictive. The scope of the present invention is defined by the terms of the claims, rather than the meanings described above, and is intended to include any modifications within the scope and meaning equivalent to the terms of the claims.

1 Server device (broker)
DESCRIPTION OF SYMBOLS 10 Control part 11 1st memory | storage part 1P Server program 12 2nd memory | storage part (database)
13 Temporary Storage Unit 14 Communication Unit 2 Client Device (Publisher / Subscriber)
20 control unit 21 storage unit 22 communication unit 3 database N network

Claims (8)

In a communication method in which a publish / subscribe type message is transmitted and received by one or a plurality of server devices that mediate between a plurality of client devices that are publishers or subscribers.
The server device
0th order arrival guarantee that a message received from a client device that is a publisher should reach a client device that is a subscriber at most once, first arrival guarantee that a message should be reached at least once, always once Accepting for each message the selection of the arrival guarantee attribute to be reached in which of the second arrival guarantees to be reached,
Accepting the selection of the operation guarantee attribute for whether or not the message should be guaranteed even if it becomes unprocessable
A communication method for switching reception processing for a message received from a client device or another server device in accordance with a combination of selection of arrival guarantee attribute and selection of operation guarantee. The server device
If another server device is included in the transmission destination of the message for which the first arrival guarantee has been selected, a receipt confirmation transmitted from the other server device is received, and then a receipt confirmation is returned to the publisher.
2. The communication method according to claim 1, wherein, when a destination of the message for which the first arrival guarantee is selected does not include another server device, a receipt confirmation is returned to the source after the transmission processing to the destination of the message. . The server device uses a nonvolatile first storage medium,
If it is selected that the arrival of the message for which the first arrival guarantee is selected should be guaranteed even when the processing is disabled, the message, the message delivery destination, The communication method according to claim 2, wherein distribution destination information including presence / absence of receipt confirmation from the distribution destination is stored in the first storage medium. The server device uses a volatile second storage medium,
When another server apparatus is included in the transmission destination of the message for which the second arrival guarantee is selected, the first identification information used for receiving the message and the first identification information used for transmission to the other server apparatus Storing the first correspondence with the two identification information in the second storage medium;
After receiving the receipt confirmation transmitted from the other server device, the receipt confirmation is returned to the transmission source using the first identification information stored in the second storage medium,
When no other server device is included in the transmission destination of the message for which the first arrival guarantee is selected, the third identification information used for receiving the message and the fourth identification information used for transmission to the client device The second correspondence relationship with the identification information is stored in the second storage medium, and after the message transmission process, a receipt confirmation is returned using the third identification information stored in the second storage medium. 1 communication method. The server device uses a nonvolatile first storage medium,
When it is selected that the arrival of the message for which the second arrival guarantee has been selected should be guaranteed even when the processing is disabled,
Storing the first and second correspondences in the first storage medium;
5. The communication method according to claim 4, wherein the message, the delivery destination of the message, and delivery destination information including presence / absence of receipt confirmation from the delivery destination are stored in the first storage medium before the message is transmitted. In a communication device that mediates transmission / reception of publish / subscribe type messages,
The zeroth arrival guarantee that the received message should reach the subscriber at most once, the first arrival guarantee that the message should reach at least once, and the second arrival guarantee that the message must be reached once A first arrival guarantee attribute accepting unit for accepting selection of an arrival guarantee attribute to be reached;
An operation guarantee attribute accepting unit that accepts a selection of an operation guarantee attribute as to whether or not the arrival of a message should be guaranteed even when the process becomes unprocessable,
A communication apparatus comprising: a reception process switching unit that switches a reception process for a received message according to a combination of selection of an arrival guarantee attribute and selection of an operation guarantee. In a computer program for causing a computer including a communication unit to execute transmission / reception of a publish / subscribe type message,
In the computer,
The zeroth arrival guarantee that the received message should reach the subscriber at most once, the first arrival guarantee that the message should reach at least once, and the second arrival guarantee that the message must be reached once A process for accepting the selection of the arrival guarantee attribute to be reached,
Depending on the combination of the processing that accepts the selection of the operation guarantee attribute to determine whether or not the message should be guaranteed even if it becomes unprocessable, and the combination of the selection of the arrival guarantee attribute and the operation guarantee A computer program that executes processing to switch reception processing. In a communication system including a plurality of client devices that transmit and receive publish / subscribe messages as publishers or subscribers, and one or a plurality of server devices that mediate transmission and reception of messages between the plurality of client devices.
The server device
0th order arrival guarantee that a message received from a client device that is a publisher should reach a client device that is a subscriber at most once, first arrival guarantee that a message should be reached at least once, always once A first arrival guarantee attribute accepting unit that accepts selection of an arrival guarantee attribute to be reached in which of the second arrival guarantees to be reached;
An operation guarantee attribute accepting unit that accepts a selection of an operation guarantee attribute as to whether or not the arrival of a message should be guaranteed even when the process becomes unprocessable,
A reception process switching unit that switches a reception process for a message received from the client apparatus or another server apparatus according to a combination of the selection of the arrival guarantee attribute and the selection of the operation guarantee, and
The client device is
A first selection unit that selects the operation guarantee attribute for a server device to be connected for communication;
A communication system comprising: a second selection unit that selects an arrival guarantee attribute of a message when the message is transmitted or received.

Images