Method and system for logging event data and persistently downloading the same

0001The present invention generally relates to a method and system for logging event data from at least one operable application program or at least one peripheral device operably connected to a server. More particularly, it relates to a method and system for logging event data that retrieves all the event data for the server, and can maintain a persistent connection when the event data are being downloaded to allow the server to attend to multiple requests resulting in the downloading of event data as they come in.

0002A computer server commonly uses a vast array of application programs and peripheral devices. Each of the application programs and the peripheral devices generally generates event data for events that occur during the operation of the computer server. Events are significant occurrences of a task or program and may relate to matters such as completions, connections, processes, terminations, status changes, errors and warnings. The event data are essential for network diagnostic and troubleshooting. The event data are often used by other application programs and peripheral devices as well.

0003Because of all the different connections and communications between computers that are easily available today, computer troubleshooting is no longer limited to the site of the computer. As a result, there is a need to keep a log of these event data over an extended period of time that can be easily downloaded by users of other computers. However, a typical transfer of a file involves a single request and a single response methodology. In other words, when a file is requested, the two connecting computers will generally terminate their connection once the transfer of the file is complete, which is especially true for a connection over the Internet. Since these event data change rapidly, it would be very useful to be able to keep a persistent connection for downloading the event data file. A persistent connection allows for multiple requests to be served by the server while at the same time permitting the requesting computer to continue downloading the event data as the server continues its operation and new event data comes in.

0004One prior method is to buffer the event data on the server, with periodic requests being made to download the event data. In this method, all the event data are stored on the server's memory, which remain until a request to download is made. Depending on the capacity of the server and the frequency of the downloading, one problem is that some of the event data may have to be discarded. As a result, valuable event data may be lost using this method. Furthermore, that implementation requires servers with significant resources in order to handle busier networks, which may be impracticable for the use of an appliance with an embedded smaller scale server, such as a Hewlett-Packard JetDirect product.

0005Another prior method that establishes a persistent connection through the web uses Java applets, which establish their own TCP/IP connection to the server and continuously receive the event data. However, a problem with this method is its inflexibility, because it limits the connections to computers that support Java applets. As a result, it is limited to the use of a web connection, and cannot be used with an intranet connection or a direct cable connection. Furthermore, a security certificate is required for a Java applet to establish a network connection, which may not be practical depending on the implementation.

0006Accordingly, a primary object of the present invention is to provide an improved method and system for logging event data that provides a persistent connection for downloading event data.

0007Still another object of the present invention is to provide an improved method and system for logging event data that maintains a log of event data ready for downloading.

0008Yet another object of the present invention is to provide an improved method and system for logging event data that is more flexible and less restrictive.

0009A further object of the present invention is to provide an improved method and system for logging event data that can maintain a persistent connection for downloading while allowing the server to attend to multiple requests and continue logging the event data.

SUMMARY OF THE INVENTION

0010The present invention generally relates to a method and system for logging event data from at least one operable application program or at least one peripheral device operably connected to a server. More particularly, it relates to a method and system for logging event data that keeps all the event data for the server and maintains a persistent connection when the event data are being downloaded while allowing the server to attend to multiple requests.

0011In accordance with the present invention, there is provided a method and system for logging event data from at least one operable application program or at least one peripheral device operably connected to a server using a log manager device driver. The method includes the steps of registering the log manager device driver with the server to receive all incoming event data, registering the log manager device driver with the server as a log manager file, the log manager device driver receiving the event data, and the log manager device driver responding to a download request for the log manager file from a requesting computer.

0012Other objects, features and advantages will become apparent upon reading the following detailed description, in conjunction with the attached drawings, in which:

0013<figref idref="DRAWINGS">FIG. 1</figref> is a schematic exemplary diagram of a network architecture in which the present method can be implemented;

0014<figref idref="DRAWINGS">FIG. 2</figref> is a flowchart illustrating a subroutine of the log manager device driver initializing and receiving the event data;

0015<figref idref="DRAWINGS">FIG. 3</figref> is a flowchart illustrating a subroutine of the log manager responding to a download request for the event data; and,

0016<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart illustrating a part of the subroutine shown in <figref idref="DRAWINGS">FIG. 3</figref>.

DETAILED DESCRIPTION

0017Broadly stated, the present invention is directed to an improved method and system for logging event data in a server that receives all event data ready for downloading to another computer using a persistent connection. A log manager device driver first registers with the server to receive all incoming event data and as the device driver for a log manager file. After the registration with the server, the log manager device driver starts receiving the event data and responding to a download request for the log manager file from a requesting computer.

0018Turning now to <figref idref="DRAWINGS">FIG. 1</figref>, a schematic diagram of an exemplary network architecture is shown, which illustrates one way that the network can be connected for the implementation of the present invention. As shown in <figref idref="DRAWINGS">FIG. 1</figref>, a server <b>10</b> is installed with at least one application program <b>12</b> (three shown) and connected to at least one peripheral device <b>14</b> (three shown). A log manager device driver <b>16</b> is preferably placed in the server along with the application program <b>12</b>.

0019In the present invention, a requesting computer <b>18</b> seeking to download event data from the server <b>10</b> would make a request to download a log manager file <b>20</b>, which is represented as a regular file and not a device driver file. Since the log manager device driver <b>16</b> had itself as the log manager file <b>20</b> at the startup, the log manager device driver would, in reality, be opened by the requesting computer <b>18</b>. In practice, the server <b>10</b> and requesting computer <b>18</b> treat the connection as a download of a very large file. However, the log manager file <b>20</b> does not really exist. Rather the request of the file prompts the log manager device driver to return event data to the server, which is sent to the requesting computer as data of the log manager file.

0020As shown in <figref idref="DRAWINGS">FIG. 1</figref>, an event queue <b>22</b> is preferably implemented with the log manager device driver <b>16</b> for storing event data that has not yet been downloaded. However, the permanent storage of the event data is not necessary. For example, the present invention can be implemented to display the data as it is downloaded from the temporary memory of the server <b>10</b>. In addition, the connection arrangements can be altered. As an example, a peripheral device <b>14</b> need not be connected to the server <b>10</b>, and the same is true for the application program <b>12</b>. These other arrangements and implementations are within the scope of the present invention.

0021Turning now to <figref idref="DRAWINGS">FIG. 2</figref>, a flowchart showing the steps of the log manager device driver <b>16</b> initializing and receiving event data from the application program <b>12</b> or the peripheral device <b>14</b> is shown and generally indicated at <b>24</b>. Device drivers comprise software that control hardware components or peripheral devices, such as a magnetic disk, magnetic tape or printer. At the startup of the computer, the device driver generally registers with the operating system as a device driver for a particular hardware component or peripheral device.

0022For the present invention, at the startup of the server (block <b>26</b>), the log manager device driver <b>16</b> first registers with the server to receive all event data (block <b>28</b>). More specifically, the operating system of the server <b>10</b> is instructed that any time an application program <b>12</b> or a peripheral device <b>14</b> requests to log an event, the event data should be sent to the log manager device driver <b>16</b>. Generally, the application programs and the peripheral devices control when and what event data are sent, and the log manager device driver <b>16</b> just simply receives the event data. Next, the log manager device driver <b>16</b> registers with the server again, except this time as a device driver for the log manager file <b>20</b> (block <b>30</b>).

0023After all the registrations are made with the server, the log manager device driver <b>16</b> then sits idle waiting for event data from the application programs <b>12</b> or the peripheral devices <b>14</b> (block <b>32</b>). Once an application program <b>12</b> or a peripheral device <b>14</b> sends the event data to the log manager device driver (block <b>34</b>) and the log manager device driver <b>16</b> receives the event data (block <b>36</b>), the log manager device driver then determines whether the event queue is full for the newly arrived event data (block <b>38</b>). If the event queue is full (block <b>40</b>), the log manager device driver <b>18</b> deletes the oldest event data in the queue in order to make room (block <b>42</b>) to save the newly arrived event data in the event queue (block <b>44</b>). After saving the event data in the queue (block <b>44</b>, the process loops back to the log manager device driver waiting for more incoming event data (block <b>32</b>). The receiving event data process is done by the log manager device driver regardless of whether there is a download request initiating the downloading process. In other words, the log manager device driver receives and saves all the event data in the event queue waiting for the requesting computer <b>18</b> to download the log manager file <b>20</b> from the server <b>10</b>.

0024Turning now to <figref idref="DRAWINGS">FIGS. 3 and 4</figref>, a flowchart of the subroutine of the log manager device driver responding to a download request of the event data is shown and generally indicated at <b>46</b>. To initiate this process, a requesting computer <b>18</b> must first request a log manager file from the server <b>10</b> (block <b>48</b>). The requesting computer <b>18</b> then determines whether the server <b>10</b> received the request to ensure a valid connection between the requesting computer and the server (block <b>50</b>). If it is determined that the server <b>10</b> did not receive the request (block <b>50</b>), the requesting computer <b>18</b> will return an error message (block <b>52</b>), which is preferably displayed to the user (block <b>54</b>). On the other hand, if the server <b>10</b> did receive the request (block <b>50</b>), the server will open the log manager file <b>20</b> from the log manager device driver <b>16</b> (block <b>56</b>).

0025The server next determines whether the log manager file <b>20</b> is successfully opened from the log manager device driver (block <b>58</b>). If the opening of the file proves to be unsuccessful (block <b>58</b>), the server <b>10</b> will return an error message to the requesting computer <b>18</b> (block <b>60</b>), which is again preferably displayed to the user (block <b>62</b>). If, however, the file is opened successfully, the server reads the event data from the event queue (block <b>64</b>), and determines whether there are any event data available (block <b>66</b>).

0026If the event queue does not have any event data available (block <b>66</b>), the server blocks, meaning it stays idle and waits, until event data are available in the event queue (block <b>68</b>). Similarly, the log manager device driver also stays idle and waits for the event data (block <b>70</b>). When event data are sent from the application program <b>12</b> or the peripheral device <b>14</b> (block <b>72</b>), the log manager device driver <b>16</b> receives the event data (block <b>74</b>) and determines whether the event queue is full (block <b>76</b>). If the queue is full (block <b>78</b>), the oldest event data in the queue will be deleted to make available space for the newly arrived event data (block <b>80</b>). Once the event queue <b>22</b> has the available space in the event queue (block <b>78</b>), the log manager device driver <b>16</b> saves the event data in the queue (block <b>82</b>).

0027Now that event data is available (block <b>66</b>), <figref idref="DRAWINGS">FIG. 4</figref> shows the remaining steps of the subroutine from <figref idref="DRAWINGS">FIG. 3</figref>. Referring now to <figref idref="DRAWINGS">FIG. 4</figref>, since event data is available in the queue, the log manager device driver returns the event data in the queue to the server (block <b>84</b>). The server receives the event data (block <b>86</b>), and sends it to the requesting computer (block <b>88</b>). The requesting computer receives the event data from the server (block <b>90</b>), and preferably displays it to the user immediately or at some point (block <b>92</b>).

0028It is next determined if the requesting computer wishes to continue downloading the log manager file (block <b>94</b>). Since the log manager file <b>20</b> does not technically exit, in practice the log manager file is a way to maintain the connection between the server <b>10</b> and the requesting computer <b>18</b>. As long as the requesting computer <b>18</b> thinks that the downloading of the log manager file <b>20</b> is not complete, the connection remains. As a result, a persistent connection is maintained between the server <b>10</b> and the requesting computer <b>18</b>.

0029If the requesting computer <b>18</b> wishes to continue downloading the log manager file <b>20</b> (block <b>94</b>), the requesting computer waits for more event data from the server <b>10</b> (block <b>96</b>), and loops the process when the server sends more event data to the requesting computer (block <b>88</b>). Because the requesting computer thinks that the log manager file is a very large file and the download is incomplete, the connection terminates only when the users choose to end the connection, meaning the computers themselves cannot automatically end the download process. If a user does choose to discontinue downloading the log manager file (block <b>94</b>), the requesting computer <b>18</b> will terminate the connection to the server <b>10</b> (block <b>98</b>). The server will then close the log manager file (block <b>100</b>), and disconnect from the requesting computer as well (block <b>102</b>).

0030From the foregoing description, it should be understood that an improved method and system for logging event data has been shown and described which have many desirable attributes and advantages. The method and system allow logging all the event data for a server, which is ready for downloading using a persistent connection. As a result, a more flexible and less restrictive method and system is provided, since the server is able to attend to multiple requests and continue logging the event data during the download process. A user will be able to view the event data as they are created.

0031While various embodiments of the present invention have been shown and described, it should be understood that other modifications, substitutions and alternatives are apparent to one of ordinary skill in the art. Such modifications, substitutions and alternatives can be made without departing from the spirit and scope of the invention, which should be determined from the appended claims.

0032Various features of the invention are set forth in the appended claims.