The present invention relates to a technique to relay communication data between a client device and a host device.
In recent years, in corporate entities, information leakage due to loss or theft of notebook PCs is becoming a problem. As a way for solving this problem, there is an approach referred to as a “thin client system”. In the thin client system, a client device is provided with a minimum required function only, whereas a server (host device) integrally controls application software and electronic files. As one such thin client system, there is a system that is called as “screen transfer type thin client system”.
In the screen transfer type client system, a storage device such as an HDD (hard disk drive) does not reside on the client device. The host device accepts a remote login from the client device, and transfers a work screen to the client device.
In many cases, the client system described above takes a form in which a client device connected to the Internet is used by remotely coupling the client device with the host device. Therefore, there may be a delay in transferring the work screen from the host device. Accordingly, by way of example, it may take time for a mouse action or a key input on the client device to be reflected on the work screen transferred from the host device.
In order to improve the situation above, there is an approach for speeding up communication between the client device and the host device. Here, prioritized delivery by a router is taken as a measure for speeding up a particular network communication. This prioritized delivery is a technique in which a core router arranged in the Internet or an intranet transfers a particular communication flow packet, giving the packet a higher priority than other packets. This technique is utilized mainly to reduce transfer delay in a real-time communication application, such as video streaming and IP telephony. The core router that performs such prioritized delivery as described above is also referred to as QoS (Quality of Service) router. “Diffserv (Differentiated Services)” is taken as an example of a representative technique of such prioritized delivery. In simple terms, this technique involves setting a transfer priority to a header of a packet, and the core router performing the prioritized delivery according to the priority. The technique “Diffserv” is described in “S. Blake, et al. “An Architecture for Differentiated Services” [online], December 1998, (retrieved on Dec. 15, 2006), Internet URL: http://www.ietf.org/rfc/rfc2475.txt” (hereinafter, referred to as “non-patent document 1”).
However, if priorities of all traffic are set to be high, the priority itself becomes meaningless. Therefore, some telecommunications carriers distinguish prioritized communication from non-prioritized communication by charging for a packet that is to be delivered with priority. Some other telecommunications carriers install a device on a network, dedicated to setting a transfer priority to the header of a packet, in order to prevent a user from taking the liberty of using the prioritized delivery. This dedicated device makes an assessment as to a communication application, according to a source port number or a destination port number of the communication data, and determines whether the communication is prioritized or not prioritized.
However, in cases where a telecommunications carrier is employed, who charges for the packet to be delivered with priority according to the Diffserv technique, communication charges may be very high if the prioritized delivery is simply applied to all communications. Therefore, considering the cost, it is desirable to exercise control as described below to suppress, to a minimal amount, the number of packets targeted for prioritized delivery. In other words, control is exercised so that normal communication quality is acceptable for remote desktop communication for operation in which efficiency is not much influenced by communication delay, such as, for example, document editing and web browsing via a browser, whereas the remote desktop communication is performed with prioritized delivery for watching streaming video or for IP telephone usage.
However, in the screen transfer type thin client system, a host PC merely transfers work screen information to a client PC, via the remote desktop communication. Screen data is exchanged between the thin client and the host, through one connection. In this case, when a device, which dedicated to setting the transfer priority to the header of the packet, is installed on the network, it is not possible to determine what kind of operation the user is performing, even when the remote desktop communication is being monitored. Therefore, it is difficult to exercise control to change the delivery priority of the remote desktop communication, according to the contents of the operation being performed by the user.