JP2003218900A - Network device control apparatus and method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a function wherein confirmation of existence of a server is performed quickly without returning of data to the server by a client and reply time-out waiting of the server, by confirming existence of common resource formed by the server by the client in order to confirm existence of the server, when communication to the client is impossible by reason that the server is in the course of re-starting or the like in network control software of a client server type. <P>SOLUTION: The network device control equipment is provided with a display means for displaying device information, a device information acquisition setting means for performing acquisition setting of information of a device, a data converting means for converting data which are transmitted and received by the device information acquisition setting means, an inter-process communication means for performing inter-process communication between the client and the server, and a shared resource control means for forming and controlling the shared resource. <P>COPYRIGHT: (C)2003,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a computer network, and more particularly to a network device control apparatus and method including network management software.

[0002]

2. Description of the Related Art As a method for managing a network device, there is a method using SNMP / MIB. (SN
For details of MP / MIB, refer to “Introduction to TCP / IP Network Management Aiming for Practical Management.” T. Rose = Author / Takeshi Nishida = Translated by Toppan Co., Ltd. See the first edition on August 20, 1992).

According to the SNMP network management technology,
The network management system includes at least one network management station (NMS), a number of managed nodes each including an agent, and a network management protocol used by the management station or agents to exchange management information. The user can obtain the data on the network and change the data by communicating with the agent software on the managed node using the network management software on the NMS.

When such network management software is used in a distributed environment, it is generally configured by a server application having an SNMP network management function and a plurality of client applications which are GUI parts activated on each terminal. .

RFC1057 RPC (Remote P) is a standard for inter-process communication between client applications and server applications between different terminals.
The location call) is defined. RP
C is a group of functions that provides a network service prepared on the server side so that the functions therein can be called from a client process of another terminal on the network like the functions in the local machine. The flow of inter-process communication in RPC is as follows. The client calls the RPC function prepared in the server as a service request to the server. at this point,
A data packet containing the function call information is sent to the server, and the client program is interrupted. When the server receives the packet, it dispatches the called function, extracts the function argument, executes the service based on that argument, and returns the result to the client. The client resumes program execution after receiving the result of the function. There are two types of connection forms of a client and a server in RPC, a connection type and a connectionless type.

[0006]

However, in the above-mentioned conventional example, when the client application of the network management software sends data to the server application, the server application cannot communicate with the server application because of the crash of the server application or the restart of the server application. In this case, there is a problem that the client application tries to retransmit data to the server application or reconnects with the server application, and it takes time to recognize that communication with the server application is not possible and the processing of the client application is stopped. is there.

Therefore, an object of the present invention is to provide a network device control apparatus and method that solves the above problems.

[0008]

According to another aspect of the present invention, there is provided a network device control apparatus, a display unit for displaying device information, a device information acquisition setting unit for acquiring and setting device information, and the device information acquisition setting. Data conversion means for converting the data transmitted and received by the means,
By providing an inter-process communication means for performing inter-process communication between the client and the server and a shared resource management means for creating and managing the shared resource, the client application can send data to the server application before the client application sends the data. By confirming the shared resource of the application and the server application, it becomes possible to quickly confirm the existence of the server application.

In the network device control apparatus according to the invention of claim 2, the shared resource management means of the network device control method creates and retrieves a window as a shared resource so that the client application can execute a search for the server application. By confirming the existence of the window owned by the server application before transmitting the data, it becomes possible to quickly confirm the existence of the server application.

In the network device control apparatus according to the invention of claim 3, in the shared resource management means of the network device control method, the search time is also used when searching the shared resource, so that the search time of the shared resource is constant. By searching the shared resource only when the range is exceeded, the number of searches can be reduced and the performance of each API call can be improved.

A computer-readable storage medium according to a fourth aspect of the present invention transmits and receives a display step for displaying device information, a device information acquisition setting step for acquiring and setting device information, and a device information acquisition setting step. Readable by a computer having a program including a data conversion step of converting data to be processed, an interprocess communication step of performing interprocess communication between a client and a server, and a shared resource management step of creating and managing shared resources. It is a storage medium.

A computer-readable storage medium according to a fifth aspect of the present invention has a program characterized in that, in the shared resource management step of the network device control method, a window is created and searched as a shared resource. It is a computer-readable storage medium.

A computer-readable storage medium according to a fifth aspect of the present invention has a program characterized in that, in the shared resource management step of the network device control method, a search time is also used when searching for a shared resource. It is a computer-readable storage medium.

[0014]

BEST MODE FOR CARRYING OUT THE INVENTION The network management apparatus of the present invention is realized on a PC having the same configuration as the PC capable of realizing the conventional network management apparatus as shown in FIG. The hard disk (HD) 211 stores a program of the network management software according to the present application, which is the main subject of the operation in all the following description. In all the explanations below, unless otherwise specified, the main body of execution is the CPU 201 in terms of hardware. On the other hand, the main body of control on software is network management software stored in the hard disk (HD) 211. In this embodiment, the OS is assumed to be, for example, Windows 2000 (manufactured by Microsoft Corporation), but the OS is not limited to this.

The network management program according to the present application is a floppy (registered trademark) disk or CD-ROM.
It may be supplied in the form of being stored in a storage medium such as a hard disk. In that case, the program is read from the storage medium by the floppy disk controller (FD) 212 shown in FIG. (HD) 211 is installed.

In the following description, the process (client application) of the GUI part of the network management software according to the present application will be referred to as "NetSpot GU".
I ”, the process of communicating with the device (server application) is called“ VDC ”.

In FIG. 3, NetSp is displayed on the PC 103.
The ot GUI process and the VDC process are activated on the PC 121 to manage the printer 102 (where the SNMP agent is installed). NetSpo
t GUI uses the function of interprocess communication to VDC
And the VDC uses the SNMP protocol to communicate with the device.

In order to obtain the device configuration information from the device, the NetSpot GUI performs inter-process communication using a proxy and transmits the device configuration information to be acquired to VDC. The VDC receives the information received by the stub and acquires the MIB information from the device by using the SNMP protocol. The acquired information is transmitted from the VDC stub to the proxy using interprocess communication, and the proxy notifies the NetSpot GUI to call back.
The NetSpot GUI displays device configuration information by performing a bitmap display or the like based on the information notified by the proxy from the callback.

In order to set the device configuration information in the device, the NetSpot GUI uses a proxy to perform inter-process communication and sends the device information to be set in VDC. VDC receives the information received by the stub and S
MIB information is set in the device using the NMP protocol. The information indicating whether the setting succeeded or failed is VD.
It is sent from the C stub to the proxy using inter-process communication and the proxy notifies the NetSpot GUI with a callback. The NetSpot GUI displays device configuration information by performing a bitmap display or the like based on the information notified by the proxy from the callback.

FIG. 4 is a screen in which the NetSpot GUI acquires and displays the device status, paper feed unit information and the like as device configuration information.

FIG. 5 is a screen on which the NetSpot GUI displays device job information. NetSpot to get device job information from the device
The GUI uses a proxy for inter-process communication and VD
Send a job acquisition command to C. The VDC receives the job acquisition command received by the stub and receives the job acquisition protocol (for example, Job MI using the SNMP protocol).
B, IPP (Internet Printing P)
the job information from the device. The acquired job information is sent from the VDC stub to the proxy using interprocess communication, and the proxy notifies the NetSpot GUI as a callback. The NetSpot GUI displays a list of jobs based on the job information notified by a callback from the proxy.

Further, in order to display the change in the job status in real time, NetSpot GUI performs inter-process communication by using a proxy and transmits a job event notification request command to VDC. The VDC receives the event notification request command received by the stub, and registers as a notification destination for event notification when an event is received from the device or when the job state changes in the spooler.
When the device or the spooler notifies the job state change event, the VDC transmits the job state change information from the stub to the proxy using interprocess communication to the client registered as the notification destination. The proxy sends the received job status change information to NetS.
Call back notification to the pot GUI, NetSpot
The GUI updates the job status in the list based on the job status change information notified by the callback.

FIG. 6 is a block diagram showing a route through which job information in the spooler is notified when the job data is transmitted to the device. In B1-1, the application sends print data to the spooler process.
In the spooler process, the language monitor receives the print data, and in B1-2, the job name, job ID,
The VDC process is notified of job information such as the job status. Job information notification to the VDC is performed using inter-process communication such as RPC. In B1-3, the language monitor sends the print data to the port monitor. The port monitor sends the print data to the device at B1-4. B
In 1-5, the VDC registers the job information in the spooler as the job status change event notification destination.
Notify the tSpotGUI. NetSpot GUI
Updates the job list information based on the received job information.

Spooler process, VDC process, VDC
In the inter-process communication used in the C process and the NetSpot GUI, V using the flowchart of FIG.
The operation in the case of confirming the existence of DC every time, the operation in the case of confirming the existence of VDC at a constant interval by using the flowchart of FIG. 8, and the operation of the VDC by using the flowchart of FIG. 9 will be described.

In S1-1 of FIG. 7, the language monitor or Ne of the spooler process that is the client is used.
The tSpot GUI makes an API call to the proxy. In S1-2, the fAlive flag indicating whether or not the VDC that is the server exists is confirmed.
If the fAlive flag is FALSE in S1-3, the process returns to S1-10 to set the return value of the function to FALSE. If the fAlive flag is TRUE, S1
The process proceeds to step -4 to confirm the existence of the window owned by the server VDC. Since the OS is inquired to confirm the existence of the window, interprocess communication with the VDC does not occur. Here, the resource for confirming the existence of the server is not limited to the window as long as it is a shared resource between the client and the server. If the existence of the window is not confirmed, a time-consuming process such as waiting for a response and resending is performed in the communication process between the client and the server. For example, if a timeout value of 5 seconds is set for the VDC response wait and the VDC does not exist due to rebooting, the job information of B1-2 in FIG. 6 is retransmitted, and the print data in the spooler process is Not sent to port monitor for 5 seconds. Therefore, the printing performance is greatly affected. By confirming the existence of the server process using the window, it is possible to prevent the data from being transmitted from the client application to the server application when the VDC does not exist, thereby preventing the print performance from being affected. S1-5
If there is no window in step S1-10, the return value of the function is set to FALSE. If the window exists, reset the fAlive flag to TRUE. In S1-7, a marshalling process for packing the argument of the API called by the client so as to be transmitted to the VDC process is performed. In S1-8,
Send the marshalled data to the stub. S1-
At 9, the return value of the function is set to TRUE. S1
At -11, S1 to exit the processing in the proxy
-9 or AP with the return value set in S1-10
Returns I call to client.

In FIG. 8, the operation in the case of confirming the existence of VDC at regular intervals will be described. In S2-1, the language monitor of the spooler process or the NetSpot GUI, which is the client, makes an API call to the proxy. In S2-2, fAlive indicating whether or not the VDC that is the server exists
Check the flag. If the fAlive flag is FALSE in S2-3, the process returns to S2-12 to set the return value of the function to FALSE. fAlive flag is T
In the case of RUE, the process proceeds to S2-4, and it is confirmed whether the update time of fAlive is within the existence confirmation range time. If it is within the existence confirmation range time, the process proceeds to S2-9. If it exceeds the existence confirmation range time, the flow advances to S2-6 to confirm the existence of the window owned by the VDC which is the server. In order to check the existence of the window, the OS is inquired.
No interprocess communication with C occurs. Here, the resource for confirming the existence of the server is not limited to the window as long as it is a shared resource between the client and the server. In S2-7, if there is no window,
Proceed to S2-12, and set the return value of the function to FALSE. If the window exists, the fAlive flag is reset to TRUE and the update time of fAlive is updated. In S2-9, a marshalling process for packing the API argument called by the client so that it can be transmitted to the VDC process is performed. S2
At -10, the marshalled data is sent to the stub. At S2-11, the return value of the function is TRU
Set to E. In S2-13, the API call is returned to the client together with the return value set in S2-11 or S2-12 in order to exit the process in the proxy.

In FIG. 9, VD which is a server process
The operation of C will be described. In S3-1, a window is created. This window is created with a name that the client can recognize so that the client can confirm the existence of the server. Here, the resource for confirming the existence of the server is not limited to the window as long as it is a shared resource between the client and the server. In S3-2, the system waits for the data transmitted from the client.

[0028]

As described above, according to the network device control apparatus and method of the present invention, when the client application of the network management software sends data to the server application, the server application crashes or the server application is restarted. When communication with the server application cannot be performed due to a reason such as middle, there is an effect that the existence of the shared resource owned by the server application can be confirmed to quickly confirm the existence of the server application.

[Brief description of drawings]

FIG. 1 is a network management device of the present invention.

FIG. 2 is a conventional network management device.

FIG. 3 is a relationship diagram between VDC and NetSpot GUI.

FIG. 4 NetSpot GUI (status page).

FIG. 5: NetSpot GUI (Job page).

FIG. 6 is a flow of job information.

[FIG. 7] Operation on the client side: When the existence of the server is confirmed every time.

[FIG. 8] Operation on the client side: When the server existence confirmation time is also used.

FIG. 9 is an operation on the server side.

[Explanation of symbols]

100 Local Area Network (LAN) 101 Network Board (NB) 101a Printed Circuit Board 101b Faceplate 102 Printer with Open Architecture 102a Serial Port 102b Parallel Port 103 Personal Computer (PC) 104 Connected to LAN100 104 Connected to LAN100 Personal computer (PC) 105 Printer 104 connected to PC 104 File server 107 connected to LAN 100 Network disk 108 included in LAN 100 Print server 109a included in LAN 100 Printer 109b connected to print server 108 Print server Printer 110 connected to 108 local area network (LAN) 111 Personal computer (PC) connected to LAN 110 112 Personal computer (PC) connected to LAN 110 113 File server connected to LAN 110 114 Network disk 115 included in LAN 110 Print server included in LAN 110 116 Printer 117 Connected to Print Server 110 Printer 120 Connected to Print Server 110 Local Area Network (LAN) 121 Personal Computer (PC) Connected to LAN 100 122 Personal Computer (PC) Connected to LAN 120 Modulation / Demodulation (MODEM) / Transponder 140 Backbone 150 Printer interface car 151 microprocessor 160 printer engine 170 connector 200 network management software keyboard controller (KB system bus 205 PC 200 of RAM 204 PC 200 of ROM 203 PC 200 of CPU 202 PC 200 to execute a network management program supplied from the PC 201 FD 212 running
C) 206 CRT controller (CRTC) of PC200 207 Disk controller (DKC) of PC200 208 Network interface card (NIC) of PC200 209 Keyboard (KB) of PC200 210 CRT display (CRT) 211 of PC200 211 Hard disk (HD) of PC200 212 Floppy disk drive (FD)

Claims (6)

[Claims] 1. A server / client type network device control device for communicating with a network device, comprising: display means for displaying device information; device information acquisition / setting means for acquiring and setting device information; and device information acquisition. It is characterized by comprising data conversion means for converting the data transmitted and received by the setting means, interprocess communication means for performing interprocess communication between the client and server, and shared resource management means for managing the creation of shared resources. Network device controller. 2. A network device control apparatus, wherein in the shared resource management means of the network device control method, a window is created and searched as a shared resource. 3. The network device control apparatus, wherein the shared resource management means of the network device control method uses a search time together when searching for a shared resource. 4. In a computer-readable storage medium, a display step of displaying device information, a device information acquisition / setting step of acquiring and setting device information, and converting data to be transmitted / received by the device information acquisition / setting step. A network device control apparatus comprising: a data conversion step, an inter-process communication step for performing inter-process communication between a client and a server, and a shared resource management step for performing creation management of shared resources. 5. The network device control apparatus, wherein in the shared resource management step of the network device control method, a window is created and searched as a shared resource. 6. The network device control apparatus, wherein in the shared resource management step of the network device control method, a search time is used together when a shared resource is searched.