JP6090751B2 - Device server and its control method - Google Patents

Description

  The present invention relates to a device server that performs isochronous transfer between a client and a device via a network, and a control method therefor.

Wired LAN (Local
2. Description of the Related Art A device server system is known in which a USB (Universal Serial Bus) device, which is a computer peripheral device, can be used from a computer terminal (client) connected to the network via a network such as an area network or a wireless LAN. (See Patent Document 1 and Non-Patent Document 1).

  In the device server system, data such as a command issued by a client device driver is converted into a network packet (referred to as a tunneling packet), which is transmitted from the client to the device server. The device server that has received the tunneling packet extracts data such as a command included in the received tunneling packet, converts it into USB communication, and transfers it to a USB device locally connected to itself.

  Communication between the device server and the USB device conforms to USB standard communication. For example, in the case of transmission from a client to a USB device, data is transmitted from the client to the USB device via the device server, and at any time, the client receives a response regarding the status of the USB device via the device server.

  When the USB device is a speaker or a display, streaming data that requires real-time properties such as audio and video is transferred from the client to the USB device. In this case, data can be transferred without interruption by performing data transfer (isochronous transfer) by an isochronous method that guarantees a minimum data transfer amount per fixed time.

  When performing isochronous transfer between a client and a USB device via a device server, the client and the USB device are not connected locally, but are connected via a network. Since the data transfer rate decreases, it is necessary to maintain the minimum data transfer amount guaranteed by isochronous transfer.

When isochronous transfer is performed from a client to a USB device, the client makes an isochronous transfer request within the client in order to maintain the isochronous output transfer while minimizing the influence of the data transfer speed reduction that occurs in the network. It is determined that the response information has been received by processing the response information from the USB device (via the device server), and the next isochronous transfer request is sent without waiting for the response information from the USB device. A control method is known in which the device server performs control so that the response information from the USB device is discarded and not returned to the client (Patent Document 2).
According to the control method disclosed in Patent Document 2, the client is guaranteed by isochronous output transfer because processing of the next isochronous transfer request is not delayed due to delay (waiting for reception) of response information from the USB device. The minimum data transfer amount can be maintained, and since response information is not sent from the device server to the network, network traffic can be reduced.

In the control method disclosed in Patent Document 2 above, in the internal processing of the client, it is determined that the response information is forged and the response information is received, and the next isochronous transfer is performed without waiting for the response information from the USB device. By sending a request, the minimum data transfer amount guaranteed by isochronous transfer is maintained.
However, since the device server performs control so that the response information from the USB device is discarded and not returned to the client, the response information from the USB device is an unrecoverable error (fatal error). The client sends the next isochronous transfer request, which is not preferable.

In addition, in the internal processing of the device server, a device server control method is known in which response information from a USB device in response to an isochronous transfer request is forged and dummy response data is transmitted to a client (Patent Document 3).
According to the control method disclosed in Patent Document 3, the client is guaranteed by isochronous output transfer because processing of the next isochronous transfer request is not stagnated due to a delay (waiting for reception) of response information from the USB device. The minimum data transfer amount can be maintained.

  However, if the device server that executes the control method disclosed in Patent Document 3 does not receive the response information from the USB device even after a predetermined time has elapsed, the device server forges the response information from the USB device and performs a dummy response. Since data is transmitted to the client, even if the USB device itself is in an unrecoverable status (fatal status), the client sends the next isochronous transfer request, which is not preferable. . In addition, since the device server that executes the control method disclosed in Patent Document 3 transmits the response information from the USB device received within a predetermined time to the client as it is, when there is an error in the response information, the client There is a problem that the communication session with the device server is immediately disconnected.

JP 2008-287453 A JP 2012-138694 A Japanese Patent No. 4617440

Silex Technology Co., Ltd. homepage <http://www.silex.jp/products/usbdeviceserver/sx3000gb.html>

Conventionally, the client prefetches several hundred milliseconds and makes an isochronous transfer request to guarantee a network delay. The device server performs isochronous transfer to the USB device while keeping the isochronous transfer request scheduled by the client as it is.
However, especially in the case of a wireless LAN, network transfer may be delayed due to a broken link of the network or an adverse effect of aggregation depending on the radio wave condition, and it may not be ensured only by prefetching several hundred milliseconds by the client.

Once the link is broken and restored at the wireless LAN level, a plurality of isochronous transfer requests may be issued at a time from the client, and a large amount of data may be transferred. Since the device server performs isochronous transfer to the USB device while keeping the client's isochronous transfer request as it is, a phenomenon that isochronous transfer scheduling cannot occur occurs. In this case, it is responded as a USB standard communication error (a stack level error indicating that a data flow has occurred because there is no scheduler buffer space).
Since the client receives a response regarding the status of the USB device via the device server, the client disconnects the session with the device server in spite of such an unrecoverable error, and the isochronous transfer ends.

  As described above, the isochronous transfer in the conventional device server cannot recover the transfer error due to the undulation of the data transfer amount due to the network delay. In addition, since the conventional device server performs isochronous transfer to the USB device while keeping the client's isochronous transfer request as it is, the data transfer amount to be guaranteed by isochronous transfer cannot be maintained. That is, the isochronous transfer method in the conventional device server has a problem that the network tolerance is weak.

  In view of the above situation, according to the present invention, in isochronous output transfer in a device server to which a device is locally connected, it is possible to recover a transfer error due to the undulation of the data transfer amount due to a network delay, and data transfer to be guaranteed by isochronous transfer It is an object to provide a device server and a device server control method capable of maintaining the amount and improving the network tolerance of isochronous output transfer.

In order to achieve the above object, the device server of the present invention is requested when an isochronous output transfer request is received from a client in a device server connected to the client via a network and the device performing isochronous transfer is locally connected. A data buffer unit for buffering transfer data is provided. When the isochronous output transfer is performed to a locally connected device and the result of the isochronous output transfer is neither normal completion nor an unrecoverable error, the data buffer unit is buffered. The ringed transfer data is again isochronously output to the device. And the timing to transfer the transfer data buffered in the data buffer unit again is isochronous output transfer is “when the previous isochronous output transfer result is completed normally” or “when the next isochronous output transfer request is received from the client” Is.

Here, the client means a general computer terminal such as a personal computer, and is an apparatus that performs isochronous output transfer to a device connected to a network and locally connected to a device server. The device is a device that is locally connected to the device server and can perform data communication with the device server by a data communication method such as a USB communication standard.
In addition, an unrecoverable error in an isochronous output transfer result is a data communication protocol error due to a device failure or power-off. On the other hand, an error that is not recoverable is an empty buffer in the data transfer scheduler as described above. It is an error due to data flow because there is no.

The device server of the present invention sends the transfer result to the client when the isochronous output transfer result is normal completion or an unrecoverable error, while the buffered transfer data is transferred when the isochronous output transfer result is an unrecoverable error. By isochronous output transfer to the device again, the session between the client and the device server is continued, and the data transfer amount to be guaranteed by isochronous transfer is maintained.
The device server of the present invention transfers the output data without interruption by buffering isochronous output data that could not be scheduled in the device server and rescheduling when the previous isochronous output transfer is completed. The effect can be expected particularly when an event occurs in which data transfer is delayed due to a broken link of the network or an adverse effect of aggregation like a wireless LAN.

The timing of isochronous output transfer of buffered transfer data again is “when the previous isochronous output transfer result has been completed normally” because the data transfer scheduler has no available space and cannot be recovered due to data flow. This is because if there is no error, it can be assumed that the buffer will be freed later and the error will be resolved.
In addition, the timing when the buffered transfer data is again isochronous output transferred is “when the next isochronous output transfer request is received from the client” in order to synchronize with the client's isochronous output transfer schedule.

  In the device server of the present invention, when the next isochronous output transfer request is not received within a predetermined time after the transfer of the previous isochronous output transfer request is normally completed, the transfer data buffered at the time of the previous transfer request is dummy data. It is preferable to perform isochronous output transfer to the device.

When the next isochronous output transfer request is not received within a predetermined time after the transfer of the isochronous output transfer request is normally completed, the data transfer amount to be guaranteed by the isochronous transfer cannot be maintained for the device.
In order to maintain the data transfer amount to be guaranteed by isochronous transfer to the device, isochronous output transfer is performed to the device using the buffered transfer data as dummy data.

A device server control method according to the present invention is a device server control method in which a device that is connected to a client via a network and performs isochronous transfer is locally connected, and includes the following steps 1) to 3). .
1) Transfer request receiving step for receiving an isochronous output transfer request from the client, and transfer data storing step for buffering the requested transfer data 2) Output transfer step for performing isochronous output transfer to a locally connected device 3) Re-transfer step to transfer the buffered transfer data to the device again when the isochronous output transfer result is neither normal completion nor irrecoverable error

  In the re-transfer step in the device server control method of the present invention, the timing at which the buffered transfer data is again isochronously output is transferred when the previous isochronous output transfer result is normally completed or from the client to the next isochronous output transfer. When a request is received.

  In the device server control method of the present invention, when the next isochronous output transfer request is not received within a predetermined time after the transfer of the previous isochronous output transfer request is normally completed, the transfer data buffered at the time of the previous transfer request It is preferable to further include a dummy transfer step of performing isochronous output transfer to the device using the data as dummy data.

  According to the present invention, in isochronous output transfer in a device server to which a device is locally connected, a transfer error due to undulation of the data transfer amount due to network delay can be recovered, and the data transfer amount to be guaranteed by isochronous transfer can be maintained. There is an effect of improving the network tolerance of output transfer.

Functional block diagram of device server system Conceptual diagram of a device server system that performs isochronous output transfer Conventional device server control flow diagram Illustration of error occurrence in isochronous output transfer via network Data flow diagram of conventional device server system Data flow diagram of device server system of the present invention (1) Control flow chart of device server of the present invention (1) Control flow chart of device server of the present invention (2) Data flow diagram of device server system of the present invention (2) Data flow diagram of device server system of the present invention (3)

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. The scope of the present invention is not limited to the following examples and illustrated examples, and many changes and modifications can be made.

FIG. 1 shows an example of functional blocks of the device server system.
In the device server system shown in FIG. 1, the USB device 30 locally connected to the device server 10 via the network 40 from the client 20 is controlled.
The network 40 is a wired or wireless network. In FIG. 1, the client 20 and the device server 10 are connected at 1: 1, but there are a plurality of them, and they are connected at N: 1, 1: N, N: M (N and M are natural numbers of 2 or more). It may be done. Two or more USB devices may be locally connected to the device server 10.

Here, the client 20 has a hardware configuration similar to that of a general personal computer, and a CPU (not shown), an input unit, a display unit, a memory, an external storage unit, a communication interface 25 (not shown), and the like are connected via an internal bus. Has been.
The client 20 includes an application 21, a device driver 22, a USB class driver 23, and a tunneling driver 24 that are stored in an external storage unit and are loaded in the memory at the time of execution as software components.
In addition, as a software component, OS (Operating
System), a resident module, a data communication control program, and the like, which are stored in an external storage unit together with various data necessary for control. These software components and various data are read out on the memory and various controls are executed under the control of the CPU.

  The resident module is a software component that always stands by and operates while the OS is running, and performs data transmission / reception with the device server 10 via the network 40. Also, USB device information for recognizing and identifying the USB device 30 locally connected to the device server 10 is received. Based on the received USB device information, a device driver 22 and a USB class driver 23 necessary for data transmission / reception with the USB device 30 are generated, and the USB device 30 can be controlled.

The device driver 22 converts a data input / output request from a higher-level program such as the OS, the application 21, and a resident module into a data format corresponding to the USB device 30 that is a data input / output target, and sends a response from the USB device 30 to the Pass to program.
Similarly, a data output request (hereinafter referred to as an isochronous output request) by isochronous transfer from a higher-level program is also converted into a data format corresponding to the USB device 30 as an isochronous output target.

  The USB class driver 23 converts the data input / output request converted into the data format corresponding to the USB device 30 by the device driver 22 into packet data conforming to the USB data format, and passes the packet data to the tunneling driver 24. Packet data conforming to the USB data format sent from the driver 24 is converted to a data format and passed to the device driver 22.

  The tunneling driver 24 encapsulates the packet data passed from the USB class driver 23 into a network packet. On the other hand, when a network packet is received from the device server 10, response packet data is taken out (decapsulated) from the network packet and transferred to the USB class driver 23 and the device driver 22.

On the other hand, the device server 10 includes a communication interface 11, a tunneling driver 12, a USB driver 13, and a data buffer unit 14.
When receiving a network packet from the client 20, the tunneling driver 12 extracts (decapsulates) packet data conforming to the USB data format from the network packet and sends it to the USB driver 13. Also, packet data conforming to the USB data format is received from the USB driver 13 and encapsulated into a network packet.

  As shown in FIG. 2, in a system in which a microphone 28 is connected to the client 20 and a speaker 32 as a USB device is connected to the device server 10 via the USB connection cable 31, the microphone 28 of the client 20 is connected via the network. Audio data is transferred to the speaker 32 as streaming data. In this case, the audio data is transferred to the speaker without interruption by isochronous output transfer that guarantees the minimum data transfer amount per fixed time.

  FIG. 3 shows a control flow of a conventional device server. When receiving the isochronous output transfer request from the client (S31), the conventional device server transfers the received data to the USB driver in units of URB (USB Request Block) (S33). Then, the device server receives the transfer result from the USB driver and determines the transfer result. When an error is received as a transfer result (S35), the transfer result (error) is sent to the client (S37).

  FIG. 4 is a graph of data transfer amount in isochronous output transfer via a network. In isochronous output transfer, a constant amount of data flow is always required. At normal time, as shown in FIG. 4, the data transfer amount is a constant value of 1000 (bps). On the other hand, at the time of abnormality, a delay occurs in the network between 200 and 400 (ms), and data flows unexpectedly at the moment of recovery (500 ms). An error occurs when a data transfer request is made to the USB driver in a situation where data flows unexpectedly.

  FIG. 5 shows a data flow of a conventional device server system. In the data flow of FIG. 5, an isochronous output transfer request is issued from the client 20 when the client 20 is connected to the device server 10 via the network, and the device server 10 and the USB device 30 are connected via USB, and the USB driver 13 is connected. Shows the case of responding with an error. First, there is an isochronous output transfer request (Isoc-out transfer request C1) from the client 20, and the tunneling driver 12 of the device server 10 receives it and makes an isochronous output transfer request (Isoc-out transfer request C2) to the USB driver 13. . The USB driver 13 makes an isochronous output transfer request (Isoc-out transfer requests C3 to C6 and C8) to the USB device 30 in units of URBs. When the isochronous output transfer is completed successfully, a transfer response (OK) C9 is issued from the USB driver 13, and a transfer completion response C10 is sent to the client 20 by the tunneling driver 12.

However, when the link is broken and returned at the network level, a plurality of isochronous transfer requests may be issued at a time from the client, and a large amount of data may be transferred.
In this case, for example, following the isochronous output transfer request (Isoc-out transfer request C1) from the client 20, the next isochronous output transfer request (Isoc-out transfer request C7) is issued, and the tunneling driver 12 of the device server 10 In response to this, an isochronous output transfer request (Isoc-out transfer request C11) is made to the USB driver 13, but a phenomenon in which isochronous transfer cannot be scheduled occurs, and an error may be returned from the USB driver 13 as a transfer response C13. . The tunneling driver 12 sends a transfer error response C14 to the client 20. As a result, the isochronous output transfer session is disconnected.
In other words, in the conventional device server, when an isochronous output transfer request that cannot be scheduled by the scheduler of the USB driver 13 is issued, the USB driver 13 returns an error response, and the error is returned to the client 20 as it is. The communication session between the device servers will be disconnected.

FIG. 6 shows the data flow of the device server system of the present invention.
As shown in FIG. 6, in the case of the device server system of the present invention, when a phenomenon in which isochronous transfer cannot be scheduled occurs and an error is returned as the transfer response C13 from the USB driver 13, buffering is performed in the data buffer unit 14. By making an isochronous output transfer request (Isoc-out transfer request C15) to the USB device 30 again, the session between the client 20 and the device server 10 is continued, and the data transfer amount to be guaranteed by isochronous transfer is determined. maintain.

  In isochronous output transfer, when the USB driver 13 returns an error as a transfer response, it can be classified into an unrecoverable error and an unrecoverable error. Unrecoverable errors are data communication protocol errors due to device failure or power off. An error that is not unrecoverable is an error caused by a data flow because there is no space in the buffer of the data transfer scheduler.

  In the case of an error due to a data flow because there is no space in the buffer of the data transfer scheduler, it can be presumed that the buffer will become empty later and the error will be resolved. Therefore, the transfer data immediately before is transferred by the processing of the tunneling driver 12 in the device server 10. Is buffered in the data buffer unit 14, and the buffered transfer data is again requested for isochronous output transfer. The USB driver 13 makes an isochronous output transfer request (Isoc-out transfer requests C16 to C20) to the USB device 30 in units of URBs. When the isochronous output transfer is completed successfully, a transfer response (OK) C21 is issued from the USB driver 13, and a transfer completion response C22 is sent to the client 20 by the tunneling driver 12.

FIG. 7 is a control flowchart of the device server of the present invention.
When an isochronous output transfer request is received from the device server 10 and the client 20 (S101), the transfer data is stored in the data buffer unit 14 (S103), and the data is transferred to the USB device in units of URB (S105). When the transfer result is received from the USB driver and the result is normal end (OK) (S107), the transfer result (OK) is returned to the client 20 (S109), and the next isochronous output transfer from the client 20 is performed. Wait for the request.

On the other hand, if the transfer result is received from the USB driver and the result is an error (S107), it is determined whether or not the error is a fatal error (S111). If the transfer result is a fatal error, the transfer result (error) is returned to the client (S113), and the next isochronous output transfer request is awaited from the client 20.
On the other hand, if the transfer result error is not a fatal error, it is determined as a transient error, and if any data on the buffer has been transferred in units of URBs (Yes in S115), the data buffer The transfer data of the unit 14 is retransferred to the USB device (S117). If the transfer is not completed (No in S115), it is determined whether or not the next transfer request has been received from the client. If it is determined that the transfer has been received (Yes in S119), the transfer data on the buffer is transferred to the USB device. (S117). On the other hand, if the next transfer request is not received from the client (No in S119), it is determined that the transient error continues, and has any of the data on the buffer been transferred in units of URBs? The process returns to the determination flow of (S115).

Further, the device server of the present invention performs the control flow shown in FIG. That is, when the next transfer request has not been received within a predetermined time from the completion of the transfer of the immediately preceding isochronous output transfer request (result OK) (S21), the data on the buffer is transferred as dummy data (URB unit) (S23). ).
When the device server of the present invention does not receive the next isochronous output transfer request within a predetermined time after the data transfer based on the immediately preceding isochronous output transfer request is normally completed by performing the control flow shown in FIG. By performing the isochronous output transfer to the USB device using the transfer data buffered at the time of the transfer request as dummy data, the data transfer amount to be guaranteed by the isochronous transfer can be maintained.
A data flow when the control flow shown in FIG. 8 is performed will be described with reference to FIGS.

As shown in FIG. 9, when the next isochronous output transfer request is not received within a predetermined time after the transfer completion response C9 is sent to the client 20 by the tunneling driver 12 (C10), the device server 10 receives dummy data (immediately before Transfer data buffered at the time of the transfer request) (C11), and the USB driver 13 makes an isochronous output transfer request (Isoc-out transfer request C12, C15 to C18) in units of URBs to the USB device 30. I do. When the isochronous output transfer is completed successfully, a transfer response (OK) C 19 is issued from the USB driver 13, and a transfer completion response C 20 is sent to the client 20 by the tunneling driver 12.
If there is an isochronous output transfer request from the client 20 during the isochronous output transfer of this dummy data (C13), the device server 10 discards the request (C14).

  When the device server 10 does not receive the next isochronous output transfer request within a predetermined time, the device server 10 requests the transfer data buffered at the time of the previous transfer request as dummy data to make an isochronous output transfer request, as shown in FIG. Data can be transferred to the USB device 30 at regular intervals.

  In the above embodiments, a device server system in which a client uses a USB device via a network has been described as an example. However, the scope of application of the present invention is not limited to this, and a communication method equivalent to the USB communication standard is used. For example, it may be based on another interface such as IEEE1394.

  The present invention is useful for a device server system that enhances the convenience of peripheral devices such as USB devices.

10 device server 20 client 28 microphone 30 USB device 31 USB connection cable 32 speaker 40 network

Claims (4)

A device server connected to a client via a network and performing isochronous transfer is a locally connected device server,
When receiving an isochronous output transfer request from the client, it has a data buffer unit that buffers the requested transfer data,
When performing isochronous output transfer to a locally connected device, if the isochronous output transfer result is neither normal completion nor an unrecoverable error, transfer data buffered in the data buffer unit is transferred to the device. And transfer the isochronous output again .
The timing to transfer the transfer data buffered in the data buffer unit again to the isochronous output is when the previous isochronous output transfer result is normally completed or when the next isochronous output transfer request is received from the client. A device server characterized by When the next isochronous output transfer request is not received within a predetermined time after the transfer of the previous isochronous output transfer request is normally completed, the transfer data buffered in the data buffer unit at the time of the previous transfer request is used as dummy data. The device server according to claim 1 , wherein isochronous output transfer is performed for the device. A device server control method in which an isochronous transfer device connected to a client via a network is locally connected.
A transfer request receiving step for receiving an isochronous output transfer request from a client;
A transfer data storage step for buffering the requested transfer data;
An output transfer step for performing isochronous output transfer to a locally connected device;
When the isochronous output transfer result is neither normal completion nor an unrecoverable error, the transfer data storage step further includes a retransfer step for transferring the transfer data buffered to the device again to the isochronous output ,
In the retransmission step,
The device for transferring isochronous output of buffered transfer data again is when the previous isochronous output transfer result is normally completed or when the next isochronous output transfer request is received from the client. Server control method. When the next isochronous output transfer request is not received within a predetermined time after the transfer of the previous isochronous output transfer request is completed normally, the transfer data buffered at the time of the previous transfer request is used as dummy data to the device. The device server control method according to claim 3 , further comprising a dummy transfer step of performing output transfer.