JP2008077324A - Server-client system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To solve the problem of some systems being unable to provide a state notification to a server for a long period even while a client is operating normally. <P>SOLUTION: Prior to starting a process during which it is impossible to provide a state notification to a server, a client notifies the server that a state notification will become impossible and the expected time required to resume the state notification. The server receives this, and even if there is no state notification from the client, the server does not determine it to be the failure of the client during the time that the state notification is declared impossible. If there is still no state notification after the expected time received from the client has elapsed, the server determines it to be failure of the client. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

The present invention relates to a server / client system.
In particular, the client periodically notifies the server of the status, and the server has two monitoring means: an abnormality detection by analyzing the received status notification and a client down detection due to the status notification being interrupted for a certain period of time. -It relates to the client system.

  Conventionally, there are two methods for detecting client anomalies using the server: Watch Dog and Heart Beat.

  Watch Dog is a method for detecting abnormalities by periodically performing communication for operation check from the server to the client and analyzing the response.

  On the contrary, Heart Beat is a method in which a status notification is periodically sent from the client to the server, and the server detects the abnormality by analyzing the status notification.

In the server / client monitoring means, when an abnormality occurs repeatedly, the client repeatedly notifies the server of the occurrence of the abnormality, and stops communication until the client recovers from the abnormal state repeatedly, thereby reducing communication traffic (Patent Document) 1).
Kaihei 10-269481

The present invention relates to Heart Beat.
In Heart Beat, if there is no status notification from the client for a certain period of time, the server determines that the client is in an abnormal state.

  However, depending on the system, there is a possibility that the client cannot operate normally for a long time while the client operates normally.

  Examples include planned restarts of client processes and devices themselves, occupation of processing by high-load processes, and the like.

  Even in such a case, since there is no status notification from the client, the server determines that the status of the client is abnormal.

  For this reason, recovery processing that is originally unnecessary is executed, or an abnormality is notified to the administrator.

  In order to solve this problem, the client notifies the server that the status notification is disabled and the estimated time until the status notification is restarted before starting the processing that disables the status notification to the server.

  The server receives this, and during the time declared that the status notification is impossible, even if there is no status notification from the client, it does not determine that the client is abnormal.

  If there is no status notification even after the estimated time received from the client has elapsed, it is determined that the client is abnormal.

  According to the present invention, the server can interpret the reason why the status notification from the client is interrupted, and the accuracy of abnormality detection can be improved.

(Example 1)
As an embodiment of the present invention, a system composed of a digital multi-function peripheral, an application (client) operating on the digital multi-function peripheral, and a server is given.

  The application regularly notifies the server of the client status, and the server receives the status notification at regular intervals to monitor the client status. When the server detects a client abnormality, it notifies the administrator by e-mail.

  The general application can be accessed from outside the digital multi-function peripheral using HTTP, and can check the status of the digital multi-function peripheral and the application itself, and can instruct operation change.

  When a specific setting of the digital multifunction peripheral is changed, a restart is required to reflect the setting. In this case, the application automatically restarts the digital multifunction peripheral. The application notifies the server of the digital multi-function peripheral before restarting, and notifies the estimated time until the restart is completed and the state notification is restarted.

  FIG. 1 is a block diagram illustrating the overall configuration of a system according to an embodiment of the present invention. Digital multifunction peripherals 100 and 101, a terminal 102 including a Web browser, a server 103, and a mail server 104 are connected to a network 105. In this embodiment, the terminal 102 is used as a UI for checking the status and changing settings of the digital multi-function peripheral and the applications operating thereon. Further, the mail server 104 is used for notifying an administrator of an email as an operation when an abnormality is detected in the server.

  FIG. 2 is a sequence diagram when the digital multi-function peripheral is restarted in the embodiment of the present invention. In the figure, reference numerals 100 to 103 are components of the system shown in FIG. 1, and are assigned the same numbers as in FIG.

  The Web browser 102 issues an instruction to change the setting of the digital multifunction peripheral through an application (200). The digital multi-function peripheral changes the setting (201), and if a restart is necessary to reflect the setting change, the digital multi-function peripheral enters a restart process. In the restart process, the server is restarted and the estimated time until the restart is completed is notified (202). Specifically, the client status data shown in FIG. 4 is transmitted. Notification of restarting is performed by setting a value indicating that in the status code (401).

  Thereafter, the digital multi-function peripheral restarts (204), and after the restart is completed, notifies the server (206). At this time, in the client status data to be transmitted, a value indicating normal operation is set as the status code (401), and the status notification stop time (402) is not set.

  The server receives the status notification from the client, analyzes the received data, and records the status and the status notification stop time (203). Thereafter, the client status monitoring unit performs the existence confirmation of the client using the status notification stop time recorded in 202 (205). When a restart completion notification (206) is received from the client, the client status and state notification stop time are updated (207).

  FIG. 3 is a configuration diagram of modules on a digital multi-function peripheral related to the digital multi-function peripheral through an application and the status display / setting change of the application itself in the embodiment of the present invention. The module shown here is a part of the module in the digital multifunction peripheral.

  The network I / F (300) is a module that controls communication with other devices via a network.

  The HTTP communication unit (301) and the SOAP communication unit (302) are modules for analyzing data transmitted and received by the network I / F as respective protocols.

  The application (303) has a function of periodically notifying the server of the status of the client and a function of receiving an HTTP request, displaying the status of the digital multifunction peripheral and the application itself, and changing the operation.

  The HTTP request is received through the network I / F (300) and the HTTP communication unit (301).

  When the application notifies the server of the status, it communicates via the SOAP communication unit (302), the HTTP communication unit (301), and the network I / F (303).

  The MIB I / F (304) is a module for controlling the digital multi-function peripheral using the MIB protocol.

  The OS service unit (305) is a module that controls the power supply, file system, and the like of the digital multi-function peripheral.

  When the application restarts the digital multifunction peripheral, the application accesses the OS service unit (305) via the MIB I / F (304).

  FIG. 4 shows the structure of client status data communicated from the digital multifunction peripheral as a client to the server in the embodiment of the present invention.

  The client ID (400) is a unique identifier for each client. This is distributed from the server when the client first communicates with the server.

  The status code (401) is a numeric string representing the state of the client.

  The status notification stop time (402) sets the time until the next status notification in seconds. This item is not normally set. In this case, it is treated as a default value on the server side. When the digital decoder is restarted, etc., an estimated time until the restart is completed is set.

  FIG. 5 is a basic processing flow of the client status data receiving unit of the server in the embodiment of the present invention.

  This process is executed as a new thread every time a status notification is received from the client.

  At 500, the data received from the client is analyzed. If the client status data can be normally analyzed, the process proceeds to 501.

  In 501, if the status notification stop time is included in the client status data, the process proceeds to 503, and if not included, the process proceeds to 502.

  In 502, a prescribed value is set as the status notification stop time.

  In 503, the status notification reception time and status of the client ID corresponding to the received client are recorded. The status notification stop time is recorded as the next reception interval.

  The operation flow described above is an example and is not limited to the above processing flow.

  FIG. 6 is a basic processing flow of the client state monitoring unit of the server in the embodiment of the present invention.

  This process is executed as a new thread at regular intervals.

  The processing from 600 to 604 is repeated by the number of clients.

  In 600, it is determined whether processing has been performed for all clients. When processing is performed for all clients, the process ends. If not, one unprocessed client is selected and processes 601 to 604 are executed.

  At 601, the status recorded for the client is checked. If the status is not normal, go to 604. If normal, proceed to 602.

  At 602, the current time is obtained.

  At 603, the existence of the client is confirmed. It is checked whether the current time has passed the recorded time obtained by adding the next reception interval to the status reception time from the general client. If so, since the status notification from the client is interrupted, it is determined that the client is not alive, and the process proceeds to 604. Otherwise, the client determines that it is normal and returns to 600.

  A process 604 is performed when a client abnormality is detected. Here, it is assumed that an abnormality is notified to a preset administrator's e-mail address.

  The operation flow described above is an example and is not limited to the above processing flow.

System configuration. Sequence when restarting the digital multi-function peripheral. Digital MFP configuration (excerpt). Client state data structure. The basic processing flow of the client status data receiver of the server. Basic processing flow of the client status monitoring unit of the server.

Explanation of symbols

100 to 100 Digital MFP (client)
102 Web browser
103 servers
104 mail server
200 to 207 Processing when restarting digital multi-function peripheral
300 to 305 Digital MFP module (excerpt)
400-402 Client status data components
500-604 processing steps

Claims (1)

A server having monitoring means for monitoring the client state by periodic status notification from the client, and a server having survival confirmation means for determining that the operation of the client has stopped due to the interruption of status notification from the client;
Consists of clients with status notification means that periodically notifies the server of status,
In the server / client system,
The status notification means of the client is characterized by stopping the status notification when stopping the status notification and notifying the server of the predicted value of the stop time,
The survival confirmation means of the server is characterized in that after receiving the status notification stop from the client, it does not determine that the operation of the client has stopped even if there is no notification from the client within the received stop time.
Server / client system.

Images