JP5470518B2 - Device sharing system, device sharing client, and device sharing method - Google Patents

Description

The present invention relates to a system having a function of sharing a device via a network, a client, and a control method thereof.

With the widespread use of networks, device servers that have been devised so that devices (peripheral devices) that are conventionally connected locally to personal computers (PCs) and the like can be used from client PCs on the network have been announced.

Among them, several implementation methods for making a storage device usable as a shared storage from a client PC on a network via a device server have been proposed.

As one implementation method, there is a method in which an operating system (hereinafter referred to as an OS) of a client PC is recognized as a storage connected to a network.

In this method, the device server is provided with a mechanism for exclusive control and session management using the SMB (Server Message Block) protocol, thereby enabling file access to a single storage from a plurality of client PCs.

However, since it is necessary to implement the SMB protocol on the device server, the processing load on the device server side becomes high, a high-speed CPU (Central Processing Unit) and a large-capacity memory are required, and the device server becomes expensive. There's a problem.

As another realization method, there is a method of virtually recognizing the OS of the client PC as a locally connected storage.

In this method, dedicated application software (utility) is installed in the client PC, and when the user tries to access the storage, the utility is operated to virtually recognize the client PC as locally connected storage. As a result, the file can be accessed from the client PC on the network in the same manner as in the locally connected state.

FIG. 14 is a flowchart showing a basic operation when a user operates a utility installed in a client PC to start / disconnect a session connection with the storage.

First, when the storage is used, since the client PC and the storage are not connected, the utility of the client PC is activated. When the utility is activated, it enters a state of waiting for the start of storage use by a user operation (step S1401).

When the user operates the utility of the client PC and executes the storage connection operation, a session start request is sent from the client PC to the device server (step S1402).

When a session is started with the device server (Yes in step S1403), the storage can be accessed (steps S1404 and S1405), and unless a storage disconnection operation is performed by the user (No in step S1406), The storage is repeatedly accessed.

On the other hand, if the session cannot be started with the device server (No in step S1403), the storage cannot be accessed (step S1410).

When the access to the storage is completed, the user operates the utility of the client PC to execute the storage disconnection operation.

When the disconnection operation for the storage is executed (Yes in step 1406), a session termination request is sent from the client PC to the device server (step S1407), the session with the device server is disconnected, and the storage is accessed. Is completed (steps S1408 and S1409).

FIG. 15 is a timing chart showing a process when a plurality of client PCs (PC1, PC2) operating based on the flowchart of FIG. 14 access the storage.

First, when starting access to the storage by the PC 1, the user performs a session start operation using the utility of the PC 1.

When a session start operation is performed, the PC 1 sends a session start request to the device server. When the session is started, the PC 1 can access the storage via the device server.

Subsequently, when a control command is sent from the PC 1 to the device server to access the storage, data can be read from and written to the storage via the device server.

During the session connection between the PC 1 and the device server, the session is exclusively used by the PC 1, and therefore the storage cannot be accessed from the PC 2.

When the access by the PC 1 is completed, the user operates the utility of the PC 1 to execute a session disconnecting operation.

When a session disconnection operation is executed, a session end request is sent from the PC 1 to the device server, a session disconnection process is performed with the device server, and access to the storage ends.

Here, when the user performs a session start operation using the utility of the PC 2, access to the storage from the PC 2 is started.

In this way, storage can be shared from a plurality of client PCs by starting / disconnecting a session using a utility.

However, this method requires the user to start and disconnect the session, and the session is maintained while the client PC is not reading or writing data to the storage (while it is not actually accessing). Unless the client disconnects the session, another client PC cannot use the storage.

In order to solve such a problem, only when block data having a data length specified by the block header is transmitted, the data transmission between the client PC and the storage is permitted as a data transmission exclusive state by the specific client PC. A network file management system using a device server is disclosed. (See Patent Document 1)

JP 2007-317067 A

However, in the network file management system disclosed in Patent Document 1, storage can be shared from a plurality of client PCs without causing a useless blank time in which the storage is not used, but access from a plurality of client PCs is possible. There is a problem that the traffic volume increases as requests constantly move on the network.

In addition, since the device server is required to have a high processing performance in order to process a large number of access requests and to control the setting / release of the data transmission exclusive state for a specific client PC, it is realized using the SMB protocol described above. As with the method to do this, it is inevitable that the device server will be expensive.

In view of the above problems, the present invention reduces the processing load on the server side when a device (peripheral device) such as a storage is shared by a client PC on a network, and is necessary without forcing the user to perform a manual operation. It is an object to provide a means for controlling to access a device only when.

In order to achieve the above object, the client according to claim 1 is a client that inputs and outputs data with a device connected to a server via a network,
An upper layer that instructs access to the device, the control command generation means for the device to generate a first control command for confirming whether available in accordance with an instruction from the upper layer, the control command generation a session start request means for sending a session start request to the server and the first control command is generated by means, a session start means for starting the server and a session based on the response to the session start request, the during connection server session, said first control command regularly sends to the server, and the session connection status confirmation means for confirming the presence or absence of a session start request from the connected state and other clients of the session, the pseudo Predetermined conditions for transitioning to the connection state depend on the presence / absence of the session start request. A predetermined condition changing means for changing Te, response to the first control command received from the server when the predetermined condition is satisfied, the session disconnection means for cutting the session, after cleavage of the session, the control command generation instead of sending the first control commands generated by means to the server, that by pseudo generate a response to the first control command is constituted by a pseudo response means for notifying the upper layer It is characterized by.

In order to achieve the above object, a device sharing method according to claim 6 is a device sharing method in which a device connected to a server via a network is shared by a client , wherein a control command generation unit is configured to send the device to the device. A control command generating step for generating a first control command for confirming whether or not the device can be used in response to an instruction from an upper layer instructing access; and a session start requesting means, wherein the control command generating step includes: A session start request step for sending a session start request to the server when the first control command is generated, and a session start step for the session start means to start a session with the server based on a response to the session start request; , session connection status confirmation means, said support During bus and session connection, wherein the first control command regularly sends to the server, and the session connection status confirmation step of confirming whether the session start request from the connected state and other clients of the session, a predetermined A condition changing means for changing a predetermined condition for shifting to the pseudo-connection state according to the presence or absence of the session start request; and a session connection means for the first control command received from the server. when the response is said predetermined condition is satisfied, the session disconnection step of cutting the session, the pseudo response means, after cleavage of the session, the generated by the control command generating step the first control commands to the server Te without sending, by a response to the first control command to the pseudo generate, the And executes a pseudo response notifying the position layer.

According to the present invention, a client PC recognizes a device connected to a device server on the network as a locally connected device, and connects a session between the client PC and the device server only when accessing the device. can do.

This eliminates the need to incorporate the processing function disclosed in the SMB protocol and Patent Document 1 into the device server when sharing the device on the network, so that the load on the device server is reduced, and a plurality of network systems can be configured with an inexpensive network system configuration. It becomes possible to share the device from the client PC.

In addition, by making the client PC recognize that the device is always connected, it is not necessary to start and disconnect the session that was manually operated by the utility of the client PC, and the device is in a network environment. It becomes possible to use without being aware of this.

Hereinafter, a first embodiment of the present invention will be described in detail with reference to the drawings.

FIG. 1 shows a schematic configuration of a network system for realizing the present invention, which includes a PC 100A, a PC 100B, a device server 200, and a storage 300.

In this network system, the device server 200 and the storage 300 are connected by a connection cable 400 conforming to an interface such as USB (Universal Serial Bus) or IEEE1394. The device server 200 and the PC 100 (PC 100A, PC 100B) are connected by a wired or wireless network 500.

In the network system of FIG. 1, the device server 200 and the storage 300 are configured as separate devices. However, the present invention is not limited to this configuration, and various configurations are possible as long as an equivalent function can be realized. Of course, the configuration can be adopted. For example, the device server 200 may be integrated so as to fit in the casing of the storage 300.

In the following description, the client PC operating system (hereinafter referred to as OS) is Windows (registered trademark), the device is a storage, and the connection interface between the device server and the device is USB. However, the present invention is not limited to these, and another OS or connection interface may be used.

Next, each device constituting the network system of FIG. 1 will be described sequentially.

First, the client PC 100 will be described. The PC 100 (PC 100A, PC 100B) is, for example, a device such as a personal computer, and is configured to be connected to the network 500 and use the storage 300 via the device server 200.

FIG. 2 is a block diagram illustrating an example of a hardware configuration and a software configuration of the PC 100 (PC 100A, PC 100B).

The PC 100 includes a CPU 101, an input unit 102, a display unit 103, a memory 104, a communication unit 105, an external storage unit 106, and the like, which are connected by an internal bus 107.

The external storage unit 106 stores various software such as an OS 110, an application program 111, and software groups 112 to 116 (described later) for realizing the present invention. Here, the application program 111 refers to a software program that causes access to the storage 300, such as file management software.

The software stored in the external storage unit 106 is read out and executed on the memory 104 under the control of the CPU 101.

The communication unit 105 is an interface for connecting to the network 500 (wired or wireless network). By performing data communication with the device server 200, the PC 100 can access the storage 300 via the device server 200. Make it possible.

The software groups 112 to 116 for realizing the present invention will be described.

The SCSI command layer 112 is driver software (for example, disk.sys) used when accessing the storage 300.

When access to the storage 300 occurs in the PC 100 according to an instruction from the upper layer (the OS 110 and the application program 111), a SCSI command that is a control command is generated, sent to the filter driver layer 113, and a response to the SCSI command Wait for information. In the following description, the control command is described as a SCSI command, but is not limited to the SCSI command.

The filter driver layer 113 is software that analyzes the type (contents) of the SCSI command sent from the SCSI command layer 112 or the USB driver layer 114.

In addition, the pseudo-response information is returned to the upper layer via the SCSI command layer 112 based on the analysis result of the SCSI command, and the session with the device server 200 is disconnected in cooperation with the network protocol layer 115. Yes.

The USB driver layer 114 is driver software (for example, usbstore.sys) that performs control in accordance with a function of a USB device to be connected (in this embodiment, the storage 300), and also includes a SCSI command and a USB device. Is a software that performs conversion processing with a USB packet that can be handled.

The network protocol layer 115 is software that performs addition / removal processing of an IP (Internet Protocol) header on a USB packet and controls data communication with the device server 200 connected via the network 500. .

The network interface layer 116 is driver software for performing transmission / reception and communication control by network packets corresponding to the network 500 such as a wired network such as Ethernet (registered trademark) or a wireless network such as IEEE802.11a or IEEE802.11b. It is.

In this embodiment, the filter driver layer 113 is disposed between the SCSI command layer 112 and the USB driver layer 114, but the present invention is not limited to this position. For example, a configuration arranged below the USB driver layer 114 or a configuration incorporated in a part of the driver software of the network protocol layer 115 may be used.

Next, the device server 200 will be described. The device server 200 is a device that controls connection between the PCs 100A and 100B and the storage 300 that is a device.

FIG. 3 is a block diagram illustrating an example of the hardware configuration and software configuration of the device server 200.

The device server 200 includes a CPU 201, an input unit 202, a display unit 203, a ROM 204, a RAM 205, a communication unit 206, a USB interface 207, and the like, which are connected by an internal bus 208.

A ROM (Read Only Memory) 204 stores various software such as an OS 210, a control program 211, and software groups 212 to 213 (to be described later) for realizing the present invention. These software are stored in the RAM 205 according to the control of the CPU 201. It is read out and executed.

The USB interface 207 is an interface for making a local connection with the storage 300 via the connection cable 400.

The communication unit 206 is an interface for data communication with the PC 100 by connecting to the network 500 (wired or wireless network).

The software groups 212 to 213 for realizing the present invention will be described.

The communication layer 212 is software that controls the communication unit 206 connected to the network and performs communication with the PC 100 connected to the network 500 using a session or a network packet.

In addition, in order to communicate with the USB command layer 213, a network packet and a USB packet are converted. Since a network packet is created by adding an IP header to a USB packet, the IP header is attached and removed for conversion.

The USB command layer 213 is software that performs data communication with the storage 300 based on the USB packet.

Note that the communication layer 212 and the USB command layer 213 may be built in the storage 300. In addition, software having the function of the communication layer 212 may be provided in a separate housing and configured as an external adapter having an interface that can be connected to the device (storage 300). In this case, software having the function of the USB command layer 213 is recorded in a RAM or an external storage device on the device 300 side.

Here, communication between the PC 100 and the device server 200 whose software configurations have been described with reference to FIGS. 2 and 3 will be described.

The network protocol layer 115 of the PC 100 communicates with the communication layer 212 of the device server 200 via the network interface layer 116 using the TCP protocol (Transmission Control Protocol). The TCP protocol is a protocol for guaranteeing reliable communication, and is used for transferring data of the storage 300 flowing on the network 500 in this embodiment.

The storage 300 is a device such as an HDD (Hard Disk Drive), and is a device capable of writing and reading various data.

In this embodiment, storage is described as an example of a device, but another device such as a printer or a scanner may be used.

FIG. 4 is a list showing the types, operation codes, sizes, and meanings of the CDB (Command Descriptor Block) for the main SCSI commands used when accessing the storage 300 from the PC 100. The SCSI commands of the PC 100 described above are shown in FIG. This is a control command generated in the layer 112 (see FIG. 2). In the present invention, these SCSI commands are used for session control.

Each CDB defines a 1-byte operation code and the size of a structure corresponding to the 1-byte operation code. For example, in a CDB of Test Unit Ready, the operation code is 0x00 and the size is 6 bytes. Hereinafter, commands used in the description of this embodiment will be described.

A Test Unit Ready command (hereinafter referred to as a TUR command) is sent from the PC 100 periodically (for example, at intervals of one second) when the access to the storage 300 is in an idle state, and is used to check the storage state. Control command.

The READ command is a command used when reading data from the storage 300, and the WRITE command is a command used when writing data into the storage 300. In the following description, control commands other than TUR commands will be described as “access control commands”.

FIG. 5 shows a packet format of SRB (SCSI Request Block) that is commonly used in each SCSI command shown in FIG. The packet is composed of a 2-byte Length indicating the size of the SRB, a 1-byte Function field indicating the function, and the like.

The SRB structure transmitted from the SCSI command layer 112 to the filter driver layer 113 has a size of 64 bytes, and Length = 64 is set. In Function, a value such as 0x00 as an execution code of a SCSI command, 0x01 as a request code to the storage 300, 0x02 for performing control, or the like is set.

1-byte CdbLength corresponding to the 10th offset from the beginning indicates the effective data size of the CDB. CDB indicates a specific command of the SCSI device, and a data area having a fixed length of 16 bytes is secured from the 48th byte of the offset.

Next, a general flow of data communication between the PC 100 and the storage 300 will be described with reference to FIG.

First, a case where data transmission from the PC 100 to the storage 300 will be described.

When an access request to the storage 300 is generated in the PC 100, the SCSI command layer 112 generates one of the SCSI commands described in FIG. 4 according to the content of the access request, and the filter driver layer 113 in the format shown in FIG. Send to.

The filter driver layer 113 analyzes the SCSI command generated in the SCSI command layer 112 and determines what kind of access request it is.

The USB driver layer 114 converts the SCSI command analyzed by the filter driver layer 113 into a USB packet (stores the SCSI command in the data layer of the USB packet).

The network protocol layer 115 adds an IP header to the USB packet converted from the SCSI command in the USB driver layer 114, and creates a network packet that is data in a format suitable for the network 500.

The network interface layer 116 sends the network packet created in the network protocol layer 115 to the device server 200 via the network 500.

In the device server 200, first, the communication layer 212 receives a network packet transmitted from the PC 100 via the network 500, converts the IP packet from the network packet into a USB packet, and converts this to the USB command layer 213. send.

In the USB command layer 213, the USB packet sent from the communication layer 212 is sent to the storage 300 via the connection cable 400.

The storage 300 analyzes the SCSI command included in the USB packet sent from the device server 200 and performs response processing according to the type.

If the SCSI command is a TUR command, a confirmation process of whether or not the storage 300 can be used is executed.

When the SCSI command is a READ command, a read process from the storage 300 is executed.

When the SCSI command is a WRITE command, a write process to the storage 300 is executed.

If the SCSI command is a command other than those described above, processing corresponding to the corresponding command is executed.

Next, a case where data transmission (response) is performed from the storage 300 to the PC 100 will be described.

The storage 300 that has performed the above-described response processing sends the result as response information to the PC 100 to the device server 200 using a USB packet.

In the device server 200, the USB command layer 213 receives a USB packet that is response information from the storage, and sends it to the communication layer 212.

In the communication layer 212, an IP header is added to the USB packet from the USB command layer 213, a network packet that is data in a format suitable for the network 500 is created, and is sent to the PC 100 via the network 500.

In this way, data communication via the device server 200 is executed between the PC 100 and the storage 300.

Next, basic control of the PC 100 (PC 100A, PC 100B) will be described.

The PC 100 determines whether or not the connection with the device server 200 is in a steady state. When the steady state is reached, the session with the device server 200 is disconnected and the upper layer (OS 110, application program 111) of the PC 100 is disconnected. ) And the SCSI command layer 112 shift to a so-called “pseudo-connected state” in which it is recognized that the storage 300 is connected, and control is performed to maintain the “pseudo-connected state” during a steady state.

The steady state refers to a state in which the connection between the PC 100 and the storage 300 is kept constant. To determine whether or not the steady state is established, the storage 300 continuously “SUCCESS” in response to the TUR command. The counter that counts the number of times (initial value 0) is referred to as a SUCCESS counter in the following description.

FIG. 7 is a flowchart illustrating a control operation procedure when the PC 100 accesses the storage 300 via the device server 200.

First, when an access to the storage 300 occurs in the PC 100, the SCSI command layer 112 generates a SCSI command (see FIG. 4) according to the content of the access request, and the generated SCSI command is sent to the filter driver layer 113. (Step S701).

Next, the filter driver layer 113 analyzes the generated SCSI command (step S702).

If the SCSI command is a TUR command (Yes in step S702), the filter driver layer 113 determines the value of the SUCCESS counter (step S703). By this determination, it is determined whether or not the pseudo connection state is established.

If the value of the SUCCESS counter is less than “5” (No in step S703), it is next determined whether or not there is a session with the device server 200 (step S705).

If “no session” with the device server 200 (Yes in step S705), that is, if the value of the SUCCESS counter is “0”, a session start request is sent to the device server 200, and the device server 200 A session is started (step S706).

In the case of “with session” with the device server 200 (No in step S705), that is, when the value of the SUCCESS counter is “1” or more and less than “5”, the processing in step S706 is skipped.

Subsequently, a TUR command is transmitted to the device server 200. The device server 200 sends a TUR command to the storage 300, the confirmation process is executed in the storage 300, and the response information is returned to the device server 200. The device server 200 returns this response information to the PC 100 (step S707).

When receiving the response information sent from the device server 200, the PC 100 confirms the response content (step S708).

If the response content is “FAIL” (No in step S708), the value of the SUCCESS counter is reset to “0” while maintaining the session with the device server 200 (step S715), and the next SCSI command Move to the reception standby state.

If the response content is “SUCCESS” (Yes in step S708), the value of the SUCCESS counter is incremented by 1 (step S709), and then whether or not the value of the SUCCESS counter is the specified value “5” is determined. Determination is made (step S710).

When the value of the SUCCESS counter is less than the specified value “5” (No in step S710), the process shifts to a reception standby state for the next SCSI command while maintaining the session with the device server 200.

If the value of the SUCCESS counter indicates the prescribed value “5” (Yes in step S710), it is determined that the connection with the device server 200 is in a steady state, the session is terminated (step S711), and the next SCSI command is received. Move to standby state.

On the other hand, if the value of the SUCCESS counter is equal to or greater than the specified value “5” in the process of step S703 described above (Yes in step S703), the session is terminated, that is, the steady state, and thus the storage by the actual network connection 300 is not inquired, the pseudo response information is generated in the filter driver layer 113, and "SUCCESS" is returned to the SCSI command layer 112 (step S704). Then, “SUCCESS” is notified from the SCSI command layer 112 to the upper layer, and the next SCSI command reception standby state is entered.

Thereafter, steps S701 to S704 described above are repeated until the filter driver layer 113 receives the access control command. During this time, the upper layer (OS 110, application program 111) and the SCSI command layer 112 of the PC 100 determine that the storage 300 is connected, but the session with the device server 200 is disconnected, so-called “pseudo”. The "connection state" will be maintained.

In addition, the process when the SCSI command analyzed by the filter driver layer 113 in the process of step S702 described above is an access control command will be described.

If the SCSI command is an access control command (No in step S702), for example, if it is a READ command / WRITE command or the like, it is next determined whether or not there is a session with the device server 200 (step S712).

In the case of “no session” with the device server 200 (Yes in step S712), when the value of the SUCCESS counter is “0”, a session start request is sent to the device server 200, and a session with the device server 200 is established. Start (step S713).

In the case of “with session” with the device server 200 (No in step S712), that is, when the value of the SUCCESS counter is “1” or more and less than “5”, the process of step S713 is skipped.

Subsequently, a SCSI command such as a READ command / WRITE command is transmitted to the device server 200. The device server 200 sends this SCSI command to the storage 300, processing corresponding to the READ command / WRITE command or the like is executed in the storage 300, and the response information is returned to the device server 200. The device server 200 returns this response information to the PC 100 (step S714).

Upon receiving the response information sent from the device server 200, the PC 100 resets the value of the SUCCESS counter to “0” while maintaining the session with the device server 200 (step S715), and receives the next SCSI command. Move to standby state.

The SUCCESS counter may be included in the filter driver layer 113 as a part of its function, and is recorded in the external storage unit 106 as another software, and the memory 104 is controlled according to the control of the CPU 101 as in the software groups 112 to 116. It may be read out and executed.

As described above, in the filter driver layer 113, when the access control command is received before the value of the SUCCESS counter reaches the specified value “5”, or when the response information is “FAIL”, the value of the SUCCESS counter Reset the value to “0”.

In the present embodiment, the value of the SUCCESS counter is used as an example of a criterion for determining whether or not the connection between the PC 100 and the device server 200 is in a steady state, but the specified value may be a value other than “5”. The user may arbitrarily set it. Alternatively, the response to the TUR command may be conditional on SUCCESS for a certain time.

FIG. 8 is a diagram showing state transitions of the PC 100 that operates based on the control flow of FIG.

A state 801 is an initial state of the PC 100 such as immediately after power-on. At this time, there is “no session” with the device server 200, and the value of the SUCCESS counter is the initial value “0”.

When an access to the storage 300 occurs in the state 801, the state 801 transits to the state 802.

The state 802 is a state where the connection with the device server 200 is not yet in a steady state. At this time, there is a “session” with the device server 200, and the value of the SUCCESS counter is less than “5”.

In the state 802, after generating a SCSI command and sending it to the device server 200, when response information is received from the storage 300 via the device server 200, one of the following (a), (b), and (c) It becomes the state of.

(A) When there is a request for a TUR command, the response to this is “SUCCESS”, and when the value of the SUCCESS counter reaches the specified value “5”, the state transitions to state 803.

(B) When there is a request for the TUR command, the response to this is “SUCCESS”, and the value of the SUCCESS counter is less than the prescribed value “5”, the state 802 is maintained.

(C) When there is a request for an access control command and there is a response thereto, the value of the SUCCESS counter is reset to “0” and the state 802 is maintained.

Thus, the PC 100 transitions from the state 802 to the state 803 only in the case of (a) described above.

A state 803 indicates a state where the connection with the device server 200 reaches a steady state, that is, a pseudo connection state. At this time, there is no session with the device server 200, and the value of the SUCCESS counter is equal to or greater than the specified value “5”.

In the state 803, when the SCSI command layer 112 generates a SCSI command in accordance with an instruction from the OS 110 and the application program 111, one of the following states (d) and (e) is entered.

(D) When the SCSI command is a TUR command, the filter driver layer 113 generates pseudo response information, responds SUCCESS to the SCSI command layer 112, and maintains the state 803.

(E) When the SCSI command is an access control command, a session with the device server 200 is started, and the generated SCSI command is sent to the device server 200. When response information from the storage 300 is received via the device server 200, the value of the SUCCESS counter is reset to “0”, and the state transitions to the state 802.

As described above, the PC 100 starts a session with the device server 200 and sends out a SCSI command only when access to the storage 300 is necessary. Storage access by the client PC can be realized. In addition, it is possible to suppress a TUR command that is periodically transmitted from the client PC to the device server 200, thereby reducing the amount of traffic (traffic) on the network.

Next, the control operation of the device server 200 will be described with reference to FIG.

The device server 200 monitors reception of a session start request or session end request from the PC 100.

If a session start request has been received (Yes in step S901), it is confirmed whether or not a session is being connected to another PC 100 (step S902).

If the session has already started (Yes in step S902), “NG” is returned to the PC 100 (step S903).

If the session is not started (No in step S902), the session is started with this PC 100 (step S904), and “OK” is returned as response information (step S905).

If a packet other than the session start request is received in the process of step S901 described above (No in step S901), if it is a session end request (Yes in step S906), the session with the PC 100 being connected to the session is disconnected. Then, “OK” is returned as response information (step S908).

On the other hand, when a packet other than the session end request is received in the process of step S906 described above (No in step S906), a response process corresponding to the type of the packet is executed (step S909).

FIG. 10 is a diagram showing state transition of the device server 200 that operates based on the control flow of FIG.

A state 1001 is an initial state of the device server 200. At this time, there is “no session” with the PC 100. The state 1001 is maintained in response to an external request through communication using a UDP (User Datagram Protocol) protocol.

Here, when access to the storage 300 occurs in the PC 100, a session start request is sent from the PC 100 to the device server 200. The device server 200 starts a session with the PC 100 in response to the session start request, and transitions to the state 1002 ((a) of FIG. 10).

The state 1002 is a “session present” state. In this state, the following processes (b), (c), and (d) are performed, and the state 1002 is maintained.

(B) A command is received from the PC 100 in session connection, is transmitted to the storage 300, and response information for the command received from the storage 300 is returned to the PC 100.

(C) When there is a session start request from another PC 100 that is not in session connection, a new session cannot be started for that PC 100, and “NG” is returned.

(D) Respond to a request from the outside by communication using the UDP protocol.

On the other hand, when there is a session end request from the PC 100 in session connection in the state 1002, the session with the PC 100 is disconnected and the state 1001 is entered ((e) of FIG. 10).

As described above, the device server 200 repeats the transition between the “no session” state 1001 and the “session present” state 1002 in accordance with the state transition of the PC 100.

Next, a specific timing chart when accessing the storage 300 from the PC 100A in the network system described above will be described.

For the sake of simplification and easy-to-understand explanation, first, a case where only one PC 100A accesses the storage 300 (in the case of one-to-one connection) will be described with reference to FIG.

Here, it is assumed that the device server 200 always responds “OK” to a session start request from the PC 100A without considering the presence or absence of a session start request from another client PC.

When access to the storage 300 occurs in the PC 100A, a SCSI command corresponding to the type of access is generated in the SCSI command layer 112 as a storage driver, and the generated SCSI command is transmitted to the filter driver layer 113 ( Timing T1101).

The filter driver layer 113 makes a session start request to the device server 200 (timing T1102). At this time, the value of the SUCCESS counter is the initial value “0”.

The device server 200 responds “OK” to the PC 100A and starts a session with the PC 100A (timing T1103).

When there is a response of “OK” from the device server 200 and the session is started, the filter driver layer 113 transmits a TUR command for confirming the state of the storage 300 (timing T1104).

Upon receiving the TUR command, the device server 200 transmits it to the storage 300 (timing T1105). The storage 300 executes processing according to the TUR command, and returns response information to the device server 200 when the processing is completed (timing T1106). The device server 200 sends response information from the storage 300 to the PC 100A (timing T1107).

The filter driver layer 113 receives the response information from the device server 200. If the response information is “SUCCESS”, the filter driver layer 113 increments the value of the SUCCESS counter by 1 and returns a response to the SCSI command layer 112 (timing T1108).

Thereafter, a TUR command is sent periodically (for example, at intervals of 1 second) until the specified value “5” is reached (timing T1109). When the value of the SUCCESS counter reaches the specified value “5”, a session end request is sent to the device server 200, and the session with the device server 200 is disconnected (timing T1110).

In the PC 100A, the SCSI command layer 112 periodically sends a TUR command even after the session ends (timing T1111), but the filter driver layer 113 has a SUCCESS counter value equal to or greater than the specified value “5”. As long as the SCSI command to be transmitted thereafter is a TUR command, pseudo response information is returned to the SCSI command layer 112 (timing T1112).

The upper layer (OS 110, application program 111) and the SCSI command layer 112 of the PC 100A recognize that it is connected to the storage 300 based on this pseudo response information. This state is a so-called “pseudo-connected state”.

Next, a case where access such as data writing / reading is performed from the pseudo-connected PC 100A to the storage 300 will be described.

When accessing the storage 300 from the pseudo-connected PC 100A such as data writing / reading, the filter driver layer 113 first loads the device server before transmitting an access control command (READ command, WRITE command, etc.). A session start request is sent to 200 (timing T1113).

The device server 200 responds “OK” to the PC 100A and starts a session with the PC 100A (timing T1114).

When there is a response of “OK” from the device server 200 and the session is started, the filter driver layer 113 sends an access control command to the device server 200 (timing T1115).

Upon receiving the access control command from the PC 100A, the device server 200 converts it into a USB packet and transmits it to the storage 300 (timing T1116).

The storage 300 executes processing according to the access control command sent from the device server 200 (for example, data writing / reading), and when the processing is completed, the result is sent to the device server 200 as response information ( Timing T1117).

Upon receiving the response information from the storage 300, the device server 200 transmits this response information to the PC 100A (timing T1118).

Upon receiving the response information from the device server 200, the filter driver layer 113 resets the value of the SUCCESS counter to “0” and returns a response to the SCSI command layer 112 (timing T1119).

Thereafter, similarly to the above, a TUR command is periodically sent from the filter driver layer 113, and when the value of the SUCCESS counter reaches the specified value “5”, a session end request is sent to the device server 200, and the device server 200 Is disconnected (timing T1120). The pseudo connection state is maintained until the storage 300 is accessed again.

Next, as a case closer to actual operation, a case where a plurality of PCs 100 (PC 100A, PC 100B) access the storage 300 (when connected in an N-to-1 manner) will be described with reference to FIG.

FIG. 12 is an explanatory diagram showing a timing chart when the PC 100A accesses the storage 300 from another PC 100B during session connection or accessing the storage 300. The PC 100A has the same operation as that of FIG.

First, a case where the PC 100B tries to access the storage 300 when the PC 100A and the device server 200 are in session connection will be described.

When a session is being connected between the PC 100A and the device server 200, the PC 100B sends a session start request to the device server 200 (timing T1201).

Since the device server 200 is in session connection with the PC 100A, the device server 200 returns “NG” to the PC 100B until the session with the PC 100A is disconnected (timing T1202).

When receiving a “NG” response from the device server 200, the PC 100B periodically resends the session start request.

When the device server 200 receives a “session start request” from the PC 100B when the session with the PC 100A is disconnected and enters a “no session” state (the PC 100A is in a pseudo-connected state), the device server 200 establishes a session with the PC 100B. Start (timing T1203).

When the session with the device server 200 is started, the PC 100B transmits a TUR command to confirm the state of the storage 300 (timing T1204).

Upon receiving the TUR command, the device server 200 transmits it to the storage 300 (timing T1205). The storage 300 executes processing according to the TUR command, and returns response information to the device server 200 when the processing is completed. The device server 200 sends response information from the storage 300 to the PC 100B (timing T1206).

The PC 100B receives the response information from the device server 200. If the response information is “SUCCESS”, the PC 100B determines the specified value of the SUCCESS counter and periodically (for example, at intervals of 1 second) until the specified value is “5”. (Timing T1207). When the specified value of the SUCCESS counter reaches “5”, a session end request is sent to the device server 200, and the session with the device server 200 is disconnected (timing T1208).

At this time, both the PC 100A and the PC 100B are in the pseudo connection state, and the device server 200 is in the “no session” state (timing T1209).

Next, a case where the PC 100A attempts to access the storage 300 from the PC 100B while the PC 100A is accessing the storage 300 (during reading or writing) will be described.

As described above, when both the PC 100A and the PC 100B are in the pseudo connection state and the device server 200 is in the “no session” state, when the PC 100A in the pseudo connection state starts access to the device server 200, the PC 100A and the device server 200 A session start request is sent to the device server 200 and a session with the device server 200 is started. (Timing T1210)

When the session is started, the PC 100A sends an access control command (READ command, WRITE command, etc.) to the device server 200 (timing T1211), and the device server 200 sends an access control command to the storage 300 (timing) T1212).

The storage 300 executes processing (for example, data writing / reading) according to the access control command, and returns the result as response information to the PC 100A via the device server 200 (timing T1213).

Thereafter, similarly to the above, the TUR command is periodically sent from the filter driver layer 113 to the device server 200 until the value of the SUCCESS counter reaches the specified value “5” (timing T1214).

When the PC 100B starts access to the storage 300 and sends a session start request to the device server 200, the device server 200 responds “NG” to the PC 100B (timing T1215).

The PC 100B periodically resends the session start request in response to the “NG” response from the device server 200, but “NG” is received from the device server 200 until the session between the PC 100A and the device server 200 is disconnected. Responded.

When the session between the device server 200 and the PC 100A ends and the device server 200 enters a state in which there is no session, the session is started with the PC 100B by a session start request from the PC 100B (timing T1216). At this time, the PC 100A is in a pseudo-connected state.

The subsequent operations of the PC 100B are the same as those of the PC 100A described above. When the session is started, the PC 100B can access the storage 300 via the device server 200.

As described above, in the network system according to the first embodiment, the communication volume (traffic) on the network is established by connecting the session between the client PC and the device server only when a certain client PC accesses the storage 300. Can be reduced.

Further, since it is not necessary to incorporate a high-load processing function into the device server, it becomes possible to share devices from a plurality of client PCs with an inexpensive network system configuration.

Next, a second embodiment of the present invention will be described in detail with reference to the drawings. In the present embodiment, the configurations illustrated in FIGS. 1 to 6 and FIGS. 8 to 12 are the same as those in the first embodiment, and the description thereof is omitted. Only differences from the first embodiment will be described below.

A basic control flow of the PC 100 (PC 100A, PC 100B) in the second embodiment will be described with reference to FIG. FIG. 13 is a flowchart showing the procedure of the control operation when the PC 100 accesses the storage 300 via the device server 200 as in FIG. 7 in the first embodiment, but steps S1310 and S1311 are shown in FIG. This is a step that was not included (details will be described later).

In the PC 100, when an access to the storage 300 occurs, the SCSI command layer 112 generates a SCSI command (see FIG. 4) according to the content of the access request, and the generated SCSI command is transmitted to the filter driver layer 113. (Step S1301).

Next, the filter driver layer 113 analyzes the generated SCSI command (step S1302).

When the SCSI command is a TUR command (Yes in step S1302), the filter driver layer 113 next counts the number of times when the response to the TUR command is “SUCCESS” (hereinafter, SUCCESS counter). Is determined (step S1303). By this determination, it is determined whether or not the pseudo connection state is established.

If the value of the SUCCESS counter is less than “5” (No in step S1303), it is next determined whether there is a session with the device server 200 (step S1305).

If “no session” with the device server 200 (Yes in step S1305), that is, if the value of the SUCCESS counter is “0”, a session start request is sent to the device server 200, and the device server 200 A session is started (step S1306).

In the case of “with session” with the device server 200 (No in step S1305), that is, if the value of the SUCCESS counter is less than the specified value, the process of step S1306 is skipped.

Subsequently, a TUR command is transmitted to the device server 200. The device server 200 sends a TUR command to the storage 300, the confirmation process is executed in the storage 300, and the response information is returned to the device server 200. The device server 200 returns this response information to the PC 100. At this time, the device server 200 notifies the presence / absence of a session start request received from another client PC (for example, the PC 100B) within a predetermined time. (Step S1307).

The predetermined time here refers to the accumulated time after the start of the session and the transmission interval (for example, one second interval) of the TUR command that is periodically transmitted, but is not limited thereto.

When receiving the response information sent from the device server 200, the PC 100A confirms the response content (step S1308).

If the response content is “FAIL” (No in step S1308), the value of the SUCCESS counter is reset to “0” while maintaining the session with the device server 200 (step S1317), and the next SCSI command Move to the reception standby state.

If the response content is “SUCCESS” (Yes in step S1308), the value of the SUCCESS counter is incremented by 1 (step S1309).

Next, the PC 100A determines whether or not to change a specified value that serves as a reference for determining whether or not to shift the connection with the device server 200 to the pseudo connection state (step S1310). For this determination, information regarding the presence or absence of a session start request from another client PC notified from the device server 200 in step S1307 is used.

If the session start request from another client PC is “Yes” (Yes in Step S1310), the specified value is changed (for example, lowered from “5” to “3”) (Step S1311).

On the other hand, if the session start request from another client PC is “none” (No in step S1310), step S1311 is skipped and the specified value is not changed.

Subsequently, it is determined whether or not the value of the SUCCESS counter is a specified value (step S1310). When the specified value is changed in step S1311, the determination is made based on the changed specified value.

When the value of the SUCCESS counter is less than the specified value (No in step S1310), the process shifts to a reception standby state for the next SCSI command while maintaining the session with the device server 200.

On the other hand, if the value of the SUCCESS counter is equal to or greater than the specified value in the process of step S1303 described above (Yes in step S1303), the session is terminated, that is, in a steady state, so The inquiry is not performed, the pseudo response information is generated in the filter driver layer 113, and “SUCCESS” is returned to the SCSI command layer 112 (step S1304). Then, “SUCCESS” is notified from the SCSI command layer 112 to the upper layer, and the next SCSI command reception standby state is entered.

Thereafter, steps S1301 to S1304 described above are repeated until the filter driver layer 113 receives the access control command. During this time, the upper layer (OS 110, application program 111) and the SCSI command layer 112 of the PC 100 determine that the storage 300 is connected, but the session with the device server 200 is disconnected, so-called “pseudo”. The "connection state" will be maintained.

If the value of the SUCCESS counter indicates a specified value (Yes in step S1310), it is determined that the connection with the device server 200 is in a steady state and the session is disconnected (step S1311), and the next SCSI command reception standby state is set. Move.

In addition, a process when the SCSI command analyzed by the filter driver layer 113 in the process of step S1302 described above is an access control command will be described.

If the SCSI command is an access control command (No in step S1302), for example, if it is a READ command / WRITE command or the like, it is next determined whether or not there is a session with the device server 200 (step S1314).

In the case of “no session” with the device server 200 (Yes in step S1314), when the value of the SUCCESS counter is “0”, a session start request is sent to the device server 200, and a session with the device server 200 is established. Start (step S1315).

In the case of “with session” with the device server 200 (No in step S1314), that is, when the value of the SUCCESS counter is less than the specified value, the process of step S1315 is skipped.

Subsequently, a SCSI command such as a READ command / WRITE command is transmitted to the device server 200. The device server 200 sends this SCSI command to the storage 300, processing corresponding to the READ command / WRITE command or the like is executed in the storage 300, and the response information is returned to the device server 200. The device server 200 returns this response information to the PC 100 (step S1316).

Upon receiving the response information sent from the device server 200, the PC 100 resets the value of the SUCCESS counter to “0” while maintaining the session with the device server 200 (step S1317), and receives the next SCSI command. Move to standby state.

As described above, in the filter driver layer 113, when the access control command is received before the value of the SUCCESS counter reaches the specified value, or when the response information is “FAIL”, the value of the SUCCESS counter is set to “ Reset to “0”.

As described above, in the network system according to the second embodiment, the device server 200 notifies the PC 100 together with the presence / absence of a session start request from another client PC, so that the PC 100 can perform pseudo-connection earlier. The session can be released and the session with the device server 200 can be released.

Note that the present invention is not limited to the above-described embodiment, and can be appropriately changed without departing from the gist of the present invention.

In the above-described embodiment, the configuration is described in which one device server manages one storage, but a configuration in which a plurality of storages are connected to one server may be employed. In this case, by preparing and controlling a session for each storage, a plurality of client PCs can simultaneously access different storages.

In addition, the configuration in which the connection interface between the device server and the device is USB has been described. However, the present invention is not limited to this, and another connection interface may be used. Specifically, in order to support IEEE 1394, the USB driver layer 114 included in the PC 100 and the USB command layer 212 included in the device server 200 may be replaced with the IEEE 1394 driver layer and the IEEE 1394 command layer, respectively.

Further, if the PC 100 has a plurality of different driver layers and the device server 200 has a plurality of different command layers corresponding thereto, it is possible to flexibly support devices having various connection interfaces.

Another object of the present invention is to supply a storage medium storing software program codes for realizing the functions of the above-described embodiments to a system or apparatus, and a computer (or CPU, MPU, etc.) of the system or apparatus. This can also be achieved by reading the program code stored in the storage medium and executing the processing.

In this case, the program code itself read from the storage medium realizes the functions of the above-described embodiments, and a computer-readable storage medium storing the program code constitutes the present invention. .

Further, an OS (operating system) or the like running on the computer performs part or all of the actual processing based on an instruction of the program code, and the functions of the above-described embodiments are realized by the processing. You may do it.

Furthermore, after the program code read from the storage medium is written in the memory of the function expansion board inserted into the computer or the function expansion unit connected to the computer, the function expansion is performed based on the instruction of the program code. In some cases, the CPU or the like provided in the board or the function expansion unit executes part or all of the actual processing, and the above-described embodiment is realized according to the processing.

In order to supply the program code, for example, a floppy (registered trademark) disk, a hard disk, a magneto-optical disk, an optical disk represented by CD or DVD, a magnetic tape, a nonvolatile memory card, a ROM, or the like is used. Can do. Alternatively, the program code may be downloaded via a network.

1 is a block diagram showing a schematic configuration of a network system according to an embodiment of the present invention. It is a block diagram which shows the schematic structure of the hardware of PC100A, 100B of FIG. 1, and hardware. It is a block diagram which shows the hardware of the device server 200 of FIG. 1, and schematic structure of hardware. It is a list of main SCSI commands used as control commands. It is explanatory drawing of the packet format of SRB (SCSI Request Block) used in common by each SCSI command. It is explanatory drawing of the rough flow of the data communication between client PC and a storage. It is a flowchart which shows the control operation of the session of the client PC in 1st embodiment. It is a state transition diagram of a client PC. It is a flowchart which shows the control operation of the session of the device server in 1st embodiment. It is a state transition diagram of a device server. 6 is a timing chart showing a process when one client PC accesses the storage in the first embodiment. 4 is a timing chart showing a process when a plurality of client PCs access a storage in the first embodiment. It is a flowchart which shows the control operation of the session of the client PC in 2nd embodiment. 6 is a flowchart illustrating an operation when a session is controlled by operating a utility of a client PC when accessing a storage on a network in the related art. 10 is a timing chart showing a process when a plurality of client PCs access a storage in the prior art.

Explanation of symbols

100A, 100B: Client PC
101: CPU
102: Input unit 103: Display unit 104: Memory 105: Communication unit 106: External storage unit 107: Internal bus 110: OS
111: Application program 112: SCSI command layer 113: Filter driver layer 114: USB driver layer 115: Network protocol layer 116: Network interface layer 200: Device server 201: CPU
202: Input unit 203: Display unit 204: ROM
205: RAM
206: Communication unit 207: USB I / F (USB interface)
208: Internal bus 210: OS
211: Control program 212: Communication layer 213: USB command layer 300: Storage 400: Connection cable 500: Network

Claims (8)

A client that inputs / outputs data to / from a device connected to a server via a network,
An upper layer that instructs access to the device,
Control command generating means for generating a first control command for confirming whether or not the device is available according to an instruction from the upper layer;
A session start request means for sending a session start request to the said first control command is generated by the control command generating unit server,
Session start means for starting a session with the server based on a response to the session start request;
Connecting said server and the session, sends periodically the first control command to the server, and the session connection status confirmation means for confirming the presence or absence of a session start request from the connected state and other clients for the session,
A predetermined condition changing means for changing a predetermined condition for shifting to the pseudo connection state according to the presence or absence of the session start request;
When the response to the first control command received from the server the predetermined condition is satisfied, the session disconnection means for cutting the session,
After the session is disconnected, the first control command generated by the control command generation means is not sent to the server, and a response to the first control command is pseudo-generated and notified to the upper layer A pseudo-response means ;
A client characterized by comprising. The predetermined condition is whether or not a successful response to the first control command has continued for a specified number of times or for a specified time.
The client according to claim 1. The control command generation means further generates a second control command for inputting / outputting data to / from the device,
The session start request means further sends a session start request to the server when the second control command is generated by the control command generation means after the session is disconnected.
The client according to claim 1. 4. A device sharing system comprising the device, the server, and the client according to claim 1 connected to the server via the network. The server manages information on presence / absence of the session start request from a client not in session connection, and adds information on presence / absence of the session start request to a response to the first control command to a client in session connection. Sending
The device sharing system according to claim 4. A device sharing method in which a device connected to a server via a network is shared by a client,
A control command generating step for generating a first control command for confirming whether or not the device is available in response to an instruction from an upper layer instructing access to the device;
A session start requesting step for sending a session start request to the server when the first control command is generated by the control command generating step;
A session start step in which a session start means starts a session with the server based on a response to the session start request;
Session connection status confirmation means periodically sends the first control command to the server during session connection with the server, and confirms the connection status of the session and whether there is a session start request from another client. Session connection status confirmation step;
A predetermined condition changing step in which the predetermined condition changing means changes the predetermined condition for shifting to the pseudo connection state according to the presence or absence of the session start request;
A session disconnecting step for disconnecting the session when the response to the first control command received from the server satisfies the predetermined condition by the session connecting means;
The pseudo response means does not send the first control command generated in the control command generation step to the server after disconnecting the session, and generates a pseudo response to the first control command, A pseudo-response step to notify the upper layer;
A device sharing method comprising: The predetermined condition is whether or not a successful response to the first control command has continued for a specified number of times or for a specified time.
The device sharing method according to claim 6. In the control command generation step, a second control command for inputting / outputting data to / from the device is further generated,
The session start request step further includes a step of sending a session start request to the server when the second control command is generated by the control command generation step after the session is disconnected.
The device sharing method according to claim 6.

Images