JPWO2001025934A1 - Server/Client System - Google Patents

Abstract

(57) [Abstract] This server/client system is a server/client system that connects at least one client having at least one I/O port to one server via a communication line, and is configured such that the server is provided with a device driver for controlling the I/O port and a virtual I/O port that provides an interface to the device driver with the same functions as the I/O port and sends input/output control signals from the device driver to the client side and receives events from the client side and notifies the device driver, and the client side is provided with a device handler connected to the virtual I/O port via the communication line, and the I/O port is controlled by the device handler.

Description

Detailed Description of the Invention

TECHNICAL FIELD The present invention relates to a server/client system, and in particular to a server/client system that reduces the hardware resources on the client side. BACKGROUND ART Figure 1 is a diagram showing a schematic hardware configuration of a conventional server/client system. In the figure, 100 indicates a server and 200 indicates a client equivalent to a personal computer, and the two are connected by a communication line 300. The client 200 also has I/O devices such as a printer, a memory card reader, a barcode reader, etc.
The device 400 is connected via a connection line 500. The server 100 in the conventional server/client system includes a CPU 101.
The client 200 includes a CPU 201, a memory 202, hard disks 103a and 103b, and a line control unit 104. The hard disks in the server are usually duplicated (mirrored) so that if one fails, the other can cover the other.
, a line control unit 204, and an I/O port 205.
It contains various applications, device drivers, and client 2
The operating system (O/S) that controls the operation of the software 206
In conventional server/client systems, as shown in the figure, applications are configured to run on the client side. Therefore, in recent years, the code size of operating systems and applications has grown, and the number of device drivers has increased, leading to a demand for clients with hardware resources with higher processing power and larger storage capacities. However, as hard disks, which are widely used as hardware resources, become larger in capacity, their costs increase and they are prone to malfunction. Therefore, increasing the capacity of hardware resources is undesirable not only in terms of manufacturing costs but also in terms of system operation costs. Therefore, there is a need to reduce the processing burden on the client side and lighten the client weight while effectively utilizing the assets of conventional applications and device drivers. Therefore, by running applications on the server 100 and transferring screen and key input between the client and server, the processing burden on the client 200 can be reduced, thereby reducing the hardware weight. Since I/O devices are typically connected close to the user, i.e., to the client, the device drivers are located on the client side. In this way, when applications are located on the server side and device drivers are run on the client side, the following problems arise with I/O device control. (1) Client device drivers often depend on the OS, which has a large code size. Therefore, if the device driver is placed on the client side, the processing load on the client increases, and a storage device is required for the OS required to run the device driver. (2) Since the interface changes between the application placed on the server side and the device driver placed on the client side, it becomes necessary to rewrite the device driver. (3) When there are multiple types of I/O devices, each device driver also needs to be
The need to recreate the device driver arises due to reason (2) above. (4) The version number of the device driver can only be confirmed at the location where the client is installed. (5) Diagnosis of the client I/O device can only be performed at the location where the client is installed. (6) The need to recreate the device driver arises every time the client platform changes. As described above, when the application runs on the server side and the device driver runs on the client side, it becomes difficult to reduce the client's weight and to effectively utilize existing assets such as applications and device drivers, particularly for reasons (1), (2), and (3) above. Furthermore, as shown in (4), (5), and (6) above, it is difficult to operate the system efficiently. Disclosure of the Invention The present invention has been made in consideration of the above problems, and provides a solution to the above problems by providing ...
The main object of the present invention is to provide a server/client system that can effectively utilize assets such as device drivers and can significantly reduce the hardware resources on the client side. According to one embodiment of the present invention that achieves the above object, in a server/client system in which at least one client having at least one I/O port is connected to one server via a communication line, the server side is provided with a
a device driver for controlling the I/O port; and a virtual I/O port for providing the device driver with an interface having the same functions as the I/O port and transmitting input/output control signals from the device driver to the client side and receiving events from the client side and notifying the device driver of the events; and a device handler connected to the virtual I/O port via the communication line is provided on the client side, and the device handler controls the I/O port.
The server/client system is characterized by a configuration in which the device driver and the virtual I/O are controlled.
The virtual I/O port realizes an interface on the server side that is the same as the interface between device drivers and I/O ports in a conventional server/client system, allowing all applications and device drivers used on the conventional client side to run on the server side. This significantly reduces the hardware resources on the client side, and allows the existing application and device driver assets to be used on the server side without modification. Furthermore, in a server/client system with the above configuration, by providing the virtual I/O port with the ability to identify the client's address on the communication line and each I/O port, it becomes possible to centrally manage multiple lightweight clients with a single server. Furthermore, by adding a client-side hardware diagnostic function to the virtual I/O port, it becomes possible for a server managing multiple clients to centrally diagnose the hardware of each client. Best Mode for Carrying Out the Invention FIG. 2 is a block diagram showing the hardware configuration of a server/client system according to one embodiment of the present invention. As shown in the figure, the server 1 of this embodiment includes a C
The client 2 is comprised of a PU 11, a memory 12, storage devices such as hard disks 13a and 13b, and a line control unit 14. The dual-structured hard disks 13a and 13b contain various applications, device drivers, and virtual I/O ports and an O/S (described later) that were previously installed on the client side as software 15. The client 2 is comprised of a CPU 21, storage devices such as a memory 22 and a ROM 23,
The system is composed of a line control unit 24 and an I/O port 25. In this system, the applications and device drivers are placed on the server side and run on the server side, so the ROM 23 stores software 26, which is software for converting signals sent from the device driver on the server side via the communication line 3 into signals that can be input to the I/O port 25, i.e., a device handler, and an embedded OS for controlling the entire client 2.
The detailed function of the device handler will be described later. In the client 2 of this embodiment, there is no need to run an application within the client, so the code size of the entire software, including the device handler and O/S, is much smaller than that of the conventional system, and as mentioned above, the ROM 2
3, which eliminates the need for a hard disk in the client. In a typical server/client system, the main cause of failure on the client side is the hard disk, so the system of the present invention does not require a hard disk, thereby greatly improving the reliability of the system. The communication line 3 can be, for example, a LAN (Local Area Network
3 is a diagram showing the software configuration of the server/client system shown in FIG. 2. In the system of this embodiment, various applications 1 are installed in the server 1.
6, a device driver 17 for driving various I/O devices 4, a virtual I/O port 18 for converting signals from the device driver 17 into signals that can be transmitted over the communication line 3, and converting signals input via the communication line 3 into signals that can be input to the device driver 17, and an OS 1 for controlling these software.
The O/S 19 is the same as the O/S used when these software programs are installed in the client 2, for example, Windows 98 (trademark),
Existing operating systems such as Windows NT (trademark) can be used.
Of course, applications and device drivers that are used in existing systems can also be used. The client 2 includes a device handler 27 that converts signals input via the communication line 3 into signals that can be recognized by the I/O port 25, and converts signals from the I/O port 25 into signals that can be transmitted over the communication line 3. In the present invention, the client 2 does not include applications and device drivers that have large code sizes, but only includes the device handler 27, which has a small code size as software, and the O/S 28 that controls this is an embedded O/S with an extremely simple configuration.
The virtual I/O port 18 in the server 1 basically has the following functions: (1) to provide an interface that functions the same as the I/O port 25 on the client 2 side to the upper device driver 17; and (2) to send input/output control signals from the upper device driver 17 to the device handler 27 of the client 2, and to receive events from the device handler 27 and notify the upper device driver 17. The minimum required functions of the device handler 27 on the client 2 side are: (1) to receive input/output control signals sent from the virtual I/O port 18 of the server 1, to perform input control/output control on the I/O port, and to send events from the I/O port 25 to the virtual I/O port 18 of the server 1. In the server/client system of this embodiment, by providing a virtual I/O port on the server side and a device handler on the client 2 side as described above,
Conventional applications and device drivers can be run on the server side without modification, significantly reducing the hardware resources of the client. The detailed configuration and operation of this system will be explained below with reference to Figure 4, which shows the data flow between the application 16 in the server 1 and the I/O device 4. First, data input/output from the application 16 to the I/O device 4 is as follows: (1) The application 16 issues an I/O processing request, including the data to be input/output, to the device driver 17, (2) The device driver 17 responds to the I/O processing request and sends the data to the virtual I/O port 1.
(3) The virtual I/O port 18 converts the I/O control into data on the communication line 3 and sends it to the device handler 27 on the client 2 side as an I/O control packet. (4) When the device handler 27 receives the I/O control packet, it interprets the contents and performs I/O control of the I/O port 25. (5) The I/O port 25 converts the I/O control into data on the connection line 5,
The event is sent to the external I/O device 4 and controlled. In this way, input/output control is performed from the application to the I/O device 4. Next, the notification of an event from the I/O device 4 to the application 16 will be explained. First, (6) the I/O device 4 outputs an event (such as a change in a control signal line) onto the connection line 5. (7) The device handler 27 converts the event from the I/O port 25 into data on the communication line and sends it to the virtual I/O port 18 as an event packet. (8) When the virtual I/O port 18 receives the event packet, it interprets the contents and sends the event to the device driver 17. (9) The device driver 17 notifies the application 16 of the event [
10]. The above is the data flow between the application 16 and the I/O device 4 in the server/client system of this embodiment. Next, the operation sequence of the server/client system according to this embodiment will be described with reference to FIG. 5. When the server 1 and client 2 are powered on, first, a connection is established between the virtual I/O port 18 and the device handler 27. This connection is established through negotiation between the two. That is, when the client 2 is powered on, the device handler 27 sends a connection request [11] (broadcast) to the virtual I/O port 18 to request establishment of a connection on the communication line. If the server 1 is powered on and the virtual I/O port 18 is active, a response [12] to this is output from the virtual I/O port 18 to the device handler 27. The response [12] includes the address of the client 2 on the communication line, which is preset by the setting function of the virtual I/O port 18, the type of physical I/O port that the client 2 has, and number mapping information. When the device handler 27 receives this response [12], it establishes a connection on the communication line, maps the physical I/O port according to the mapping information, and when this is complete, it sends a mapping completion notification [13] to the virtual I/O port 18. When the virtual I/O port 18 receives this notification [13], it sends a response [14] to it. At this point, the virtual I/O port 18 is able to accept control from the device driver 17. Note that if a control signal is sent from the device driver 17 before this point, the virtual I/O port 18 returns an error signal to the device driver 17. Next, the sequence for data input/output from the application 16 to the I/O device 4 will be explained. Note that the data flow in this case is as shown in Figure 4. First, the input/output request [15] of the application 16 is sent to the device driver 17.
The device driver 17 sends the input/output control
The virtual I/O port 18 converts the input/output control [16] into data for communication lines and transmits it to the device handler 27 as an input/output control packet [17]. When the device handler 27 receives the input/output control packet [17],
The contents are interpreted and input/output control [18] of the I/O port 25 is performed.
The I/O device 4 outputs data [19] onto the connection line 5. Next, the notification of an event from the I/O device 4 to the application 16 will be described. When the I/O device 4 outputs an event (such as a change in a control signal) [20] onto the connection line, the device handler 27 converts the event [21] from the I/O port 25 into data on the communication line and sends an event packet [22] to the virtual I/O port 18.
]. When the virtual I/O port 18 receives the event packet [22], it interprets the contents and sends an event [23] to the device driver 17. The device driver 17 sends an event [24] to the application 16. FIG. 6 is a flowchart showing the functions of the virtual I/O port 18. Note that this flowchart shows only the minimum necessary functions of the virtual I/O port 18. The following internal states of the virtual I/O port 18 are assumed: (1) Waiting: A state in which the virtual I/O port 18 is waiting to receive a connection request from the client 2; (2) Waiting for completion notification: A state in which the virtual I/O port 18 is waiting for a mapping completion notification of the physical I/O port of client 2; and (3) Connected: A state in which the virtual I/O port 18 is able to accept control from the device driver 17 after receiving a mapping completion notification of the physical I/O port of client 2. The following events are assumed for each of the above states of the virtual I/O port. That is, (4) Connection request reception: an event of receiving a connection request from the client 2, (5) Completion notification reception: an event of receiving a notification of completion of mapping of the physical I/O port of the client 2, (6) Input/output control request: an event of an input/output control request from the device driver 17, and (7) Event packet reception: an event of receiving an event packet from the client 2. The function of the virtual I/O port 18 will be explained below with reference to the above states and events. In Fig. 6, an initialization process is performed in step S1, and the state of the virtual I/O port 18 is set to a standby state. Next, an event is acquired in step S2. At this time,
If the virtual I/O port 18 is in a standby state (Yes in step S3), it is then determined in step S4 whether the event is a connection request reception. If the event is a connection request reception (Yes in step S4), a response is sent to the device handler 27 in step S5, and the state is set to a completion notification waiting state in step S6. If the event is not a connection request reception (No in step S4), it is determined in step S7 whether the next input event is a termination request. If it is a termination request (Yes), the operation of the virtual I/O port 18 is terminated. On the other hand, if it is not a termination request, the process returns to step S2, where an event is acquired again, and subsequent steps are executed. If the state is not a standby state in step S3 (No), it is determined in step S8 whether the state is a completion notification waiting state. If it is a completion notification waiting state (Yes in step S8), it is determined in step S9 whether the event is a completion notification reception state. If it is a completion notification reception state (Yes in step S), a response is sent to the device handler 27 in step S10, and the state transitions to a connected state (step S11).
If the event is not a completion notification reception in step S9 (No), the process returns to step S2 to acquire the event again, except when the event is a termination request. If the state is not a completion notification waiting state in step S8 (No in step S8),
In step S12, it is determined whether the state of the virtual I/O port 18 is connected. If it is connected (Yes in step S12), it is determined in step S13 whether the event is an I/O control request. If Yes, an I/O control packet is sent to the device handler 27 in step S14. If the event is not an I/O control request in step S13 (No in step S13), it is determined in step S15 whether the event is an event packet reception. If Yes, the received packet is sent to the device driver 17. If it is not an event packet reception in step S15 (No), it is determined in step S7 whether there is an event termination request. If Yes, the process ends. If No, the process proceeds to step S2 and continues. FIG. 7 is a flowchart showing the functions of the device handler 27. Note that this flowchart shows only the minimum necessary functions of the device handler 27. The internal states of the device handler 27 are assumed to be (1) to (3) below.
(1) Standby: the state immediately after the startup of the client 2; (2) Waiting for a connection request response: the state of waiting for a response from the server after sending a connection request; (3) Connected: the state in which an I/O control packet can be received from the virtual I/O port 18 after sending a notification of completion of mapping of the physical I/O port. Furthermore, events (4) to (7) are assumed for each state of the device handler 27. (4) No event: the absence of any event; (5) Received connection request response: the event of receiving a response from the server after sending a connection request; (6) Received I/O control packet: the event of receiving an I/O control packet from the server; and (7) I/O port event: the event from the I/O port 25. Next, the processing procedure of the device handler 27 will be described with reference to FIG. 7 . First, in step S20, initialization processing is performed to set the state to standby, and an event is acquired in step S21. Next, in step S22, it is determined whether the event state is standby. If the result is Yes, it is confirmed in step S23 that there is no event. If there is no event (Yes in step S23), the virtual I/O of the server 1
A connection request is sent to the port 18 (step S24), and the state is set to waiting for a response to the connection request (step S25). Next, it is determined whether the event is an end request (step S26). If it is not an end request, the process returns to step S21 and the subsequent steps are executed again. If it is determined in step S22 that the state of the device handler 27 is not in standby (
If the answer is No in step S22, it is determined in step S27 whether the state is waiting for a connection request response. If the answer is Yes, it is determined in step S28 whether the event is reception of a connection request response. If the answer is Yes, a physical I/O port mapping completion notification is sent to the virtual I/O port 18, and the state of the device handler 27 is set to connected (S30). On the other hand, if the state of the device handler 27 is not waiting for a connection request response (No) in step S27, it is determined in step S31 whether the state is connected. If the answer is Yes, it is determined in step S32 whether the event is reception of an input/output control packet. If the answer is Yes, input/output control is performed on the I/O port 25 in step S33. If the event is not reception of an input/output control packet in step S32,
In step S34, it is determined whether the event is an I/O port event, and if the result is Yes, in step S35, this event packet is sent to the virtual I/O port.
In step S26, it is determined whether the event is an end request, and if Yes, the process is terminated, and if No, the process returns to step S21 and the subsequent steps are executed again. As described above, in the server/client system according to the first embodiment of the present invention, a virtual I/O port 18 is provided on the server side, and a device handler 27 is provided on the client side, and processing from a device driver which is an upper layer of the virtual I/O port 18 is transferred to the device handler 27, and the device handler controls the I/O port 25, and events from the I/O port 25 are transferred to the virtual I/O port 18.
8, applications and device drivers that have conventionally run on the client side can be run on the server 1 side without any changes. This significantly reduces the processing load on the client 2 side, and eliminates the need for a large-capacity storage device such as a hard disk on the client side. Note that the server/client system of this embodiment shown in Figures 2 and 3 employs an interface used in conventional server/client systems that have device drivers on the client side as the interface between the virtual I/O port 18 and device driver 17. Figure 8a shows the interface between the device driver 210 and I/O port 210 in a conventional system.
8A shows the interface configuration between the I/O port 205 (hardware) and the device driver 210. As shown in the figure, an I/O port device driver 211 exists between the device driver 210 and the I/O port 205. To absorb differences in hardware, the operations performed by the device driver 210 on the I/O port 205 are expressed as abstracted commands 30. The I/O port device driver 211 controls the I/O port 205 (hardware) using these commands 30, receives control results 32 from the I/O port 205, and returns processing results 33 to the device driver 210. In the server/client system of this embodiment shown in FIGS. 2 and 3, as shown in FIG. 8B, the virtual I/O port 18 provides the interface of the commands 30 and processing results 33 shown in FIG. 8A to the device driver 17 as is. This makes it possible to provide the API (application interface) environment provided to the device driver 210 by the OS in conventional systems to the device driver 17 in the OS of this embodiment as well. As a result, in this embodiment, the device driver 100 is the same as the conventional device driver 210.
7 to control the I/O device 4. As described above, in the server/client system of this embodiment, conventional device drivers can be used as they are on the server side without modification, making it possible to effectively utilize existing assets. FIG. 9 is a block diagram showing the configuration of a second embodiment of the present invention. In this embodiment, as shown in the figure, two clients 2a and 2b, which have been made lighter in accordance with the present invention, are connected to one server 1. It goes without saying that the number of clients connected to one server is not limited to the example shown in the figure, and any number of clients can be connected. In the embodiment shown, client 2a uses device handler 27a and I/O
The client 2b has a device handler 27b and two I/O ports 1 and 2, which are connected to the I/O device 4b and the I/O device 4c, respectively. In the server 1, the application 16a contains an application (1) used by the client 2a and an application (2) used by the client 2b.
The device driver 17a includes the I
/O device driver (1) for driving device 4a, client 2b
a device driver (2) for driving an I/O device 4b connected to
In this embodiment, the virtual I/O port 18a includes a device driver (3) for driving the I/O device 4c. In this embodiment, the virtual I/O port 18a is connected to the clients 2a and 2b and the I/O ports 25a and 25b connected to the server 1 via the communication line 3.
, 25c, the system has a function of being able to set the virtual I/O port number of the virtual I/O port 18a, the addresses on the communication line of each client 2a, 2b, the type of physical I/O port each client has, and the physical I/O port number. Figure 10 shows the setting information in the system of Figure 9. This setting information is also included in the response [12] in Figure 5. According to the setting information shown in Figure 10, client (1) 2a is specified by address 1 on the communication line, and client (2) 2b is specified by address 2. The I/O port 25a in client (1) 2a has a physical I/O port type of COM
In this case, the physical I/O port number is specified as 1. Two I/O ports 25b and 25c in client (2) 2b are specified as physical I/O port numbers 1 and 2. The mapping information allows one-to-one correspondence between the type and number of the physical I/O port possessed by the client and the number set as the virtual I/O port number. For example,
In the example of FIG. 10, the physical I/O port type of the client (1) 2a is CO
M1 corresponds to virtual I/O port number 1. Furthermore, COM1 in client (2) 2b corresponds to virtual I/O port number 2, COM2 corresponds to virtual I/O port number 3,
9, when the power is turned on to the client (1) 2a, the device handler 27a is started and a connection is established between address 0 (server 1) and address 1 (client 2a) on the communication line and the virtual I/O port 18a. Subsequent data transfer between the virtual I/O port 18a and the device handler 27a is carried out over this connection. Processing from the device driver 17a to the I/O device 4a is accepted on the virtual I/O port 18a as processing for the I/O port 25a, and COM1 indicating the I/O port 25a is added to the processing message before being transferred to the device handler 27a. In the device handler 27a,
The I/O port 25a is identified from the information COM1 attached to the processing message, and processing is performed for this. On the other hand, the device handler 27a
, 1 is added to the processing message and the message is sent as a packet to the virtual I/O port 18a. Therefore, the virtual I/O port number 1 is recognized in the virtual I/O port 18a.
The occurrence of the event is notified to the device driver (1) corresponding to virtual I/O port number 1. For client 2b, the same processing is performed on the connection between address 0 and address 2 on the communication line. That is, the virtual I/O port 18a and the I/O
Between the virtual I/O port 18a and the I/O port 25b, the virtual I/O port number 2 and COM1 correspond one-to-one. Between the virtual I/O port 18a and the I/O port 25c, the virtual I/O port number 3 and COM1 correspond one-to-one.
M2 correspond one-to-one to the virtual I/O port number 18. Therefore, the processing message exchanged on the connection between address 0 and address 2 is accompanied by information indicating virtual I/O port number 2, COM1, or virtual I/O port number 3, COM2, thereby identifying I/O port 25b or I/O port 25c. In the server/client system of this embodiment, a single server can centrally manage multiple clients having multiple I/O ports as described above. In this case, the device drivers for multiple types of I/O devices connected to multiple clients can all be run on the server side without changing the device drivers in conventional systems, so the version numbers of all device drivers can be confirmed and managed on the server side. In the server/client system of FIG. 9, virtual I/O port 18
By adding a diagnostic instruction function and a result display function to the virtual I/O port 18a, the diagnosis of all clients can be executed centrally on the server side. That is, when a diagnosis is started by a user, the virtual I/O port 18a sends a diagnostic command to a specified client, for example, the client (1) 2a, and causes the device handler 27a in the client 2a to examine the I/O port 25a, the I/O device 4a, and the client hardware. The results of the diagnosis are displayed on the virtual I/O port 18a.
a and displayed as a diagnostic result. Fig. 11 is a diagram showing an example of a diagnostic menu used in this diagnostic function. As described above, this system has a setting function for specifying each I/O port of each client in the virtual I/O port 18a. Therefore, when a virtual I/O port user starts diagnosing this system, the specified I/O device, I/O
First, the virtual I/O port 18a is diagnosed as follows:
A diagnostic command is sent to a specified client, for example, client 2a, and upon receiving the sent command, the device handler 27a immediately returns a response to the virtual I/O port 18a. Therefore, if the virtual I/O port 18a does not receive this response, it means that the power to client 2a has been cut off or there is some kind of abnormality in the communication line or client 2a. This abnormality is displayed on the server 1 side, for example, on a display. When the device handler 27a receives the diagnostic command, the device handler 27
The virtual I/O port 18a interprets the contents of the diagnostic data and, for example, when diagnosing the I/O device 4a, performs the diagnostics supported by the I/O device 4a and sends the results to the virtual I/O port 18a. For example, if the I/O port 27a is a serial port, it performs an internal loopback diagnostic and sends the results to the virtual I/O port 18a. When the virtual I/O port 18a receives the diagnostic results, it displays them, for example, on a display on the server side. The above diagnostic process allows the virtual I/O port 18a to individually identify each client and each I/O port, enabling the server side to centrally perform diagnostics for all clients. In the embodiment shown in FIG. 9, if the platform (hardware, operating system, etc.) of each client is changed, each client's device handler must be newly created. However, there is no need to change the procedure for establishing a connection between the virtual I/O port 18a and the communication line 3, the method for receiving processing messages from the virtual I/O port 18a, the format of the processing result message including the I/O port number and type to the virtual I/O port 18a, or the format of the event message. Furthermore, even in a system having the above-mentioned diagnostic function, there is no need to change the method of receiving diagnostic commands, the message format of the response, or the message format of the diagnostic results. Therefore, even if the platform of each client is changed, there is no need to change the server side, so it is possible to flexibly deal with changes in the client side platform. Effects of the Invention As explained above, according to the present invention, it is possible to move applications and device drivers used on the client side in a conventional server/client system to the server without changing them. Therefore, the processing load on the client side is reduced, and as a result, hardware resources are significantly lightened. Therefore,
A server/server with a lightweight client while maintaining the traditional API environment
This makes it possible to build a client system that can handle multiple clients simultaneously. Furthermore, even if the client platform is changed, no changes are required on the server side, so changes to the platform can be flexibly accommodated. When the server/client system of the present invention as described above is applied to a POS system in which one server controls several clients, each client is significantly lighter, resulting in significant savings not only in the cost of building the entire system but also in the cost of operating the system. Furthermore, because changes to each platform can be flexibly accommodated, the cost burden when changing the design of the POS system can be significantly reduced.

BRIEF DESCRIPTION OF THE DRAWINGS The above and other objects, features, advantages, etc. of the present invention will be described in detail below with reference to the accompanying drawings showing embodiments of the present invention. In the drawings, in which: FIG. 1 is a block diagram showing the configuration of a conventional server/client system; FIG. 2 is a block diagram showing the hardware configuration of a server/client system according to a first embodiment of the present invention; FIG. 3 is a block diagram showing the software configuration of the server/client system shown in FIG. 2; FIG. 4 is a diagram for explaining the data flow between applications and I/O devices in the server/client systems shown in FIGS. 2 and 3; FIG. 5 is a diagram showing an operation sequence in the server/client systems shown in FIGS. 2 and 3;
7 is a flowchart for explaining the function of a device handler included in the server/client system shown in FIGS. 2 and 3; FIG. 8a is a diagram showing the interface between a device driver and an I/O port in a conventional server/client system; FIG. 8b is a diagram showing the interface between a device driver and a virtual I/O port in the server/client system of the present invention shown in FIGS. 2 and 3; FIG. 9 is a block diagram showing the configuration of a server/client system according to a second embodiment of the present invention; FIG. 10 is a diagram for explaining the function of a virtual I/O port included in the server/client system shown in FIG. 9; and FIG. 11 is a diagram for explaining other functions of the virtual I/O port included in the server/client system shown in FIG. 9.

───────────────────────────────────────────────────── (Note) This publication is based on the publication published internationally by the International Bureau of Patents (WIPO). The effect of the international publication of the Japanese patent application (Japanese utility model registration application) related to this publication arises pursuant to Article 184-10, Paragraph 1 of the Patent Act (Article 48-13, Paragraph 2 of the Utility Model Act) and is unrelated to this publication.

Claims (12)

[Claims] [Claim 1] A server/client system in which at least one client having at least one I/O port is connected to one server via a communication line, wherein the server is provided with a device driver for controlling the I/O port, and a virtual I/O port that provides the device driver with an interface having the same functions as the I/O port and transmits input/output control signals from the device driver to the client side and receives events from the client side and notifies the device driver of the events, and the client is provided with a device handler connected to the virtual I/O port via the communication line, and the I/O port is controlled by the device handler. 2. The device handler receives an input/output control signal transmitted from the virtual I/O port, performs input/output control for the I/O port based on the control signal, and transmits input/output control to the I/O port connected to the client via the I/O port.
2. The server/client system according to claim 1, wherein an event from a device is received via said I/O port and transmitted to said virtual I/O port. 3. The server/client system according to claim 1, wherein said virtual I/O port transmits input/output control from said device driver to said device handler via said communication line as an input/output control packet. 4. The device handler receives an I/O command via the I/O port.
The port event is transmitted as an event packet to the virtual I/O port via the communication line.
4. The server/client system according to claim 1, wherein the client/server device transmits data to a port. 5. The method according to claim 1, wherein the server includes an existing application used in a conventional server/client system.
Item 1. A server/client system according to item 1. 6. The server/client system according to claim 1, wherein the server includes an existing device driver that has been used in a conventional server/client system. [Claim 7] A server/client system as described in any one of claims 1 to 6, characterized in that the virtual I/O port has the function of identifying the address on the client's communication line and the type and number of the I/O port. 8. The server/server system according to claim 1, wherein the virtual I/O port has a function of diagnosing the hardware of the client.
Client system. 9. The server/client system according to claim 1, wherein the communication line is a LAN. [Claim 10] A server/client system as described in any one of claims 1 to 9, comprising one server and m (m is an integer greater than or equal to 2) clients, each having at least one I/O port, and wherein all applications used by each of the clients and all device drivers controlling each of the I/O ports are located on the server side. [Claim 11] A server having at least one CPU, a memory device, a line control unit, and an operating system that controls these, characterized in that it further incorporates, as software, an application, a device driver, and a virtual I/O port that provides the device driver with the same functions as an I/O port. [Claim 12] A client having at least one CPU, a memory device, a line control unit, an I/O port for controlling an external I/O device, and an operating system for controlling these, characterized in that a device handler for controlling the I/O port is further incorporated as software.