Communication system and device to be used therefor

Abstract

To make it possible, even when communication disconnection occurs, to return to a communication environment capable of implementing real-time property of device control and load mitigation of a control server while keeping a situation in which control for a device is executable from the control server.SOLUTION: A communication system is configured that a control server 1 and a device 3 are in full-time connection with a base station server 2 so that control using push communication is enabled from the control server 1 to the device 3. When detecting disconnection of communication with the base station server 2, the device 3 executes polling communication in parallel with executing retry processing for re-connection to the base station server 2 to make it possible, even in a period in which communication is lost between the device 3 and the base station server 2, to keep a state in which control from the control server 1 to the device 3 is executable by the polling communication while trying to returning to a state in which device control by the push communication can be performed.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a communication system and a device used therefor, and in particular, it is suitable for use in a communication system in which a control server and a device are always connected to a base station server, and the control server can perform push communication control on the device via the base station server.

Background Art

[0002] Conventionally, a system has been provided in which control is performed on a device installed at a remote location from a cloud server (control server) via a communication network such as the Internet. Here, in a network environment where a firewall is provided in the local network where the device is installed, it is not possible to directly give an instruction from the control server to the device. Therefore, in such a network environment, polling by HTTP communication is used to inquire of the control server whether there is an instruction from the device, and the device is controlled from the control server as a response thereto.

[0003] Since it is not known when an instruction from the control server will occur, the device needs to periodically execute an inquiry by polling to the control server. As the number of devices connected to the control server increases, the control server always needs to process a large number of inquiries, and the processing load increases. In order to reduce the load on such a control server, in a conventional system, the time interval for performing polling is set long. However, in this case, a problem occurs in that the control server cannot give an instruction to the device in real time.

[0004] On the other hand, a system using push communication is known as a communication method capable of the control server giving an instruction to the device in real time (see, for example, Patent Documents 1 to 3). Push communication is one of the communication methods on the Internet and refers to a communication request started by a control server.

[0005] In the system described in Patent Document 1, while aiming for real-time control through push communication using WebSocket, the push communication session is disconnected under predetermined conditions to reduce the server load for session maintenance. That is, when it is necessary to immediately issue a real-time instruction to the device for recovery in case of a failure or the like, as a response to an inquiry from the device, the management server sends an instruction to switch the communication method to push communication to the device, and establishes the push communication method by performing initial communication corresponding to the switching instruction with the device. After issuing an instruction to the device by the push communication method, the communication by the push communication method is disconnected according to predetermined conditions.

[0006] In the system described in Patent Document 2, based on the characteristics of the computer network used to communicate with the remote device and the communication characteristics of the source application of the message, for an HTTP GET request received from the source application, one of the supported set of application layer communication protocols (HTTP, CoAP, MQTT, etc.) is selected, and a message constructed according to the selected application layer communication protocol is sent to the remote device using the selected application layer communication protocol. Protocol discovery by the GET request is performed periodically, once after each communication session, or once at the start of the application. MQTT is a protocol capable of performing push communication.

[0007] In the system described in Patent Document 3, for the transmission and reception of control messages, MQTT communication, which has a low load on the network even in the case of a constant connection, is used. When relatively large data needs to be transmitted and received, HTTP communication suitable for data transfer is used only during that communication. That is, a control message is received from the connection destination of the first session using MQTT, the process specified by the control message is performed, and in order to perform the communication process associated with the process using HTTP, a second session is established with the communication destination of the communication using HTTP, and communication is performed using the first and second sessions. Then, when the communication using HTTP ends, the second session ends, and the result of the process specified by the control message is notified to the communication destination via the first session.

[0008] MQTT (Message Queuing Telemetry Transport) described in Patent Documents 2 and 3 is a communication protocol for exchanging lightweight messages between a control server and a device via a base station server called an MQTT broker. In order for the control server to transmit and receive arbitrary messages in real time, it is always connected to the MQTT broker. Also, in order for the device to transmit and receive arbitrary messages in real time, it is always connected to the MQTT broker. That is, the control server and the device are always connected to the MQTT broker as clients respectively to achieve low-latency control.

[0009] By using this push communication technology based on MQTT, it is possible to perform real-time control from the control server to the device while avoiding an increase in the processing load of the control server associated with responding to a large number of inquiries from the device by polling. For example, at the timing when a print job occurs in the control server, a message indicating the existence of the print job can be sent to a specific printer via the MQTT broker, and the printer can start the printing operation based on the reception of this message. As a result, the real-time performance of printer control by the control server is improved. At the same time, since the control server only needs to perform push communication for print job notifications at the necessary timing, it is possible to eliminate the execution of unnecessary HTTP requests from the device and reduce the processing load of the control server for responding to them.

[0010] However, when the communication between the device and the MQTT broker is lost due to some failure during the execution of MQTT communication, there has been a problem that there will be no means to execute control from the control server to the device thereafter.

Prior Art Documents

Patent Documents

[0011]

Patent Document 1

Patent Document 2

Patent Document 3

Summary of the Invention

Problems to be Solved by the Invention

[0012] The present invention has been made to solve such problems, and even when communication between a device and a base station server is lost, it maintains a state in which control of the device can be executed from a control server, while achieving real-time device control and reducing the processing load on the control server. The purpose is to be able to return to a communication environment where this is possible.

Means for Solving the Problems

[0013] In order to solve the above-described problems, in the present invention, in a communication system configured such that a control server and a device are always connected to a base station server and the control server can perform control on the device by push communication via the base station server, when the device detects a disconnection from the base station server, it executes a retry process for reconnecting to the base station server and also executes a process of receiving information from the control server by polling communication.

Effects of the Invention

[0014] According to the present invention configured as described above, when communication between the device and the base station server is lost, by performing a retry process for reconnecting from the device to the base station server, it is possible to return to a state where device control by push communication via the base station server can be performed. Also, by performing polling communication in parallel with the execution of this retry process, a state in which control of the device can be executed from the control server is maintained even during the period when communication between the device and the base station server is lost. As a result, it is possible to return to a communication environment where real-time device control and reduction of the processing load on the control server can be achieved while maintaining a state in which control of the device can be executed from the control server.

Brief Description of the Drawings

[0015]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Mode for Carrying Out the Invention

[0016] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. FIG. 1 is a diagram showing an overall configuration example of the communication system according to this embodiment. As shown in FIG. 1, the communication system of this embodiment includes a control server 1, a base station server 2, and a device 3 to be controlled. The control server 1, the base station server 2, and the device 3 are connected via a communication network 10 such as the Internet or a mobile phone network. Here, only one device 3 is shown, but there may be a plurality of them.

[0017] The control server 1 is a so-called cloud server. For example, it executes control over the device 3 according to operation instruction information transmitted via the communication network 10 from an operation terminal (not shown) for operating the device 3. Further, the control server 1 may also generate instruction information by itself and execute control over the device 3 (for example, periodically checking the status of the device 3, etc.). The operation terminal is, for example, a smartphone, a tablet terminal, a personal computer, various business terminals, and the like. The device 3 is, for example, a peripheral device such as a printer, a display, a storage device, a network device, a camera, a reader / writer, a cash drawer, etc. The device 3 only needs to have the functions shown in FIG. 3 described later, and may be a home appliance, an AV device, a game machine, a robot, an industrial machine, etc.

[0018] When the device 3 is a printer, examples of instructions given from the control server 1 to the printer include a printing instruction, a printer status request, an instruction to change the printer settings, etc. When the device 3 is a display, examples of instructions given from the control server 1 to the display include an image display instruction and a power on / off instruction, etc. When the device 3 is a storage device, examples of instructions given from the control server 1 to the storage device include an instruction to save the communication log information of the control server 1, etc. When the device 3 is a network device, examples of instructions given from the control server 1 to the network device include an instruction to cut off the network connection of a specific device, etc.

[0019] When the device 3 is a camera, examples of instructions given from the control server 1 to the camera include an image shooting instruction, etc. When the device 3 is a reader / writer, examples of instructions given from the control server 1 to the reader / writer include an instruction to read and write data, etc. When the device 3 is a cash drawer, examples of instructions given from the control server 1 to the cash drawer include a drawer open instruction, a drawer open / close status request, etc. Note that the instructions listed here are just examples and are not limited to these.

[0020] Device 3 is equipped with a function for performing HTTP communication and a function for performing MQTT communication. In order to perform MQTT communication, Device 3 is constantly connected to the base station server 2 as an MQTT client. In this case, the base station server 2 is an MQTT broker. Hereinafter, it will be referred to as MQTT Broker 2 instead of the base station server 2. Note that the control server 1 is also constantly connected to MQTT Broker 2 as an MQTT client. Device 3 can execute both HTTP communication and MQTT communication while being constantly connected to MQTT Broker 2.

[0021] When performing HTTP communication, Device 3 communicates with the control server 1 as shown in Fig. 2(a). In this case, an arbitrary request is sent from Device 3 to the control server 1, and the control server 1 returns a response to that request. In the case of HTTP communication, when a response is obtained for a request, the communication ends there. The HTTP communication performed by Device 3 includes polling. In the case of polling, Device 3 periodically sends an inquiry request to the control server 1 and obtains a response each time.

[0022] When performing MQTT communication, Device 3 communicates with MQTT Broker 2 as shown in Fig. 2(b). In this case, with the control server 1 and Device 3 constantly connected to MQTT Broker 2 as described above, it is possible to perform control on Device 3 by push communication from the control server 1 via MQTT Broker 2. That is, in the case of MQTT communication, it is not necessary to start communication by a request from Device 3 as in HTTP communication, and communication can be started in a form where a request from the control server 1 is sent to Device 3 via MQTT Broker 2.

[0023] In this embodiment, the device 3 has a function of communicating using three types of protocols regarding MQTT communication. As will be described in detail later with reference to FIG. 3, which protocol to use for communication among HTTP communication (without using MQTT communication in combination) and three types of MQTT communication (as will be described later, there are cases where HTTP communication is used in combination and cases where it is not used in combination) is determined by making an inquiry from the device 3 to the control server 1 by HTTP communication. That is, the device 3 sends an HTTP request to the control server 1 asking which protocol it should operate with. The control server 1 responds with setting information to that request. The device 3 determines the protocol to be used in its subsequent operations according to the setting information obtained from the control server 1. Thereby, it is possible to eliminate the need for the user to set in advance the protocol to be used in the device 3 with respect to the device 3. Note that it is necessary to set or store in advance the URL information of the control server 1 for making the inquiry in the device 3.

[0024] The first communication protocol regarding MQTT is a protocol in which, when the control server 1 controls the device 3, a message is sent from the control server 1 to the device 3 by MQTT communication including the data used in the device 3 (without using HTTP communication in combination). For example, when the device 3 is a printer, in addition to information notifying the control server 1 that there is print data, a message including the print data is sent from the control server 1 to the device 3 via the MQTT broker 2. In this case, the device 3 may execute printing based on the received print data and respond to the control server 1 with a message including information indicating the print result via the MQTT broker 2. Hereinafter, this first protocol is referred to as the "Full MQTT protocol".

[0025] When controlling the device 3 from the control server 1, the second communication protocol sends a message including a URL (Uniform Resource Locator) indicating the location of the data used by the device 3 from the control server 1 to the device 3 via MQTT communication, and the device 3 obtains the data from the specified URL via HTTP communication (HTTP communication is used in combination). For example, when the device 3 is a printer, in addition to the information notifying the control server 1 that print data exists, a message including a URL indicating the location of the print data is sent from the control server 1 to the device 3 via the MQTT broker 2. In this case, after the device 3 obtains the print data by accessing the specified URL via HTTP communication, it executes printing based on the print data and responds to the control server 1 with a message including information indicating the print result via the MQTT broker 2. Hereinafter, this second protocol is referred to as the "Pass URL protocol".

[0026] When controlling the device 3 in the control server 1 (for example, when the control server 1 receives operation instruction information of the device 3 from an operation terminal), as a trigger for migrating from MQTT communication to HTTP communication, a message requesting the start of HTTP communication is sent from the control server 1 to the device 3 via MQTT communication, and the actual communication for device control is performed via HTTP communication (HTTP communication is used in combination). For example, when the device 3 is a printer, when a print job occurs in the control server 1, the control server 1 requests the start of HTTP communication with the device 3 via an MQTT message. The device 3 that has received this request executes all operations from confirmation of the presence or absence of the print job, acquisition to transmission of the print result with the control server 1 via HTTP communication. Hereinafter, this third protocol is referred to as the "Trigger HTTP protocol".

[0027] FIG. 3 is a block diagram showing a functional configuration example of the device 3 according to the present embodiment. As shown in FIG. 3, the device 3 of the present embodiment includes, as a functional configuration, an HTTP communication execution unit 31, an MQTT connection unit 32, an MQTT communication execution unit 33, an MQTT connection state detection unit 34, a connection retry control unit 35, and a polling control unit 36.

[0028] The above functional blocks 31 to 36 execute the processes described below by the cooperation of hardware and software. For example, the processes of the above functional blocks 31 to 36 are executed by the operation of a program stored in a storage medium such as a RAM, a ROM, a hard disk, or a semiconductor memory under the control of a microcomputer including a CPU, a RAM, a ROM, etc. A DSP (Digital Signal Processor) may be provided in addition to the microcomputer.

[0029] The HTTP communication execution unit 31 executes HTTP communication with the control server 1. In the present embodiment, the HTTP communication execution unit 31 appropriately transmits HTTP requests such as a GET request for requesting information acquisition from the control server 1, a POST request for providing information to the control server 1, a result notification of device-side processing after information acquisition by the device 3, and a DELETE request for notifying the control server 1 that the information can be deleted, and obtains HTTP responses such as a GET response, a POST response, and a DELETE response from the control server 1 for each HTTP request. Details regarding this will be described later. When performing polling communication, the device 3 periodically transmits an HTTP request (for example, a POST request) to the control server 1.

[0030] The MQTT connection unit 32 connects to the MQTT broker 2 at a predetermined timing. When connecting to the MQTT broker 2, the HTTP communication execution unit 31 receives an instruction from the MQTT connection unit 32, sends a GET request for inquiring about the communication protocol to be used to the control server 1, and receives a GET response as a response. When the communication protocol using the MQTT broker 2 (any of the three communication protocols described above) is specified in the GET response, the MQTT connection unit 32 executes a process of connecting to the MQTT broker 2. On the other hand, when the HTTP communication protocol (without using MQTT communication together) is specified, or when the MQTT communication protocol is not specified, the MQTT connection unit 32 does not execute a process of connecting to the MQTT broker 2.

[0031] Which communication protocol to use for communication is set in advance in the control server 1. For example, information for identifying the communication protocol to be used is set in the control server 1 by the operator or the like who operates the control server 1 according to their intention. The control server 1 generates a GET response including the identification information of the communication protocol set in advance for the GET request sent from the device 3 and responds to the device 3.

[0032] When the MQTT communication protocol is specified, the GET response returned from the control server 1 to the device 3 as a response to the GET request includes, in addition to the designation information of the communication protocol to be used, connection information necessary for connecting to the MQTT broker 2, the name of the topic (communication endpoint), and the like. The connection information to the MQTT broker 2 includes, for example, the URL of the MQTT broker 2, the port number, authentication information, and the like. The topic name is information used when the device 3 acquires an MQTT message from the MQTT broker 2 or issues an MQTT message to the MQTT broker 2.

[0033] The MQTT connection unit 32 also performs processing for subscribing to messages from the MQTT broker 2 using the topic name notified by the control server 1. As a result, the MQTT communication execution unit 33, which will be described later, can receive messages sent from the control server 1 to the MQTT broker 2 by specifying the topic name. Note that the control server 1 also subscribes to topics of unspecified devices, and can receive messages sent from any device 3 by subscribing to such topics.

[0034] Here, the predetermined timings at which the MQTT connection unit 32 attempts to connect to the MQTT broker 2 (the timings at which the HTTP communication execution unit 31 sends a GET request to inquire about the protocol to be used) are, for example, the following two. The first is the timing when the power of the device 3 is turned on and the device 3 is connected to the communication network 10. The second is the timing when, during the connection between the device 3 and the MQTT broker 2, the connection is severed due to some failure and the connection retry control unit 35 requests reconnection. The retry process for the second timing will be described in detail later.

[0035] The MQTT communication execution unit 33 is always connected to the MQTT broker 2 and executes MQTT message communication with the MQTT broker 2. For example, when a message regarding the control of the device 3 is sent from the control server 1 to the MQTT broker 2, the MQTT communication execution unit 33 receives the message from the MQTT broker 2. Also, the MQTT communication execution unit 33 sends messages to the MQTT broker 2 for conveying the results of the processing executed in the device 3 in response to the received message to the control server 1, messages for conveying changes in the status of the device 3 to the control server 1, and so on.

[0036] The MQTT connection state detection unit 34 detects the connection state of the communication between the MQTT broker 2 and the device 3. Specifically, the MQTT connection state detection unit 34 determines whether the communication with the MQTT broker 2 has been connected by the processing of the MQTT connection unit 32. In addition, the MQTT connection state detection unit 34 determines whether the communication with the MQTT broker 2 has been disconnected during the always-on connection of the communication with the MQTT broker 2 by the MQTT communication execution unit 33. The communication with the MQTT broker 2 is disconnected when some communication failure occurs between the MQTT broker 2 and the device 3.

[0037] When the MQTT connection state detection unit 34 detects a disconnection of the communication with the MQTT broker 2, the device 3 executes a retry process for reconnecting to the MQTT broker 2, and in parallel with that, executes a process of receiving information (information that should originally be received by push communication via the MQTT broker 2) from the control server 1 using HTTP communication polling. That is, by executing the HTTP communication polling process in parallel with the retry process for reconnecting to the MQTT broker 2, the device 3 can maintain a state in which control from the control server 1 can be executed and can return to the operation of MQTT communication.

[0038] When the MQTT connection state detection unit 34 detects a disconnection of the communication with the MQTT broker 2, the connection retry control unit 35 controls the MQTT connection unit 32 to execute a retry process for reconnecting to the MQTT broker 2. Here, the retry process performed by the MQTT connection unit 32 is the same as the first connection process performed when the device 3 is powered on. That is, the MQTT connection unit 32 controls the HTTP communication execution unit 31 to send a GET request to the control server 1, obtains the specification of the MQTT communication protocol and the connection information to the MQTT broker 2 from the GET response, and executes a process of connecting to the MQTT broker 2.

[0039] Here, when the MQTT connection unit 32 detects that the communication disconnection with the MQTT broker 2 is detected by the MQTT connection state detection unit 34, after a predetermined time (for example, 30 seconds), the HTTP communication execution unit 31 is controlled to retransmit a GET request for inquiring about the communication protocol to be used to the control server 1. Then, as a response, the specification of the MQTT communication protocol (any one of the Full MQTT protocol, Pass URL protocol, Trigger HTTP protocol) and the connection information to the MQTT broker 2 are acquired, and a process for reconnecting to the MQTT broker 2 (hereinafter, sometimes simply referred to as a reconnection process) is executed.

[0040] Note that there may be a possibility that one control server 1 and a plurality of devices 3 perform MQTT communication via the MQTT broker 2. In that case, if any communication failure occurs between the MQTT broker 2 and the device 3, retry processing is executed in the plurality of devices 3. In this case, GET requests are sent from the plurality of devices 3 to the control server 1. Therefore, in order to reduce the load on the control server 1, it is preferable that the predetermined time is set so that a large number of devices 3 do not send GET requests to the control server 1 at exactly the same timing, and the same time is not set for all of the plurality of devices 3 connected to the MQTT broker 2.

[0041] For example, the connection retry control unit 35 controls the MQTT connection unit 32 to send a GET request after a predetermined time set within a range of 30 seconds ± 5 seconds. The predetermined time within a range of 30 seconds ± 5 seconds can be randomly determined by the connection retry control unit 35 when executing the retry process, for example. Alternatively, a predetermined time randomly determined in advance within a range of 30 seconds ± 5 seconds may be set for each device 3, and each device 3 may send a GET request after the predetermined time based on this set value.

[0042] When the retry process is performed by the MQTT connection unit 32, the MQTT connection state detection unit 34 determines whether communication with the MQTT broker 2 has been established. Here, if it is detected that the reconnection to the MQTT broker 2 has been successful by the retry process, the polling communication of HTTP by the polling control unit 36 is stopped, and the operation returns to the original MQTT communication by the MQTT communication execution unit 33.

[0043] On the other hand, when the MQTT connection state detection unit 34 detects that reconnection to the MQTT broker 2 cannot be made, this is notified to the connection retry control unit 35. In this case, the MQTT connection unit 32 receives an instruction from the connection retry control unit 35 and re-executes the retry process (sending a GET request to the control server 1 and the reconnection process to the MQTT broker 2). Thereafter, if the state where reconnection to the MQTT broker 2 cannot be made continues, the retry process is repeatedly executed. Here, an upper limit value may be set for the number of repetitions, and when reconnection cannot be made even after reaching the upper limit value, a connection failure error message may be output and the retry process may be terminated.

[0044] When repeatedly executing the retry process, as the number of repetitions increases, the time interval for performing the retry process (that is, the predetermined time from when it is detected that reconnection to the MQTT broker 2 has failed until the retry process is re-executed) may be gradually lengthened. For example, for the first time, the retry process is executed after a predetermined time determined within the range of 30 ± 5 seconds from when communication disconnection is detected, and for the second and subsequent times, the retry process is executed after 1 minute, 2 minutes, 4 minutes, 8 minutes, ··· after reconnection failure, gradually lengthening the predetermined time. This is also a method for reducing the load on the control server 1. The maximum value of the predetermined time may be set to 8 minutes, and after reaching the maximum value, the retry process may be repeatedly executed every 8 minutes. Note that the numerical values of the predetermined time given here are just examples and are not limited thereto. Also, for the second and subsequent times, the retry process may be performed after a predetermined time determined within the range of 1 minute ± 5 seconds, 2 minutes ± 5 seconds, 4 minutes ± 5 seconds, 8 minutes ± 5 seconds.

[0045] When the disconnection from the MQTT broker 2 is detected by the MQTT connection state detection unit 34, the polling control unit 36 controls the HTTP communication execution unit 31 to execute the process of receiving information from the control server 1 by polling communication. The information that the control server 1 sends to the device 3 is arbitrary. For example, there are notifications, instructions, requests for the device 3, data used for processing in the device 3, and so on. In this case, the HTTP communication execution unit 31 periodically sends an HTTP request to the control server 1 to check whether there is information to be sent from the control server 1 to the device 3. When receiving an HTTP response indicating that there is information, the HTTP communication execution unit 31 continues to execute an HTTP request to receive information from the control server 1. Then, the device 3 executes the process corresponding to the information and sends the processing result to the control server 1 by an HTTP request.

[0046] Here, the time interval at which the HTTP communication execution unit 31 repeatedly sends an HTTP request is preferably shorter than a predetermined time (30 seconds) until the MQTT connection unit 32 executes the first retry process at the time of detecting the communication disconnection. For example, an HTTP request is sent every 5 seconds.

[0047] FIGS. 4 to 6 are diagrams showing an example of a processing flow when MQTT communication is normally performed in a state where there is no communication disconnection between the MQTT broker 2 and the device 3. FIG. 4 shows a processing flow example when performing MQTT communication using the Full MQTT protocol, FIG. 5 shows a processing flow example when performing MQTT communication using the Pass URL protocol, and FIG. 6 shows a processing flow example when performing MQTT communication using the Trigger HTTP protocol. FIGS. 4 to 6 show an example of the process when the device 3 is a printer. It is assumed that the connection between the control server 1 and the MQTT broker 2 has already been completed before the execution of the processes shown in the flowcharts of FIGS. 4 to 6.

[0048] In the case of printer control using MQTT communication, examples of the MQTT messages issued by the control server 1 to control the printer are as follows. · A message requesting the status of the printer. Printer statuses include, for example, standby, cover open, out of paper, out of toner, etc. · A message for causing the printer to execute printing. In the case of the Full MQTT protocol, the print data itself is included in the payload of the message. In the case of the Pass URL protocol, the URL storing the print data is included in the message. · A message for controlling peripheral devices connected to the printer.

[0049] Also, examples of MQTT messages issued by the printer to the control server 1 include the following. · A message for notifying its own status. Issued when a change occurs in the status or when the above-mentioned request message is received from the control server 1. · A message for notifying the print result (success or failure, etc.).

[0050] In FIG. 4, when the printer is powered on and connected to the communication network 10, the MQTT connection unit 32 controls the HTTP communication execution unit 31 to send a GET request to the control server 1 via HTTP to inquire about the communication protocol to be used, and acquires the specified information of the communication protocol and the connection information to the MQTT broker 2 in the GET response (step S11). Here, it is specified to use MQTT communication based on the Full MQTT protocol.

[0051] Subsequently, the MQTT connection unit 32 executes the process of connecting to the MQTT broker 2 based on the acquired connection information, and also executes the process for subscribing to messages using the topic name (step S12). As a result, the printer is always connected to the MQTT broker 2 as an MQTT client.

[0052] After that, in the example of FIG. 4, MQTT communication for checking the status of the printer is performed at an arbitrary timing (step S13). In the process of this step S3, at an arbitrary timing, the control server 1 sends a status request message to the MQTT broker 2, and this is received by the MQTT communication execution unit 33 of the printer from the MQTT broker 2. Then, the MQTT communication execution unit 33 of the printer sends a message for notifying its own status to the MQTT broker 2, and this is received by the control server 1 from the MQTT broker 2.

[0053] Also, when a print instruction is executed from the operation terminal to the control server 1 at an arbitrary timing, printing on the printer is executed by MQTT communication of the Full MQTT protocol (step S14). In the process of this step S14, at the timing when the control server 1 receives print instruction information from the operation terminal, the control server 1 sends a message (print data is included in the payload) for causing the printer to execute printing to the MQTT broker 2, and this is received by the MQTT communication execution unit 33 of the printer from the MQTT broker 2. Then, after the printer executes printing based on the print data included in the message, the MQTT communication execution unit 33 sends a message for notifying the print result to the MQTT broker 2, and this is received by the control server 1 from the MQTT broker 2.

[0054] After that, in the example of FIG. 4, due to the status of the printer changing at an arbitrary timing, MQTT communication for notifying the changed status from the printer to the control server 1 is performed (step S15). In the process of this step S5, at the timing when the status of the printer changes, the MQTT communication execution unit 33 sends a status notification message to the MQTT broker 2, and this is received by the control server 1 from the MQTT broker 2.

[0055] In FIG. 5, when the printer is powered on and connected to the communication network 10, the MQTT connection unit 32 controls the HTTP communication execution unit 31 to send a GET request for inquiring about the communication protocol to be used to the control server 1 via HTTP communication, and acquires the specified information of the communication protocol and the connection information to the MQTT broker 2 as a response via a GET response (step S21). Here, it is specified to use MQTT communication based on the Pass URL protocol.

[0056] Subsequently, the MQTT connection unit 32 executes a process of connecting to the MQTT broker 2 based on the acquired connection information, and executes a process for message subscription (Subscribe) using the topic name (step S22). As a result, the printer is always connected to the MQTT broker 2 as an MQTT client.

[0057] Thereafter, when a print instruction is executed from the operation terminal to the control server 1 at an arbitrary timing, printing on the printer is executed by MQTT communication of the Pass URL protocol (step S23). In the process of this step S23, at the timing when the control server 1 receives the print instruction information from the operation terminal, the control server 1 sends a message (including a URL indicating the storage location of the print data) for causing the printer to execute printing to the MQTT broker 2, and this is received by the MQTT communication execution unit 33 of the printer from the MQTT broker 2.

[0058] In response, the HTTP communication execution unit 31 of the printer sends a GET request to request a print job from the control server 1 specified by the URL, and acquires the print job (including print data) through the GET response. As the format of the print job, printer commands, text data, image data (PNG), etc. can be used (the same applies in FIG. 6). Here, the destination of the GET request specified by the URL does not have to be the control server 1 that made the print execution request (for example, a dedicated server for data storage may be provided separately). Then, after executing printing based on the print data acquired by the printer, the MQTT communication execution unit 33 sends a message for notifying the print result to the MQTT broker 2, and the control server 1 receives this from the MQTT broker 2.

[0059] Although FIG. 5 does not illustrate the processing for checking the status of the printer and the processing for status notification, they can be executed at an arbitrary timing similar to step S13 and step S15 in FIG. 4.

[0060] In FIG. 6, when the printer is powered on and connected to the communication network 10, the MQTT connection unit 32 controls the HTTP communication execution unit 31 to send a GET request to the control server 1 via HTTP to inquire about the communication protocol to be used, and acquires the specified information of the communication protocol and the connection information to the MQTT broker 2 through the GET response (step S31). Here, it is specified to use MQTT communication based on the Trigger HTTP protocol.

[0061] Subsequently, the MQTT connection unit 32 executes the process of connecting to the MQTT broker 2 based on the acquired connection information, and also executes the process for subscribing to messages using the topic name (step S32). As a result, the printer is always connected to the MQTT broker 2 as an MQTT client.

[0062] After that, when a print instruction is executed from the operation terminal to the control server 1 at an arbitrary timing, printing on the printer is executed by HTTP communication triggered by MQTT communication of the Trigger HTTP protocol (step S33). In the process of this step S33, at the timing when the control server 1 receives print instruction information from the operation terminal, the control server 1 transmits a message requesting the issuance of a POST request to the printer to the MQTT broker 2, and this is received by the MQTT communication execution unit 33 of the printer from the MQTT broker 2. Triggered by this, the printer executes subsequent processes by the HTTP communication execution unit 31. Note that while the printer is executing the HTTP communication of step S33 in response to the request for issuing a POST request from the control server 1, on the other hand, the subscription of MQTT messages (receiving the request for issuing a POST request from the control server 1) is continuously executed.

[0063] First, the HTTP communication execution unit 31 of the printer transmits a POST request for its own status notification and confirmation of the presence or absence of a print job to the control server 1, and confirms that there is a print job by the POST response. Subsequently, the HTTP communication execution unit 31 transmits a GET request for requesting a print job to the control server 1, and acquires the print job (including print data) by the GET response. Then, after printing is executed based on the print data acquired by the printer, the HTTP communication execution unit 31 transmits a DELETE request for print job completion confirmation to the control server 1, and receives a DELETE response of the confirmation result returned from the control server 1.

[0064] After that, in the example of FIG. 6, due to the change in the status of the printer at an arbitrary timing, HTTP communication for notifying the changed status from the printer to the control server 1 is performed (step S34). In the process of this step S34, at the timing when the status of the printer changes, the printer transmits a POST request for its own status notification to the control server 1, and receives a response from the control server 1 by the POST response.

[0065] As described above, in the Trigger HTTP protocol, unlike the Full MQTT protocol and the Pass URL protocol, only the request to issue a POST request from the control server 1 to the printer is made by MQTT communication, and for the rest, the HTTP communication protocol is used for information communication. As a result, even in the control server 1 that originally did not implement the MQTT communication function, it is possible to apply this embodiment with only a slight modification to implement the function of issuing a POST request by MQTT communication (in a configuration that does not change the HTTP communication environment as much as possible).

[0066] FIG. 7 is a flowchart showing an example of the processing executed in the device 3 when the communication between the MQTT broker 2 and the device 3 is disconnected during the execution of the MQTT communication shown in FIGS. 4 to 6. First, the MQTT connection state detection unit 34 determines whether the communication with the MQTT broker 2 has been disconnected (step S71). If the disconnection of the communication has not been detected, the determination process of step S71 is continuously executed while continuing the execution of the MQTT communication shown in FIGS. 4 to 6.

[0067] When the disconnection of the communication with the MQTT broker 2 is detected by the MQTT connection state detection unit 34, the polling control unit 36 controls the HTTP communication execution unit 31 to start polling communication (step S72). As a result, the HTTP communication execution unit 31 periodically executes, separately from the processing of the flowchart shown in FIG. 7, for example, processing to confirm the presence or absence of information from the control server 1 by sending a POST request. For example, the same processing as step S33 in FIG. 6 (excluding the request to issue a POST request by an MQTT message) is periodically executed.

[0068] Also, the connection retry control unit 35 determines whether or not a predetermined time (for example, 30 ± n seconds; 0 ≦ n ≦ 5) has elapsed since the communication disconnection from the MQTT broker 2 was detected in step S71 (step S73). If the predetermined time has not yet elapsed, the determination process in step S73 is continuously executed. When it is determined that the predetermined time has elapsed, the connection retry control unit 35 controls the MQTT connection unit 32 to execute a retry process for reconnecting to the MQTT broker 2 (step S74).

[0069] Next, the MQTT connection state detection unit 34 determines whether or not the communication with the MQTT broker 2 has been connected by the retry process (step S75). Here, when it is determined that the communication with the MQTT broker 2 has been connected, the polling control unit 36 controls the HTTP communication execution unit 31 to stop the polling communication (step S76). Then, the operation of the MQTT communication by the MQTT communication execution unit 33 is restarted (step S77), and the process returns to step S71.

[0070] On the other hand, in step S75, when it is determined that the reconnection to the MQTT broker 2 cannot be made, the connection retry control unit 35 determines whether or not the number of repetitions of the retry process has reached the upper limit value (step S78). If the upper limit value of the number of repetitions has not yet been reached, the connection retry control unit 35 sets a predetermined time (for example, 1 minute) that is one step longer than the current time (step S79). Then, it is determined whether or not the set predetermined time has elapsed since the failure of the reconnection by the retry process (step S80). If the predetermined time has not yet elapsed, the determination process in step S80 is continuously executed.

[0071] When it is determined that the predetermined time has elapsed, the connection retry control unit 35 controls the MQTT connection unit 32 to execute a retry process for reconnecting to the MQTT broker 2 (step S81). After that, the process returns to step S75, and it is determined whether or not the communication with the MQTT broker 2 has been connected by the retry process.

[0072] Thereafter, until the reconnection to the MQTT broker 2 is successful, the processes of steps S75, S78 to S81 are repeatedly executed. In this repeated process, when it is determined in step S78 that the number of repetitions has reached the upper limit value, the connection retry control unit 35 outputs an error message indicating that reconnection is impossible (step S82), and ends the process of the flowchart shown in FIG. 7.

[0073] As described in detail above, in the present embodiment, in a communication system configured such that the control server 1 and the device 3 are always connected to the MQTT broker 2 and the control server 1 can perform control on the device 3 by push communication via the MQTT broker 2, when the device 3 detects a communication disconnection from the MQTT broker 2, it executes a retry process for reconnecting to the MQTT broker 2 and also executes a process of receiving information from the control server 1 by HTTP polling communication.

[0074] According to the present embodiment configured as described above, even when the communication between the device 3 and the MQTT broker 2 is lost, it is possible to attempt to return to MQTT communication that can realize the real-time performance of the control of the device 3 and the reduction of the processing load of the control server 1 while maintaining a state in which the control from the control server 1 to the device 3 can be executed by HTTP polling communication. In other words, even during the period of attempting to return to a state where MQTT communication is possible, it is possible to maintain a state in which the control from the control server 1 to the device 3 can be executed by HTTP polling communication performed in parallel with the execution of the retry process, and avoid a state where the control of the device 3 becomes completely impossible.

[0075] In the above-described embodiment, an example was described in which any one of three types of MQTT communication protocols, namely the Full MQTT protocol, the Pass URL protocol, and the Trigger HTTP protocol, is selected and applied. However, the present invention is not limited to this. For example, any one of two types of protocols, namely the Full MQTT / Pass URL protocol and the Trigger HTTP protocol, may be selected and applied. When the Full MQTT / Pass URL protocol is selected, each time the control server 1 gives an instruction to the device 3, the control server 1 determines which pattern of the Full MQTT protocol or the Pass URL protocol to operate in. For example, when the device 3 is a printer, if the print instruction information includes print data, the Full MQTT protocol is used, and if the URL indicating the location of the print data is included, the Pass URL protocol is used.

[0076] Also, in the above-described embodiment, as the timing at which the MQTT connection unit 32 attempts to connect to the MQTT broker 2 (the timing at which a GET request for confirming the communication protocol is transmitted), the timing when the power of the device 3 is turned on and the timing when the communication with the MQTT broker 2 is disconnected (including the timing when the retry process fails and the retry process is executed again) were exemplified. However, the present invention is not limited to this.

[0077] For example, a GET request may be transmitted at the following timing. (1) When, although the use of the MQTT communication protocol is instructed by a GET response, the connection to the designated MQTT broker 2 cannot be established. Also in this case, the device 3 executes the processes of the connection retry control unit 35 and the polling control unit 36.

[0078] (2) When an instruction to execute a GET request again by specifying a predetermined URL is described in the GET response to the GET request. For example, in addition to the control server 1, a control server for debugging, an MQTT broker for debugging, and a device for debugging may be provided, and an operation for debugging may be executed. In this case, when an instruction to execute a GET request again by specifying the URL of the control server for debugging is described in the GET response to the GET request sent from the device for debugging to the control server 1, a GET request is sent from the device for debugging to the control server for debugging. In the case of this example, the device for debugging and the control server for debugging are connected to the MQTT broker for debugging and execute the same processing as described in the above embodiment.

[0079] (3) When an instruction to execute a GET request again is described in the GET response to the GET request every time the specified time elapses, and when the specified time has elapsed. In this case, while executing the operations shown in FIGS. 4 to 6 in response to the first GET request, every time the specified time elapses from the transmission of the first GET request, the device 3 sends a GET request to the control server 1. At this time, if the connection information to the MQTT broker 2, the topic name, etc. described in the GET response have been updated from the current information, the connection to the MQTT broker 2 is re-executed using the updated information.

[0080] (4) When the device 3 receives an MQTT message describing an instruction to execute a GET request while performing the operation of MQTT communication. Also in this case, similar to the above (3), in the GET response to the GET request executed according to the execution instruction, if the connection information to the MQTT broker 2, the topic name, etc. have been updated, the connection to the MQTT broker 2 is re-executed using the updated information.

[0081] (5) When an instruction to execute a GET request is described in the POST response received as a response to the POST request sent from the device 3 to the control server 1 while the device 3 is performing the operation of HTTP communication. In this case, device 3 operates according to the information described in the GET response for the GET request executed according to the execution instruction.

[0082] Also, in the above embodiment, MQTT broker 2 is given as an example of the base station server 2, and an example using MQTT communication as a protocol capable of push communication from the control server 1 to device 3 has been described, but it is not limited to this. Similar to the MQTT broker 2, any protocol that can transmit and receive messages using a base station server 2 that constantly connects the control server 1 and device 3 as clients respectively, and that can execute communication in parallel with HTTP communication, can apply the above embodiment.

[0083] Also, in the above embodiment, an example of executing retry processing including the transmission of a GET request to the control server 1 (a request for inquiring about the communication protocol to be used) has been described, but it is not limited to this. For example, the reconnection process to the MQTT broker 2 may be executed omitting the transmission of the GET request to the control server 1. In this case, the MQTT connection unit 32 may attempt to reconnect to the MQTT broker 2 based on the connection information of the MQTT broker 2 already acquired during the first connection process. If the connection to the MQTT broker 2 cannot be established even by this retry process, in subsequent retry processes, the reconnection process to the MQTT broker 2 is also executed omitting the transmission of the GET request to the control server 1. By doing so, a GET request is not transmitted from device 3 to the control server 1 during the execution of the retry process, and the processing load on the control server 1 can be reduced.

[0084] In addition, the first retry process may be performed including the transmission of a GET request to the control server 1, and when the MQTT connection status detection unit 34 detects that the retry process cannot reconnect to the MQTT broker 2, the retry process may be re-executed without transmitting the GET request to the control server 1 for the second and subsequent retry processes. In this case, when the second and subsequent retry processes are executed, the MQTT connection unit 32 may attempt to reconnect to the MQTT broker 2 based on the connection information of the MQTT broker 2 already acquired during the first retry process. In this way, the same device 3 will not repeatedly send a GET request to the control server 1, and the processing load of the control server 1 can be reduced. In addition, even if the connection information of the MQTT broker 2 has changed between the time of the first connection and the time of communication disconnection, the latest connection information can be obtained during the first retry process to execute the reconnection process to the MQTT broker 2.

[0085] In addition, when repeatedly executing the reconnection process to the MQTT broker 2, the time interval for performing the reconnection process (i.e., the time from when a failure to reconnect to the MQTT broker 2 is detected to when the reconnection process is reexecuted) may be gradually increased as the number of repetitions increases.

[0086] In addition, the above-mentioned embodiments are merely examples of the implementation of the present invention, and the technical scope of the present invention should not be interpreted as being limited thereby. In other words, the present invention can be implemented in various forms without departing from the gist or main characteristics thereof. [Explanation of symbols]

[0087] 1 Control Server 2 Base station server (MQTT broker) 3 Devices 31 HTTP communication execution unit 32 MQTT connection 33 MQTT Communication Execution Unit 34 MQTT Connection State Detection Unit 35 Connection Retry Control Unit 36 Polling Control Unit

Claims

1. In a communication system in which a control server and a device are always connected to a base station server, and control by push communication can be performed on the device from the control server via the base station server, when the device detects a disconnection from the base station server, the device executes a retry process for reconnecting to the base station server and executes a process of receiving information from the control server by polling communication. A communication system characterized by the above.

2. The device at a predetermined timing, sends a request to the control server to inquire about the communication protocol to be used, and when the communication protocol using the base station server is specified as a response, performs a process of connecting to the base station server, and when executing the retry process, resends the request to the control server, receives a specification of the communication protocol using the base station server as a response, and executes a process for reconnecting to the base station server The communication system according to claim 1, characterized by the above.

3. when the device executes the retry process, the device resends the request to the control server after a predetermined time from when the disconnection from the base station server is detected, the predetermined time is set so as not to be the same for all of a plurality of devices connected to the base station server The communication system according to claim 2, characterized by the above.

4. when, as a result of executing the retry process, the device fails to reconnect to the base station server, the device re-executes the retry process after a predetermined time from when the failure to reconnect is detected, the predetermined time until the retry process is re-executed is set to increase as the number of repetitions of the retry process increases The communication system according to claim 3, characterized by the above.

5. The device at a predetermined timing, sends a request to the control server to inquire about the communication protocol to be used, and when the communication protocol using the base station server is specified as a response, performs a process of connecting to the base station server, and When executing the retry process in response to detecting a communication disconnection with the base station server, retransmit the request to the control server, and in response thereto, receive a specification of the communication protocol using the base station server, and execute a process for reconnecting to the base station server. If, as a result of executing the retry process, it is not possible to reconnect to the base station server, re-execute the retry process. When executing the retry process for the second time and subsequent times, execute a process for reconnecting to the base station server without retransmitting the request to the control server. The communication system according to claim 1, characterized in that.

6. When the device executes the retry process in response to detecting a communication disconnection with the base station server, retransmit the request to the control server after a predetermined time from when the communication disconnection with the base station server is detected. The predetermined time is set so as not to be the same for all of a plurality of devices connected to the base station server. The communication system according to claim 5, characterized in that.

7. The communication system according to any one of claims 1 to 6, characterized in that when the device successfully reconnects to the base station server by the retry process, the polling communication is stopped.

8. A device that is always connected to a base station server and can receive control by push communication via the base station server from a control server that is always connected to the base station server, A device characterized in that when a communication disconnection with the base station server is detected, a retry process for reconnecting to the base station server is executed, and a process for receiving information from the control server by polling communication is executed.

Images