知財求人 - 知財ポータルサイト「IP Force」
▶ 日本電気株式会社の特許一覧 ▶ ＮＥＣソリューションイノベータ株式会社の特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5652891
(24)【登録日】2014年11月28日
(45)【発行日】2015年1月14日
(54)【発明の名称】リモートデスクトップシステム
(51)【国際特許分類】
G06F 13/00 20060101AFI20141218BHJP
H04L 12/807 20130101ALI20141218BHJP
【ＦＩ】
G06F13/00 353A
H04L12/807
【請求項の数】21
【全頁数】25
(21)【出願番号】特願2013-32836(P2013-32836)
(22)【出願日】2013年2月22日
(65)【公開番号】特開2014-164369(P2014-164369A)
(43)【公開日】2014年9月8日
【審査請求日】2013年2月22日
(73)【特許権者】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(73)【特許権者】
【識別番号】000232092
【氏名又は名称】ＮＥＣソリューションイノベータ株式会社
(74)【代理人】
【識別番号】100124811
【弁理士】
【氏名又は名称】馬場 資博
(74)【代理人】
【識別番号】100088959
【弁理士】
【氏名又は名称】境 廣巳
(72)【発明者】
【氏名】釣 大輔
(72)【発明者】
【氏名】中田 佳孝
【審査官】
木村 雅也
(56)【参考文献】
【文献】
特開２０１２−０４４６６８（ＪＰ，Ａ）
【文献】
特開２０１３−０３４１０１（ＪＰ，Ａ）
【文献】
特開２００５−２４９８４１（ＪＰ，Ａ）
【文献】
特表２００８−５０７９２８（ＪＰ，Ａ）
【文献】
特開２００８−２７０９７２（ＪＰ，Ａ）
【文献】
特開２００５−１３６６８４（ＪＰ，Ａ）
【文献】
特開２００８−１７２５２１（ＪＰ，Ａ）
【文献】
特開２００１−１９５３２６（ＪＰ，Ａ）
(58)【調査した分野】（Int.Cl.，ＤＢ名）
Ｇ０６Ｆ １３／００
Ｈ０４Ｌ １２／８０７
(57)【特許請求の範囲】
【請求項1】
サーバ装置とクライアント装置とがネットワークを介して接続されたリモートデスクトップシステムであって、
前記クライアント装置に接続されるクライアント側プロキシと、
前記サーバ装置に接続されると共に前記ネットワークを介して前記クライアント側プロキシに接続されるサーバ側プロキシとを有し、
前記クライアント側プロキシは、
前記クライアント装置から前記サーバ装置向けの情報を受信してＴＣＰ通信により前記ネットワークを通じて前記サーバ側プロキシへ送信する第１の通信部と、
前記サーバ側プロキシから前記クライアント装置向けの情報をＴＣＰ通信により前記ネットワークを通じて受信し前記クライアント装置へ送信する第２の通信部と
を有し、
前記サーバ側プロキシは、
前記サーバ装置から前記クライアント装置向けの情報を受信してＴＣＰ通信により前記ネットワークを通じて前記クライアント側プロキシへ送信する第３の通信部と、
前記クライアント側プロキシから前記サーバ装置向けの情報をＴＣＰ通信により前記ネットワークを通じて受信し前記サーバ装置へ送信する第４の通信部と
を有し、
前記サーバ側プロキシは、
前記第３の通信部に存在する送信待ちの前記クライアント装置向けの情報の量が閾値以下である時に、前記ネットワークの混雑状況を調査するためのテストデータを前記ネットワークを通じて前記クライアント側プロキシとの間で送受信して前記ネットワークの混雑状況を判断するネットワーク状態確認部と、
前記判断された前記ネットワークの混雑状況に応じて前記ＴＣＰ通信のウィンドウサイズを制御するウィンドウサイズ調整部と
を有する
リモートデスクトップシステム。
前記クライアント装置に接続されるクライアント側プロキシと、
前記サーバ装置に接続されると共に前記ネットワークを介して前記クライアント側プロキシに接続されるサーバ側プロキシとを有し、
前記クライアント側プロキシは、
前記クライアント装置から前記サーバ装置向けの情報を受信してＴＣＰ通信により前記ネットワークを通じて前記サーバ側プロキシへ送信する第１の通信部と、
前記サーバ側プロキシから前記クライアント装置向けの情報をＴＣＰ通信により前記ネットワークを通じて受信し前記クライアント装置へ送信する第２の通信部と
を有し、
前記サーバ側プロキシは、
前記サーバ装置から前記クライアント装置向けの情報を受信してＴＣＰ通信により前記ネットワークを通じて前記クライアント側プロキシへ送信する第３の通信部と、
前記クライアント側プロキシから前記サーバ装置向けの情報をＴＣＰ通信により前記ネットワークを通じて受信し前記サーバ装置へ送信する第４の通信部と
を有し、
前記サーバ側プロキシは、
前記第３の通信部に存在する送信待ちの前記クライアント装置向けの情報の量が閾値以下である時に、前記ネットワークの混雑状況を調査するためのテストデータを前記ネットワークを通じて前記クライアント側プロキシとの間で送受信して前記ネットワークの混雑状況を判断するネットワーク状態確認部と、
前記判断された前記ネットワークの混雑状況に応じて前記ＴＣＰ通信のウィンドウサイズを制御するウィンドウサイズ調整部と
を有する
リモートデスクトップシステム。
【請求項2】
前記第３の通信部は、
中間バッファと、
前記サーバ装置から受信した前記情報を前記中間バッファに蓄積する受信処理部と、
該受信処理部と独立に動作し、前記中間バッファに蓄積された前記情報を読み出して前記クライアント側プロキシへ送信する送信処理部と
を有する請求項１に記載のリモートデスクトップシステム。
中間バッファと、
前記サーバ装置から受信した前記情報を前記中間バッファに蓄積する受信処理部と、
該受信処理部と独立に動作し、前記中間バッファに蓄積された前記情報を読み出して前記クライアント側プロキシへ送信する送信処理部と
を有する請求項１に記載のリモートデスクトップシステム。
【請求項3】
前記第３の通信部は、
自通信部に存在する送信待ちの前記クライアント装置向けの情報の送信順序を、前記情報の種別と該種別に対して予め定められた優先度とに基づいて決定する送信順序決定部
を有する請求項１または２に記載のリモートデスクトップシステム。
自通信部に存在する送信待ちの前記クライアント装置向けの情報の送信順序を、前記情報の種別と該種別に対して予め定められた優先度とに基づいて決定する送信順序決定部
を有する請求項１または２に記載のリモートデスクトップシステム。
【請求項4】
前記第３の通信部は、
自通信部に存在する送信待ちの前記クライアント装置向けの複数の画面イメージから、重複する画面イメージを削除する重複画面イメージ削除部
を有する請求項１乃至３の何れかに記載のリモートデスクトップシステム。
自通信部に存在する送信待ちの前記クライアント装置向けの複数の画面イメージから、重複する画面イメージを削除する重複画面イメージ削除部
を有する請求項１乃至３の何れかに記載のリモートデスクトップシステム。
【請求項5】
前記第３の通信部は、
前記サーバ装置から受信した画面イメージを用いて前記サーバ装置のデスクトップ画面の画面イメージを生成し、自通信部に存在する送信待ちの前記クライアント装置向けの画面イメージの総量が前記生成したデスクトップ画面の画面イメージの総量を上回る場合、前記送信待ちの前記クライアント装置向けの画面イメージを削除し、前記生成した前記デスクトップ画面の画面イメージを送信する画面生成部
を有する請求項１乃至４の何れかに記載のリモートデスクトップシステム。
前記サーバ装置から受信した画面イメージを用いて前記サーバ装置のデスクトップ画面の画面イメージを生成し、自通信部に存在する送信待ちの前記クライアント装置向けの画面イメージの総量が前記生成したデスクトップ画面の画面イメージの総量を上回る場合、前記送信待ちの前記クライアント装置向けの画面イメージを削除し、前記生成した前記デスクトップ画面の画面イメージを送信する画面生成部
を有する請求項１乃至４の何れかに記載のリモートデスクトップシステム。
【請求項6】
サーバ装置とクライアント装置とをネットワークを介してリモートデスクトップ接続する方法であって、
前記クライアント装置に接続されるクライアント側プロキシが、前記クライアント装置から前記サーバ装置向けの情報を受信し、ＴＣＰ通信により、前記ネットワークを通じて、前記サーバ装置に接続されるサーバ側プロキシへ送信し、
前記サーバ側プロキシが、前記クライアント側プロキシから前記サーバ装置向けの情報を、ＴＣＰ通信により、前記ネットワークを通じて受信し、前記サーバ装置へ送信し、
前記サーバ側プロキシが、前記サーバ装置から前記クライアント装置向けの情報を受信し、ＴＣＰ通信により、前記ネットワークを通じて、前記クライアント側プロキシへ送信し、
前記クライアント側プロキシが、前記サーバ側プロキシから前記クライアント装置向けの情報を、ＴＣＰ通信により、前記ネットワークを通じて受信し、前記クライアント装置へ送信し、
前記サーバ側プロキシが、送信待ちの前記クライアント装置向けの情報の量が閾値以下である時に、前記ネットワークの混雑状況を調査するためのテストデータを前記ネットワークを通じて前記クライアント装置側との間で送受信して前記ネットワークの混雑状況を判断し、前記判断した前記ネットワークの混雑状況に応じて前記ＴＣＰ通信のウィンドウサイズを制御する
リモートデスクトップ接続方法。
前記クライアント装置に接続されるクライアント側プロキシが、前記クライアント装置から前記サーバ装置向けの情報を受信し、ＴＣＰ通信により、前記ネットワークを通じて、前記サーバ装置に接続されるサーバ側プロキシへ送信し、
前記サーバ側プロキシが、前記クライアント側プロキシから前記サーバ装置向けの情報を、ＴＣＰ通信により、前記ネットワークを通じて受信し、前記サーバ装置へ送信し、
前記サーバ側プロキシが、前記サーバ装置から前記クライアント装置向けの情報を受信し、ＴＣＰ通信により、前記ネットワークを通じて、前記クライアント側プロキシへ送信し、
前記クライアント側プロキシが、前記サーバ側プロキシから前記クライアント装置向けの情報を、ＴＣＰ通信により、前記ネットワークを通じて受信し、前記クライアント装置へ送信し、
前記サーバ側プロキシが、送信待ちの前記クライアント装置向けの情報の量が閾値以下である時に、前記ネットワークの混雑状況を調査するためのテストデータを前記ネットワークを通じて前記クライアント装置側との間で送受信して前記ネットワークの混雑状況を判断し、前記判断した前記ネットワークの混雑状況に応じて前記ＴＣＰ通信のウィンドウサイズを制御する
リモートデスクトップ接続方法。
【請求項7】
リモートデスクトップシステムを構成するクライアント装置とサーバ装置のうち前記サーバ装置に接続されるプロキシ装置であって、
前記サーバ装置から前記クライアント装置向けの情報を受信してＴＣＰ通信により前記ネットワークを通じて前記クライアント装置側へ送信する第１の通信部と、
前記クライアント装置側から前記サーバ装置向けの情報をＴＣＰ通信により前記ネットワークを通じて受信し前記サーバ装置へ送信する第２の通信部と、
前記第１の通信部に存在する送信待ちの前記クライアント装置向けの情報の量が閾値以下である時に、前記ネットワークの混雑状況を調査するためのテストデータを前記ネットワークを通じて前記クライアント装置側との間で送受信して前記ネットワークの混雑状況を判断するネットワーク状態確認部と、
前記判断された前記ネットワークの混雑状況に応じて前記ＴＣＰ通信のウィンドウサイズを制御するウィンドウサイズ調整部と
を有するプロキシ装置。
前記サーバ装置から前記クライアント装置向けの情報を受信してＴＣＰ通信により前記ネットワークを通じて前記クライアント装置側へ送信する第１の通信部と、
前記クライアント装置側から前記サーバ装置向けの情報をＴＣＰ通信により前記ネットワークを通じて受信し前記サーバ装置へ送信する第２の通信部と、
前記第１の通信部に存在する送信待ちの前記クライアント装置向けの情報の量が閾値以下である時に、前記ネットワークの混雑状況を調査するためのテストデータを前記ネットワークを通じて前記クライアント装置側との間で送受信して前記ネットワークの混雑状況を判断するネットワーク状態確認部と、
前記判断された前記ネットワークの混雑状況に応じて前記ＴＣＰ通信のウィンドウサイズを制御するウィンドウサイズ調整部と
を有するプロキシ装置。
【請求項8】
前記第１の通信部は、
中間バッファと、
前記サーバ装置から受信した前記情報を前記中間バッファに蓄積する受信処理部と、
該受信処理部と独立に動作し、前記中間バッファに蓄積された前記情報を読み出して前記クライアント装置側へ送信する送信処理部と
を有する請求項７に記載のプロキシ装置。
中間バッファと、
前記サーバ装置から受信した前記情報を前記中間バッファに蓄積する受信処理部と、
該受信処理部と独立に動作し、前記中間バッファに蓄積された前記情報を読み出して前記クライアント装置側へ送信する送信処理部と
を有する請求項７に記載のプロキシ装置。
【請求項9】
前記第１の通信部は、
自通信部に存在する送信待ちの前記クライアント装置向けの情報の送信順序を、前記情報の種別と該種別に対して予め定められた優先度とに基づいて決定する送信順序決定部
を有する請求項７または８に記載のプロキシ装置。
自通信部に存在する送信待ちの前記クライアント装置向けの情報の送信順序を、前記情報の種別と該種別に対して予め定められた優先度とに基づいて決定する送信順序決定部
を有する請求項７または８に記載のプロキシ装置。
【請求項10】
前記第１の通信部は、
自通信部に存在する送信待ちの前記クライアント装置向けの複数の画面イメージから、重複する画面イメージを削除する重複画面イメージ削除部
を有する請求項７乃至９の何れかに記載のプロキシ装置。
自通信部に存在する送信待ちの前記クライアント装置向けの複数の画面イメージから、重複する画面イメージを削除する重複画面イメージ削除部
を有する請求項７乃至９の何れかに記載のプロキシ装置。
【請求項11】
前記第１の通信部は、
前記サーバ装置から受信した画面イメージを用いて前記サーバ装置のデスクトップ画面の画面イメージを生成し、自通信部に存在する送信待ちの前記クライアント装置向けの画面イメージの総量が前記生成したデスクトップ画面の画面イメージの総量を上回る場合、前記送信待ちの前記クライアント装置向けの画面イメージを削除し、前記生成した前記デスクトップ画面の画面イメージを送信する画面生成部
を有する請求項７乃至１０の何れかに記載のプロキシ装置。
前記サーバ装置から受信した画面イメージを用いて前記サーバ装置のデスクトップ画面の画面イメージを生成し、自通信部に存在する送信待ちの前記クライアント装置向けの画面イメージの総量が前記生成したデスクトップ画面の画面イメージの総量を上回る場合、前記送信待ちの前記クライアント装置向けの画面イメージを削除し、前記生成した前記デスクトップ画面の画面イメージを送信する画面生成部
を有する請求項７乃至１０の何れかに記載のプロキシ装置。
【請求項12】
リモートデスクトップシステムを構成するクライアント装置とサーバ装置のうち前記サーバ装置に接続されるプロキシ装置が実行するプロキシ方法であって、
前記サーバ装置から前記クライアント装置向けの情報を受信してＴＣＰ通信により前記ネットワークを通じて前記クライアント装置側へ送信し、
前記クライアント装置側から前記サーバ装置向けの情報をＴＣＰ通信により前記ネットワークを通じて受信し前記サーバ装置へ送信し、
送信待ちの前記クライアント装置向けの情報の量が閾値以下である時に、前記ネットワークの混雑状況を調査するためのテストデータを前記ネットワークを通じて前記クライアント装置側との間で送受信して前記ネットワークの混雑状況を判断し、
前記判断した前記ネットワークの混雑状況に応じて前記ＴＣＰ通信のウィンドウサイズを制御する
プロキシ方法。
前記サーバ装置から前記クライアント装置向けの情報を受信してＴＣＰ通信により前記ネットワークを通じて前記クライアント装置側へ送信し、
前記クライアント装置側から前記サーバ装置向けの情報をＴＣＰ通信により前記ネットワークを通じて受信し前記サーバ装置へ送信し、
送信待ちの前記クライアント装置向けの情報の量が閾値以下である時に、前記ネットワークの混雑状況を調査するためのテストデータを前記ネットワークを通じて前記クライアント装置側との間で送受信して前記ネットワークの混雑状況を判断し、
前記判断した前記ネットワークの混雑状況に応じて前記ＴＣＰ通信のウィンドウサイズを制御する
プロキシ方法。
【請求項13】
前記クライアント装置向けの情報の受信と送信では、
前記サーバ装置から受信した前記情報を中間バッファに蓄積する動作と、前記中間バッファに蓄積された前記情報を読み出して前記クライアント装置側へ送信する動作とを独立に並行して行う
請求項１２に記載のプロキシ方法。
前記サーバ装置から受信した前記情報を中間バッファに蓄積する動作と、前記中間バッファに蓄積された前記情報を読み出して前記クライアント装置側へ送信する動作とを独立に並行して行う
請求項１２に記載のプロキシ方法。
【請求項14】
送信待ちの前記クライアント装置向けの情報の送信順序を、前記情報の種別と該種別に対して予め定められた優先度とに基づいて決定する
請求項１２または１３に記載のプロキシ方法。
請求項１２または１３に記載のプロキシ方法。
【請求項15】
送信待ちの前記クライアント装置向けの複数の画面イメージから、重複する画面イメージを削除する
請求項１２乃至１４の何れかに記載のプロキシ方法。
請求項１２乃至１４の何れかに記載のプロキシ方法。
【請求項16】
前記サーバ装置から受信した画面イメージを用いて前記サーバ装置のデスクトップ画面の画面イメージを生成し、送信待ちの前記クライアント装置向けの画面イメージの総量が前記生成したデスクトップ画面の画面イメージの総量を上回る場合、前記送信待ちの前記クライアント装置向けの画面イメージを削除し、前記生成した前記デスクトップ画面の画面イメージを送信する
請求項１２乃至１５の何れかに記載のプロキシ方法。
請求項１２乃至１５の何れかに記載のプロキシ方法。
【請求項17】
リモートデスクトップシステムを構成するクライアント装置とサーバ装置のうち前記サーバ装置に接続されるプロキシ装置を構成するコンピュータを、
前記サーバ装置から前記クライアント装置向けの情報を受信してＴＣＰ通信により前記ネットワークを通じて前記クライアント装置側へ送信する第１の通信部と、
前記クライアント装置側から前記サーバ装置向けの情報をＴＣＰ通信により前記ネットワークを通じて受信し前記サーバ装置へ送信する第２の通信部と、
前記第１の通信部に存在する送信待ちの前記クライアント装置向けの情報の量が閾値以下である時に、前記ネットワークの混雑状況を調査するためのテストデータを前記ネットワークを通じて前記クライアント装置側との間で送受信して前記ネットワークの混雑状況を判断するネットワーク状態確認部と、
前記判断された前記ネットワークの混雑状況に応じて前記ＴＣＰ通信のウィンドウサイズを制御するウィンドウサイズ調整部と
して機能させるためのプログラム。
前記サーバ装置から前記クライアント装置向けの情報を受信してＴＣＰ通信により前記ネットワークを通じて前記クライアント装置側へ送信する第１の通信部と、
前記クライアント装置側から前記サーバ装置向けの情報をＴＣＰ通信により前記ネットワークを通じて受信し前記サーバ装置へ送信する第２の通信部と、
前記第１の通信部に存在する送信待ちの前記クライアント装置向けの情報の量が閾値以下である時に、前記ネットワークの混雑状況を調査するためのテストデータを前記ネットワークを通じて前記クライアント装置側との間で送受信して前記ネットワークの混雑状況を判断するネットワーク状態確認部と、
前記判断された前記ネットワークの混雑状況に応じて前記ＴＣＰ通信のウィンドウサイズを制御するウィンドウサイズ調整部と
して機能させるためのプログラム。
【請求項18】
前記第１の通信部は、
中間バッファと、
前記サーバ装置から受信した前記情報を前記中間バッファに蓄積する受信処理部と、
該受信処理部と独立に動作し、前記中間バッファに蓄積された前記情報を読み出して前記クライアント装置側へ送信する送信処理部と
を有する請求項１７に記載のプログラム。
中間バッファと、
前記サーバ装置から受信した前記情報を前記中間バッファに蓄積する受信処理部と、
該受信処理部と独立に動作し、前記中間バッファに蓄積された前記情報を読み出して前記クライアント装置側へ送信する送信処理部と
を有する請求項１７に記載のプログラム。
【請求項19】
前記第１の通信部は、
自通信部に存在する送信待ちの前記クライアント装置向けの情報の送信順序を、前記情報の種別と該種別に対して予め定められた優先度とに基づいて決定する送信順序決定部
を有する請求項１７または１８に記載のプログラム。
自通信部に存在する送信待ちの前記クライアント装置向けの情報の送信順序を、前記情報の種別と該種別に対して予め定められた優先度とに基づいて決定する送信順序決定部
を有する請求項１７または１８に記載のプログラム。
【請求項20】
前記第１の通信部は、
自通信部に存在する送信待ちの前記クライアント装置向けの複数の画面イメージから、重複する画面イメージを削除する重複画面イメージ削除部
を有する請求項１７乃至１９の何れかに記載のプログラム。
自通信部に存在する送信待ちの前記クライアント装置向けの複数の画面イメージから、重複する画面イメージを削除する重複画面イメージ削除部
を有する請求項１７乃至１９の何れかに記載のプログラム。
【請求項21】
前記第１の通信部は、
前記サーバ装置から受信した画面イメージを用いて前記サーバ装置のデスクトップ画面の画面イメージを生成し、自通信部に存在する送信待ちの前記クライアント装置向けの画面イメージの総量が前記生成したデスクトップ画面の画面イメージの総量を上回る場合、前記送信待ちの前記クライアント装置向けの画面イメージを削除し、前記生成した前記デスクトップ画面の画面イメージを送信する画面生成部
を有する請求項１７乃至２０の何れかに記載のプログラム。
前記サーバ装置から受信した画面イメージを用いて前記サーバ装置のデスクトップ画面の画面イメージを生成し、自通信部に存在する送信待ちの前記クライアント装置向けの画面イメージの総量が前記生成したデスクトップ画面の画面イメージの総量を上回る場合、前記送信待ちの前記クライアント装置向けの画面イメージを削除し、前記生成した前記デスクトップ画面の画面イメージを送信する画面生成部
を有する請求項１７乃至２０の何れかに記載のプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、リモートデスクトップシステム、リモートデスクトップ接続方法、プロキシ装置、プロキシ方法、およびプログラムに関する。
【背景技術】
【0002】
コンピュータのＧＵＩ（グラフィックユーザインタフェース）をネットワークを通じて接続された別の機器から操作するリモートデスクトップシステムが広く採用されている。リモートデスクトップシステムにおいて、ネットワークを介して制御されるコンピュータ側をサーバ装置、ユーザが操作を行う機器側をクライアント装置と呼ぶ。また、リモートデスクトップ接続に適する通信プロトコルとして、ＲＤＰ（Ｒｅｍｏｔｅ Ｄｅｓｋｔｏｐ Ｐｒｏｔｏｃｏｌ）がある。このＲＤＰはアプリケーション層のプロトコルである。
【0003】
他方、機能拡張のためにサーバ装置およびクライアント装置のそれぞれにプロキシを設けてサーバ装置とクライアント装置との間でプロキシを介してデータの授受を行うことが本発明に関連する第１の関連技術として知られている（例えば特許文献１参照）。上記第１の関連技術では、リモートデスクトップクライアントとしての複合機と中継装置としてのプロキシサーバとがバスを介して接続されたイントラネットと、リモートデスクトップサーバとしてのコールセンタの端末装置と、中継装置としてのプロキシサーバとを、インターネットを介して接続している。
【0004】
また、遠隔にある端末に対して大容量データを効率良く高速転送するためにプロキシ間をＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）接続し、定期的に再送制御とフロー制御を行いながらＵＤＰを使用してデータ転送を行うことが本発明に関連する第２の関連技術として提案されている（例えば特許文献２参照）。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開２００８−２７０９７２号公報
【特許文献2】特開２００５−１３６６８４号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
しかしながら、プロキシ間の通信をＵＤＰで行うリモートデスクトップシステムでは、パケットロスが発生すると、クライアント装置からサーバ装置に向けて送信されるコマンド等の欠落や、反対にサーバ装置からクライアント装置に向けて送信される応答や画面データ等の欠落が生じる。このため、パケットロスの多い通信環境ではリモートデスクトップ接続は困難である。また特許文献２の技術を特許文献１に適用してプロキシ間で定期的に再送制御とフロー制御を行いながらＵＤＰを使用してデータ転送を行う構成では、パケットロスが発生した際のリカバリや順序制御を独自に開発してプロキシに実装する必要がある。
【0007】
本発明の目的は、上述した課題、すなわち、プロキシ間の通信をＵＤＰで行うリモートデスクトップシステムでは、パケットロスが発生した際のリカバリや順序制御を独自開発しなければリモートデスクトップ接続は困難である、という課題を解決するリモートデスクトップシステムを提供することにある。
【課題を解決するための手段】
【0008】
本発明の第１の観点に係るリモートデスクトップシステムは、サーバ装置とクライアント装置とがネットワークを介して接続されたリモートデスクトップシステムであって、
上記クライアント装置に接続されるクライアント側プロキシと、
上記サーバ装置に接続されると共に上記ネットワークを介して上記クライアント側プロキシに接続されるサーバ側プロキシとを有し、
上記クライアント側プロキシは、
上記クライアント装置から上記サーバ装置向けの情報を受信してＴＣＰ通信により上記ネットワークを通じて上記サーバ側プロキシへ送信する第１の通信部と、
上記サーバ側プロキシから上記クライアント装置向けの情報をＴＣＰ通信により上記ネットワークを通じて受信し上記クライアント装置へ送信する第２の通信部と
を有し、
上記サーバ側プロキシは、
上記サーバ装置から上記クライアント装置向けの情報を受信してＴＣＰ通信により上記ネットワークを通じて上記クライアント側プロキシへ送信する第３の通信部と、
上記クライアント側プロキシから上記サーバ装置向けの情報をＴＣＰ通信により上記ネットワークを通じて受信し上記サーバ装置へ送信する第４の通信部と
を有する。
【0009】
本発明の第２の観点に係るリモートデスクトップ接続方法は、サーバ装置とクライアント装置とをネットワークを介してリモートデスクトップ接続する方法であって、
上記クライアント装置に接続されるクライアント側プロキシが、上記クライアント装置から上記サーバ装置向けの情報を受信し、ＴＣＰ通信により、上記ネットワークを通じて、上記サーバ装置に接続されるサーバ側プロキシへ送信し、
上記サーバ側プロキシが、上記クライアント側プロキシから上記サーバ装置向けの情報を、ＴＣＰ通信により、上記ネットワークを通じて受信し、上記サーバ装置へ送信し、
上記サーバ側プロキシが、上記サーバ装置から上記クライアント装置向けの情報を受信し、ＴＣＰ通信により、上記ネットワークを通じて、上記クライアント側プロキシへ送信し、
上記クライアント側プロキシが、上記サーバ側プロキシから上記クライアント装置向けの情報を、ＴＣＰ通信により、上記ネットワークを通じて受信し、上記クライアント装置へ送信する。
【0010】
本発明の第３の観点に係るプロキシ装置は、リモートデスクトップシステムを構成するクライアント装置とサーバ装置のうち上記サーバ装置に接続されるプロキシ装置であって、
上記サーバ装置から上記クライアント装置向けの情報を受信してＴＣＰ通信により上記ネットワークを通じて上記クライアント装置側へ送信する第１の通信部と、
上記クライアント装置側から上記サーバ装置向けの情報をＴＣＰ通信により上記ネットワークを通じて受信し上記サーバ装置へ送信する第２の通信部と
を有する。
【0011】
本発明の第４の観点に係るプロキシ方法は、リモートデスクトップシステムを構成するクライアント装置とサーバ装置のうち上記サーバ装置に接続されるプロキシ装置が実行するプロキシ方法であって、
上記サーバ装置から上記クライアント装置向けの情報を受信してＴＣＰ通信により上記ネットワークを通じて上記クライアント装置側へ送信し、
上記クライアント装置側から上記サーバ装置向けの情報をＴＣＰ通信により上記ネットワークを通じて受信し上記サーバ装置へ送信する。
本発明の第５の観点に係るプログラムは、
リモートデスクトップシステムを構成するクライアント装置とサーバ装置のうち上記サーバ装置に接続されるプロキシ装置を構成するコンピュータを、
上記サーバ装置から上記クライアント装置向けの情報を受信してＴＣＰ通信により上記ネットワークを通じて上記クライアント装置側へ送信する第１の通信部と、
上記クライアント装置側から上記サーバ装置向けの情報をＴＣＰ通信により上記ネットワークを通じて受信し上記サーバ装置へ送信する第２の通信部と
して機能させる。
【発明の効果】
【0012】
本発明は上述した構成を有するため、パケットロスが発生した際のリカバリや順序制御を独自に開発しなくてもパケットロスが多発する通信環境においてリモートデスクトップ接続を利用することが可能になる。
【図面の簡単な説明】
【0013】
【図1】本発明の第１の実施形態のブロック図である。
【図2】本発明の第２の実施形態のブロック図である。
【図3】本発明の第３の実施形態のブロック図である。
【図4】本発明の第３の実施形態においてネットワークのデータ転送時間を用いて送受信に使用するソケットバッファのサイズを変更する際に使用する式を示す図である。
【図5】本発明の第３の実施形態におけるサーバ側プロキシモジュールのネットワーク状態確認部の処理の一例を示すフローチャートである。
【図6】本発明の第３の実施形態におけるクライアント側プロキシモジュールのネットワーク状態確認部の処理の一例を示すフローチャートである。
【図7】本発明の第４の実施形態の要部ブロック図である。
【図8】本発明の第４の実施形態における通信部の処理の一例を示すフローチャートである。
【発明を実施するための形態】
【0014】
次に本発明の実施の形態について図面を参照して詳細に説明する。[第１の実施形態]
図１を参照すると、本発明の第１の実施形態にかかるリモートデスクトップシステム１００は、サーバ装置１１０とクライアント装置１２０とがネットワーク１３０を介して接続されている。またサーバ装置１１０とネットワーク１３０との間にはサーバ側プロキシ１４０が介在し、クライアント装置１２０とネットワーク１３０との間にはクライアント側プロキシ１５０が介在する。
【0015】
クライアント側プロキシ１５０は、第１の通信部１５１と第２の通信部１５２とを有する。第１の通信部１５１は、クライアント装置１２０からサーバ装置１１０向けの情報を受信し、ＴＣＰ通信によりネットワーク１３０を通じてサーバ側プロキシ１４０へ送信する機能を有する。第２の通信部１５２は、サーバ側プロキシ１４０からクライアント装置１２０向けの情報をＴＣＰ通信によりネットワーク１３０を通じて受信し、クライアント装置１２０へ送信する機能を有する。
【0016】
サーバ側プロキシ１４０は、第３の通信部１４１と第４の通信部１４２とを有する。第３の通信部１４１は、サーバ装置１１０からクライアント装置１２０向けの情報を受信し、ＴＣＰ通信によりネットワーク１３０を通じてクライアント側プロキシ１５０へ送信する機能を有する。第４の通信部１４２は、クライアント側プロキシ１５０からサーバ装置１１０向けの情報をＴＣＰ通信によりネットワーク１３０を通じて受信し、サーバ装置１１０へ送信する機能を有する。
【0017】
上記クライアント側プロキシ１５０は、クライアント装置１２０と物理的に同じ装置あるいは異なる装置の何れに実装されていても良い。また上記サーバ側プロキシ１４０は、サーバ装置１１０と物理的に同じ装置あるいは異なる装置の何れに実装されていても良い。
【0018】
次に本実施形態に係るリモートデスクトップシステム１００の動作を説明する。
【0019】
リモートデスクトップシステム１００では、クライアント装置１２０からサーバ装置１１０に向けて、遠隔操作に必要なコマンド等の各種情報（以下、サーバ装置向けの情報と称す）が送信される。他方、サーバ装置１１０からクライアント装置１２０に向けて、コマンドに対する応答データやＧＵＩの画面データ等（以下、クライアント向けの情報と称す）が送信される。これらサーバ装置向けの情報およびクライアント向けの情報は、本実施形態では以下のようにして送受信される。
【0020】
サーバ装置向けの情報は、まず、クライアント装置１２０からクライアント側プロキシ１５０に送信される。クライアント側プロキシ１５０の第１の通信部１５１は、クライアント装置１２０からサーバ装置向けの情報を受信すると、ＴＣＰ通信により、ネットワーク１３０を通じて、サーバ側プロキシ１４０へ送信する。サーバ側プロキシ１０の第４の通信部１４２は、クライアント側プロキシ１５０からサーバ装置向けの情報をＴＣＰ通信によりネットワーク１３０を通じて受信し、サーバ装置１１０へ送信する。
【0021】
これによって、クライアント装置１２０から送信されたサーバ装置向けの情報が、クライアント側プロキシ１５０、ネットワーク１３０、およびサーバ側プロキシ１４０を経由して、サーバ装置１１０へ届けられる。若し、ネットワーク１３０においてパケットロスが発生した場合、第１の通信部１５１はＴＣＰ通信によるＡＣＫを第４の通信部１４２から受信できないため、パケットの再送を行う。これによって、クライアント装置１２０から送信されたサーバ装置向けの情報がサーバ装置１１０に確実に届けられる。
【0022】
他方、クライアント装置向けの情報は、まず、サーバ装置１１０からサーバ側プロキシ１４０に送信される。サーバ側プロキシ１４０の第３の通信部１４１は、サーバ装置１１０からクライアント装置向けの情報を受信すると、ＴＣＰ通信により、ネットワーク１３０を通じて、クライアント側プロキシ１５０へ送信する。クライアント側プロキシ１５０の第２の通信部１５２は、サーバ側プロキシ１４０からクライアント装置向けの情報をＴＣＰ通信によりネットワーク１３０を通じて受信し、クライアント装置１２０へ送信する。
【0023】
これによって、サーバ装置１１０から送信されたクライアント装置向けの情報が、サーバ側プロキシ１４０、ネットワーク１３０、およびクライアント側プロキシ１５０を経由して、クライアント装置１２０へ届けられる。若し、ネットワーク１３０においてパケットロスが発生した場合、第３の通信部１４１はＴＣＰ通信によるＡＣＫを第２の通信部１５２から受信できないため、パケットの再送を行う。これによって、サーバ装置１１０から送信されたクライアント装置向けの情報がクライアント装置１２０に確実に届けられる。
【0024】
このように本実施形態によれば、プロキシ間のネットワーク経由の通信でパケットロスが発生した際、リカバリや順序制御がＴＣＰによって自動的に実施されるため、パケットロスが発生した際のリカバリや順序制御を独自に開発しなくてもパケットロスが多発する通信環境においてリモートデスクトップ接続を利用することが可能になる。
【0025】
[第２の実施形態]図２を参照すると、本発明の第２の実施形態にかかるリモートデスクトップシステム２００は、情報処理装置２１０と情報処理装置２２０とがネットワーク２３０を介して接続されている。
【0026】
情報処理装置２１０は、リモートデスクトップサーバモジュール２４０と、サーバ側プロキシモジュール２５０と、ＴＣＰ通信部２６０とを有する。リモートデスクトップサーバモジュール２４０は、情報処理装置２１０をリモートデスクトップシステムにおけるサーバ装置として機能させるためのプログラムモジュールである。ＴＣＰ通信部２６０は、情報処理装置２１０がネットワーク２３０を介して情報処理装置２２０等の他の装置とＴＣＰ通信を行うためのプログラムモジュールである。サーバ側プロキシモジュール２５０は、リモートデスクトップサーバモジュール２４０とＴＣＰ通信部２６０との間に介在するプログラムモジュールである。このサーバ側プロキシモジュール２５０を省略し、リモートデスクトップサーバモジュール２４０をＴＣＰ通信部２６０に接続する構成でもリモートデスクトップ接続は基本的に可能であるが、サーバ側の機能拡張のために、サーバ側プロキシモジュール２５０を介在させるようにしている。
【0027】
また情報処理装置２２０は、リモートデスクトップクライアントモジュール２７０と、クライアント側プロキシモジュール２８０と、ＴＣＰ通信部２９０とを有する。リモートデスクトップクライアントモジュール２８０は、情報処理装置２２０をリモートデスクトップシステムにおけるクライアント装置として機能させるためのプログラムモジュールである。ＴＣＰ通信部２９０は、情報処理装置２２０がネットワーク２３０を介して情報処理装置２１０等の他の装置とＴＣＰ通信を行うためのプログラムモジュールである。クライアント側プロキシモジュール２８０は、リモートデスクトップクライアントモジュール２７０とＴＣＰ通信部２９０との間に介在するプログラムモジュールである。このクライアント側プロキシモジュール２８０を省略し、リモートデスクトップクライアントモジュール２７０をＴＣＰ通信部２７０に接続する構成でもリモートデスクトップ接続は基本的に可能であるが、クライアント側の機能拡張のために、クライアント側プロキシモジュール２８０を介在させるようにしている。
【0028】
クライアント側プロキシモジュール２８０は、通信部２８１と通信部２８２とを有する。
【0029】
通信部２８１は、リモートデスクトップクライアントモジュール２７０から、遠隔操作に必要なコマンド等の各種情報（サーバ装置向けの情報）を受信し、ＴＣＰ通信部２９０の機能を使ってＴＣＰ通信によりネットワーク２３０を通じてサーバ側の情報処理装置２１０へ送信する機能を有する。通信部２８１は、受信部２８１１と中間バッファ２８１２と送信部２８１３とを有する。
【0030】
中間バッファ２８１２は、サーバ装置向けの情報を一時的に蓄積するバッファメモリである。
【0031】
受信部２８１１は、リモートデスクトップクライアントモジュール２７０から受信したサーバ装置向けの情報を中間バッファ２８１２に格納する機能を有する。受信部２８１１は、受信バッファ２８１１１と受信処理部２８１１２とを有する。受信バッファ２８１１１は、リモートデスクトップクライアントモジュール２７０からリモートデスクトップサーバモジュール２４０に送るサーバ装置向けの情報を一時的に蓄積するバッファである。リモートデスクトップクライアントモジュール２７０は、リモートデスクトップサーバモジュール２４０に対してサーバ装置向けの情報を送信する場合、送信する情報を受信バッファ２８１１１に書き込む。受信処理部２８１１２は、受信バッファ２８１１１に書き込まれた情報を読み出して、中間バッファ２８１２に書き込む機能を有する。
【0032】
送信部２８１３は、中間バッファ２８１２に蓄積されたサーバ装置向けの情報をＴＣＰ通信部２９０の機能を使ってＴＣＰ通信によりネットワーク２３０を通じて情報処理装置２１０へ送信する機能を有する。送信部２８１３は、送信処理部２８１３１と送信バッファ２８１３２とを有する。送信処理部２８１３１は、中間バッファ２８１２に蓄積されたサーバ装置向けの情報を読み出して送信バッファ２８１３２に書き込む機能を有する。送信バッファ２８１３２に書き込まれた情報はＴＣＰ通信部２９０によって読み出され、ネットワーク２３０を通じて情報処理装置２１０へ送信される。
【0033】
例えば、通信部２８１は１つのアプリケーション（プロセス）で構成され、受信バッファ２８１１１および送信バッファ２８１３２はソケット（Ｓｏｃｋｅｔ）バッファで構成される。また受信部２８１１と送信部２８１３とはそれぞれ１つのスレッドとして動作する。このため、受信部２８１１と送信部２８１３とは独立に並行して動作する。
【0034】
通信部２８２は、サーバ側の情報処理装置２１０からＴＣＰ通信部２９０およびネットワーク２３０を通じてＴＣＰ通信によって、コマンドに対する応答データやＧＵＩの画面データ等（クライアント向けの情報）を受信し、リモートデスクトップクライアントモジュール２７０へ送信する機能を有する。通信部２８２は、受信部２８２１と中間バッファ２８２２と送信部２８２３とを有する。
【0035】
中間バッファ２８２２は、クライアント装置向けの情報を一時的に蓄積するバッファメモリである。
【0036】
受信部２８２１は、ＴＣＰ通信部２９０から受信したクライアント装置向けの情報を中間バッファ２８２２に格納する機能を有する。受信部２８２１は、受信バッファ２８２１１と受信処理部２８２１２とを有する。受信バッファ２８２１１は、情報処理装置２１０から受信したクライアント装置向けの情報を一時的に蓄積するバッファである。ＴＣＰ通信部２９０は、ネットワーク２３０を通じて情報処理装置２１０のリモートデスクトップサーバモジュール２４０からクライアント装置向けの情報を受信すると、この受信した情報を受信バッファ２８２１１に書き込む。受信処理部２８２１２は、受信バッファ２８２１１に書き込まれた情報を読み出して、中間バッファ２８２２に書き込む機能を有する。
【0037】
送信部２８２３は、中間バッファ２８２２に蓄積されたクライアント装置向けの情報をリモートデスクトップクライアントモジュール２７０へ送信する機能を有する。送信部２８２３は、送信処理部２８２３１と送信バッファ２８２３２とを有する。送信処理部２８２３１は、中間バッファ２８２２に蓄積されたクライアント装置向けの情報を読み出して送信バッファ２８２３２に書き込む機能を有する。送信バッファ２８２３２に書き込まれた情報はリモートデスクトップクライアントモジュール２７０によって読み出される。
【0038】
例えば、通信部２８２は１つのアプリケーション（プロセス）で構成され、受信バッファ２８２１１および送信バッファ２８２３２はソケット（Ｓｏｃｋｅｔ）バッファで構成される。また受信部２８２１と送信部２８２３とはそれぞれ１つのスレッドとして動作する。このため、受信部２８２１と送信部２８２３とは独立に並行して動作する。
【0039】
サーバ側プロキシモジュール２５０は、通信部２５１と通信部２５２とを有する。
【0040】
通信部２５１は、リモートデスクトップサーバモジュール２４０から、クライアント向けの情報を受信し、ＴＣＰ通信部２６０の機能を使ってＴＣＰ通信によりネットワーク２３０を通じてクライアント側の情報処理装置２２０へ送信する機能を有する。通信部２５１は、受信部２５１１と中間バッファ２５１２と送信部２５１３とを有する。
【0041】
中間バッファ２５１２は、クライアント装置向けの情報を一時的に蓄積するバッファメモリである。
【0042】
受信部２５１１は、リモートデスクトップサーバモジュール２４０から受信したクライアント装置向けの情報を中間バッファ２５１２に格納する機能を有する。受信部２５１１は、受信バッファ２５１１１と受信処理部２５１１２とを有する。受信バッファ２５１１１は、リモートデスクトップサーバモジュール２４０からリモートデスクトップクライアントモジュール２７０に送るクライアント装置向けの情報を一時的に蓄積するバッファである。リモートデスクトップサーバモジュール２４０は、リモートデスクトップクライアントモジュール２７０に対してクライアント装置向けの情報を送信する場合、送信する情報を受信バッファ２５１１１に書き込む。受信処理部２５１１２は、受信バッファ２５１１１に書き込まれた情報を読み出して、中間バッファ２５１２に書き込む機能を有する。
【0043】
送信部２５１３は、中間バッファ２５１２に蓄積されたクライアント装置向けの情報をＴＣＰ通信部２６０の機能を使ってＴＣＰ通信によりネットワーク２３０を通じて情報処理装置２２０へ送信する機能を有する。送信部２５１３は、送信処理部２５１３１と送信バッファ２５１３２とを有する。送信処理部２５１３１は、中間バッファ２５１２に蓄積されたクライアント装置向けの情報を読み出して送信バッファ２５１３２に書き込む機能を有する。送信バッファ２５１３２に書き込まれた情報はＴＣＰ通信部２６０によって読み出され、ネットワーク２３０を通じて情報処理装置２２０へ送信される。
【0044】
例えば、通信部２５１は１つのアプリケーション（プロセス）で構成され、受信バッファ２５１１１および送信バッファ２５１３２はソケット（Ｓｏｃｋｅｔ）バッファで構成される。また受信部２５１１と送信部２５１３とはそれぞれ１つのスレッドとして動作する。このため、受信部２５１１と送信部２５１３とは独立に並行して動作する。
【0045】
通信部２５２は、クライアント側の情報処理装置２２０からＴＣＰ通信部２６０およびネットワーク２３０を通じてＴＣＰ通信によって、サーバ装置向けの情報を受信し、リモートデスクトップサーバモジュール２４０へ送信する機能を有する。通信部２５２は、受信部２５２１と中間バッファ２５２２と送信部２５２３とを有する。
【0046】
中間バッファ２５２２は、サーバ装置向けの情報を一時的に蓄積するバッファメモリである。
【0047】
受信部２５２１は、ＴＣＰ通信部２６０から受信したサーバ装置向けの情報を中間バッファ２５２２に格納する機能を有する。受信部２５２１は、受信バッファ２５２１１と受信処理部２５２１２とを有する。受信バッファ２５２１１は、情報処理装置２２０から受信したサーバ装置向けの情報を一時的に蓄積するバッファである。ＴＣＰ通信部２６０は、ネットワーク２３０を通じて情報処理装置２２０のリモートデスクトップサーバモジュール２７０からサーバ装置向けの情報を受信すると、この受信した情報を受信バッファ２５２１１に書き込む。受信処理部２５２１２は、受信バッファ２５２１１に書き込まれた情報を読み出して、中間バッファ２５２２に書き込む機能を有する。
【0048】
送信部２５２３は、中間バッファ２５２２に蓄積されたサーバ装置向けの情報をリモートデスクトップサーバモジュール２４０へ送信する機能を有する。送信部２５２３は、送信処理部２５２３１と送信バッファ２５２３２とを有する。送信処理部２５２３１は、中間バッファ２５２２に蓄積されたサーバ装置向けの情報を読み出して送信バッファ２５２３２に書き込む機能を有する。送信バッファ２５２３２に書き込まれた情報はリモートデスクトップサーバモジュール２４０によって読み出される。
【0049】
例えば、通信部２５２は１つのアプリケーション（プロセス）で構成され、受信バッファ２５２１１および送信バッファ２５２３２はソケット（Ｓｏｃｋｅｔ）バッファで構成される。また受信部２５２１と送信部２５２３とはそれぞれ１つのスレッドとして動作する。このため、受信部２５２１と送信部２５２３とは独立に並行して動作する。
【0050】
次に本実施形態に係るリモートデスクトップシステム２００の動作を説明する。
【0051】
リモートデスクトップシステム２００では、情報処理装置２２０のリモートデスクトップクライアントモジュール２７０から情報処理装置２１０のリモートデスクトップサーバモジュール２４０に向けて、遠隔操作に必要なコマンド等の各種情報（サーバ装置向けの情報）が送信される。他方、情報処理装置２１０のリモートデスクトップサーバモジュール２４０から情報処理装置２２０のリモートデスクトップクライアントモジュール２７０に向けて、コマンドに対する応答データやＧＵＩの画面データ等（クライアント装置向けの情報）が送信される。これらサーバ装置向けの情報およびクライアント装置向けの情報は、本実施形態では以下のようにして送受信される。
【0052】
まず、リモートデスクトップクライアントモジュール２７０は、サーバ装置向けの情報をクライアント側プロキシモジュール２８０の通信部２８１の受信部２８１１における受信バッファ２８１１１に書き込む。
【0053】
次に、通信部２８１の受信処理部２８１１２は、サーバ装置向けの情報が受信バッファ２８１１１に蓄積されると、それを読み出して、中間バッファ２８１２に書き込む。
【0054】
次に、通信部２８１の送信部２８１３の送信処理部２８１３１は、サーバ装置向けの情報が中間バッファ２８１２に蓄積されると、それを読み出して、送信バッファ２８１３２に書き込む。
【0055】
次に、ＴＣＰ通信部２９０は、送信バッファ２８１３２にサーバ装置向けの情報が蓄積されると、それを読み出して、ネットワーク２３０を通じてＴＣＰ通信により情報処理装置２１０のリモートデスクトップサーバモジュール２４０宛に送信する。
【0056】
情報処理装置２１０のＴＣＰ通信部２６０は、ＴＣＰ通信部２９０によって送信されたサーバ装置向けの情報を受信すると、受信した情報をサーバ側プロキシモジュール２５０の通信部２５２の受信部２５２１における受信バッファ２５２１１に書き込む。
【0057】
受信部２５２１の受信処理部２５２１２は、サーバ装置向けの情報が受信バッファ２５２１１に蓄積されると、それを読み出して、中間バッファ２５２２に書き込む。
【0058】
通信部２５２の送信部における送信処理部２５２３１は、中間バッファ２５２２にサーバ装置向けの情報が蓄積されると、それを読み出して、送信バッファ２５２３２に書き込む。
【0059】
リモートデスクトップサーバモジュール２４０は、送信バッファ２５２３２にサーバ装置向けの情報が蓄積されると、それを読み出す。そして、リモートデスクトップサーバモジュール２４０は、読み出した情報に応じた処理を実行する。
【0060】
以上のような動作によって、リモートデスクトップクライアントモジュール２７０から送信されたサーバ装置向けの情報が、クライアント側プロキシモジュール２８０の通信部２８１、ＴＣＰ通信部２９０、ネットワーク２３０、ＴＣＰ通信部２６０、サーバ側プロキシモジュール２５０の通信部２５２を経由して、リモートデスクトップサーバモジュール２４０へ届けられ、その情報に応じたサーバ処理が実行されることになる。若し、ネットワーク２３０においてパケットロスが発生した場合、ＴＣＰ通信部２９０はＴＣＰ通信によるＡＣＫをＴＣＰ通信部２６０から受信できないため、パケットの再送を行う。これによって、サーバ装置向けの情報が情報処理装置２２０から情報処理装置２１０に確実に届けられる。
【0061】
また、通信部２５２、２８１は、中間バッファ２５２２、２８１２と、互いに独立して動作する受信部２５２１、２８１１および送信部２５２３、２８１３とから構成されているため、それぞれの通信部２５２、２８１では、送信動作の影響を受けずに受信動作が行え、その逆に受信動作の影響を受けずに送信動作が行える。例えば、通信部２８１の場合、ネットワーク２３０の通信状態が悪化して送信バッファ２８１３２が満杯になり送信部２８１３の送信が一時的に停止したとしても、中間バッファ２８１２に空きがある限り、受信部２８１１はリモートデスクトップクライアントモジュール２７０からサーバ装置向けの情報を受信し続けることができる。これによってネットワーク２３０の通信状態の悪化によってリモートデスクトップクライアントモジュール２７０の動作が停止するのを防止できる。
【0062】
次に、クライアント装置向けの情報を送受信する動作について説明する。
【0063】
まず、リモートデスクトップサーバモジュール２４０は、クライアント装置向けの情報をサーバ側プロキシモジュール２５０の通信部２５１の受信部２５１１における受信バッファ２５１１１に書き込む。
【0064】
次に、通信部２５１の受信処理部２５１１２は、クライアント装置向けの情報が受信バッファ２５１１１に蓄積されると、それを読み出して、中間バッファ２５１２に書き込む。
【0065】
次に、通信部２５１の送信部２５１３の送信処理部２５１３１は、クライアント装置向けの情報が中間バッファ２５１２に蓄積されると、それを読み出して、送信バッファ２５１３２に書き込む。
【0066】
次に、ＴＣＰ通信部２６０は、送信バッファ２５１３２にクライアント装置向けの情報が蓄積されると、それを読み出して、ネットワーク２３０を通じてＴＣＰ通信により情報処理装置２２０のリモートデスクトップクライアントモジュール２７０宛に送信する。
【0067】
情報処理装置２２０のＴＣＰ通信部２９０は、ＴＣＰ通信部２６０によって送信されたクライアント装置向けの情報を受信すると、受信した情報をクライアント側プロキシモジュール２８０の通信部２８２の受信部２８２１における受信バッファ２８２１１に書き込む。
【0068】
受信部２８２１の受信処理部２８２１２は、クライアント装置向けの情報が受信バッファ２８２１１に蓄積されると、それを読み出して、中間バッファ２８２２に書き込む。
【0069】
通信部２８２の送信部における送信処理部２８２３１は、中間バッファ２８２２にクライアント装置向けの情報が蓄積されると、それを読み出して、送信バッファ２８２３２に書き込む。
【0070】
リモートデスクトップクライアントモジュール２７０は、送信バッファ２８２３２にクライアント装置向けの情報が蓄積されると、それを読み出す。そして、リモートデスクトップサーバクライアントモジュール２７０は、読み出した情報に応じた処理を実行する。
【0071】
以上のような動作によって、リモートデスクトップサーバモジュール２４０から送信されたクライアント装置向けの情報が、サーバ側プロキシモジュール２５０の通信部２５１、ＴＣＰ通信部２６０、ネットワーク２３０、ＴＣＰ通信部２９０、サーバ側プロキシモジュール２８０の通信部２８２を経由して、リモートデスクトップクライアントモジュール２７０へ届けられ、その情報に応じたクライアント処理が実行されることになる。若し、ネットワーク２３０においてパケットロスが発生した場合、ＴＣＰ通信部２６０はＴＣＰ通信によるＡＣＫをＴＣＰ通信部２９０から受信できないため、パケットの再送を行う。これによって、クライアント装置向けの情報が情報処理装置２１０から情報処理装置２２０に確実に届けられる。
【0072】
また、通信部２５１、２８２は、中間バッファ２５１２、２８２２と、互いに独立して動作する受信部２５１１、２８２１および送信部２５１３、２８２２とから構成されているため、それぞれの通信部２５１、２８２では、送信動作の影響を受けずに受信動作が行え、その逆に受信動作の影響を受けずに送信動作が行える。例えば、通信部２５１の場合、ネットワーク２３０の通信状態が悪化して送信バッファ２５１３２が満杯になり送信部２５１３の動作が一時的に停止したとしても、中間バッファ２５１２に空きがある限り、受信部２５１１はリモートデスクトップサーバモジュール２４０からクライアント装置向けの情報を受信し続けることができる。これによってネットワーク２３０の通信状態の悪化によってリモートデスクトップサーバモジュール２４０の動作が停止するのを防止できる。
【0073】
[第３の実施形態]図３を参照すると、本発明の第３の実施形態にかかるリモートデスクトップシステム３００は、情報処理装置３１０と情報処理装置３２０とがネットワーク３３０を介して接続されている。
【0074】
情報処理装置３１０は、リモートデスクトップサーバモジュール３４０と、サーバ側プロキシモジュール３５０と、ＴＣＰ通信部３６０とを有する。リモートデスクトップサーバモジュール３４０およびＴＣＰ通信部３６０は、図２に示した第２の実施形態におけるリモートデスクトップサーバモジュール２４０およびＴＣＰ通信部２６０と同じ機能を有する。サーバ側プロキシモジュール３５０は、通信部３５１と通信部３５２とネットワーク状態確認部３５３とウインドウサイズ調整部３５４とを有する。通信部３５１および通信部３５２は、図２に示した第２の実施形態における通信部２５１および通信部２５２と同じ機能を有する。すなわち、通信部３５１が有する受信部３５１１、中間バッファ３５１２、送信部３５１３、上記受信部３５１１が有する受信バッファ３５１１１、受信処理部３５１１２、上記送信部３５１３が有する送信処理部３５１３１、送信バッファ３５１３２は、図２に示した第２の実施形態における通信部２５１が有する受信部２５１１、中間バッファ２５１２、送信部２５１３、上記受信部２５１１が有する受信バッファ２５１１１、受信処理部２５１１２、上記送信部２５１３が有する送信処理部２５１３１、送信バッファ２５１３２と同じ機能を有する。また、通信部３５２が有する受信部３５２１、中間バッファ３５２２、送信部３５２３、上記受信部３５２１が有する受信バッファ３５２１１、受信処理部３５２１２、上記送信部３５２３が有する送信処理部３５２３１、送信バッファ３５２３２は、図２に示した第２の実施形態における通信部２５２が有する受信部２５２１、中間バッファ２５２２、送信部２５２３、上記受信部２５２１が有する受信バッファ２５２１１、受信処理部２５２１２、上記送信部２５２３が有する送信処理部２５２３１、送信バッファ２５２３２と同じ機能を有する。
【0075】
また情報処理装置３２０は、リモートデスクトップクライアントモジュール３７０と、クライアント側プロキシモジュール３８０と、ＴＣＰ通信部３９０とを有する。リモートデスクトップクライアントモジュール３７０およびＴＣＰ通信部３９０は、図２に示した第２の実施形態におけるリモートデスクトップクライアントモジュール２７０およびＴＣＰ通信部２９０と同じ機能を有する。クライアント側プロキシモジュール３８０は、通信部３８１と通信部３８２とネットワーク状態確認部３８３とウインドウサイズ調整部３８４とを有する。通信部３８１および通信部３８２は、図２に示した第２の実施形態における通信部２８１および通信部２８２と同じ機能を有する。すなわち、通信部３８１が有する受信部３８１１、中間バッファ３８１２、送信部３８１３、上記受信部３８１１が有する受信バッファ３８１１１、受信処理部３８１１２、上記送信部３８１３が有する送信処理部３８１３１、送信バッファ３８１３２は、図２に示した第２の実施形態における通信部２８１が有する受信部２８１１、中間バッファ２８１２、送信部２８１３、上記受信部２８１１が有する受信バッファ２８１１１、受信処理部２８１１２、上記送信部２８１３が有する送信処理部２８１３１、送信バッファ２８１３２と同じ機能を有する。また、通信部３８２が有する受信部３８２１、中間バッファ３８２２、送信部３８２３、上記受信部３８２１が有する受信バッファ３８２１１、受信処理部３８２１２、上記送信部３８２３が有する送信処理部３８２３１、送信バッファ３８２３２は、図２に示した第２の実施形態における通信部２８２が有する受信部２８２１、中間バッファ２８２２、送信部２８２３、上記受信部２８２１が有する受信バッファ２８２１１、受信処理部２８２１２、上記送信部２８２３が有する送信処理部２８２３１、送信バッファ２８２３２と同じ機能を有する。
【0076】
サーバ側プロキシモジュール３５０のネットワーク状態確認部３５３とクライアント側プロキシモジュール３８０のネットワーク状態確認部３８３とは、ネットワーク３３０の混雑状況を調査するためのテストデータをネットワーク３３０を通じて送受信することによって、情報処理装置３１０から情報処理装置３２０に向かう経路に関するネットワーク３３０の混雑状況を調査する機能を有する。ネットワーク３３０の混雑状況を表す指標として、本実施形態ではデータ転送時間を使用する。具体的には、ネットワーク状態確認部３５３は、現在時刻を送信時刻として記載したテストデータを送信バッファ３５１３２に書き込むことによって、ＴＣＰ通信部３６０を利用してネットワーク３３０およびＴＣＰ通信部３９０経由でテストデータをサーバ側プロキシモジュール３５０からクライアント側プロキシモジュール３８０の受信バッファ３８２１１へ送信する。ネットワーク状態確認部３８３は、受信バッファ３８２１１からテストデータを取り出し、テストデータに記載されている送信時刻と現在時刻との差から、送信バッファ３５１３２から受信バッファ３８２１１までのデータ転送時間を算出する。そして、ネットワーク状態確認部３８３は、算出したデータ転送時間を自モジュールのウインドウサイズ調整部３８４へ通知する。またネットワーク状態確認部３８３は、算出したデータ転送時間を記載した応答データを送信バッファ３８１３２に書き込むことによって、ＴＣＰ通信部３９０を利用してネットワーク３３０およびＴＣＰ通信部３６０経由で応答データをクライアント側プロキシモジュール３８０からサーバ側プロキシモジュール３５０の受信バッファ３５２１１へ送信する。ネットワーク状態確認部３５３は、受信バッファ３５２１１から応答データを取り出し、応答データに記載されているデータ転送時間をウインドウサイズ調整部３５４へ通知する。
【0077】
テストデータを送信することによってクライアント装置向けの情報の送信が遅延することを避けるために、ネットワーク状態確認部３５３は、サーバ側プロキシモジュール３５０における送信待ちのクライアント装置向けの情報の量が閾値以下であるタイミングでテストデータを送信する。また、応答データを送信することによってサーバ装置向けの情報の送信が遅延することを避けるために、ネットワーク状態確認部３８３は、クライアント側プロキシモジュール３８０における送信待ちのサーバ装置向けの情報の量が閾値以下であるタイミングで応答データを送信する。
【0078】
ウインドウサイズ調整部３５４、３８４は、通知されたデータ転送時間に従って、ＴＣＰ通信部３６０からＴＣＰ通信部３９０への送受信に使用するＴＣＰのウインドウサイズを調整する機能を有する。例えば、ＴＣＰのウインドウサイズを拡大調整することによりデータ転送時間が短くなれば続けて拡大調整を行い、ＴＣＰのウインドウサイズを拡大調整することによりデータ転送時間が長くなれば逆に縮小調整を行う。また、ＴＣＰのウインドウサイズを縮小調整することによりデータ転送時間が短くなれば続けて縮小調整を行い、ＴＣＰのウインドウサイズを縮小調整することによりデータ転送時間が長くなれば逆に拡大調整を行う。
【0079】
本実施形態では、ウインドウサイズの調整は、送受信に使用するソケットバッファのサイズの変更に伴ってウインドウサイズが決定されるソケットの仕組みを利用する。ソケットバッファのサイズの変更は、図４に示す式に従う。
【0080】
図４に示す式において、Ｘnは今回測定されたデータ転送時間、Ｘn-1は前回測定されたデータ転送時間、ａは正の定数、Ｃnは今回のソケットバッファの増減量、Ｃn-1は前回のソケットバッファの増減量である。ソケットバッファの増減量が一定量より少ない場合は、増減調整を行わず又ｎ回目の測定データとして採用しない。また、ソケットバッファのサイズは正の最小値を持ち、初期値は予め設定されたデフォルト値を使用する。
【0081】
次に本実施形態に係るリモートデスクトップシステム３００の動作を説明する。本実施形態に係るリモートデスクトップシステム３００の動作のうち、ネットワーク状態確認部３５３、３８３およびウインドウサイズ調整部３５４、３８４以外の動作は、図２に示した第２の実施形態に係るリモートデスクトップシステム２００の動作と同じである。以下では、ネットワーク状態確認部３５３、３８３およびウインドウサイズ調整部３５４、３８４の動作を説明する。
【0082】
リモートデスクトップクライアントモジュール３７０とリモートデスクトップサーバモジュール３４０との間で、クライアント側プロキシモジュール３８０、ＴＣＰ通信部３９０、ネットワーク３３０、ＴＣＰ通信部３６０、およびサーバ側プロキシモジュール３５０を通じて相互に通信可能な状態になると、サーバ側プロキシモジュール３５０のネットワーク状態確認部３５３は予め定められた一定周期（例えば数分）毎に図５に示す処理の実行を開始し、クライアント側プロキシモジュール３８０のネットワーク状態確認部３８３は図６に示す処理の実行を開始する。
【0083】
サーバ側プロキシモジュール３５０のネットワーク状態確認部３５３は、起動されると、中間バッファ３５１２が空であるか否かを判定する（Ｓ３０１）。この処理は、サーバ側プロキシモジュール３５０における送信待ちのクライアント装置向けの情報の量が閾値以下であるか否かを判定する処理の一例である。若し、中間バッファ３５１２が空きでなければ、図５に示す処理を終了する。若し、中間バッファ３５１２が空きであれば、現在時刻を送信時刻として記載したテストデータを送信バッファ３５１３２に書き込む（Ｓ３０２）。そして、テストデータに対する応答データが受信バッファ３５２１１に到着するのを監視する（Ｓ３０３）。
【0084】
送信バッファ３５１３２に書き込まれたテストデータは、ＴＣＰ通信部３６０によってネットワーク３３０を通じて情報処理装置３１０から情報処理装置３２０へ送信され、ＴＣＰ通信部３９０で受信されてクライアント側プロキシモジュール３８０の受信バッファ３８２１１に書き込まれる。
【0085】
クライアント側プロキシモジュール３８０のネットワーク状態確認部３８３は、テストデータが受信バッファ３８２１１に到着するのを常時監視している（Ｓ３１１）。ネットワーク状態確認部３８３は、テストデータが受信バッファ３８２１１に到着すると、それを取り出し（Ｓ３１２）、テストデータに記載された送信時刻と現在時刻との差をデータ転送時間として算出する（Ｓ３１３）。次にネットワーク状態確認部３８３は、算出したデータ転送時間を応答データに記載し（Ｓ３１４）、中間バッファ３８１２が空のタイミングで（Ｓ３１５でＹＥＳ）、応答データを送信バッファ３８１３２に書き込む（Ｓ３１６）。ステップＳ３１５の処理は、クライアント側プロキシモジュール３８０における送信待ちのサーバ装置向けの情報の量が閾値以下であるか否かを判定する処理の一例である。またネットワーク状態確認部３８３は、上記算出したデータ転送時間をウインドウサイズ調整部３８４に通知する（Ｓ３１７）。そして、ネットワーク状態確認部３８３は、ステップＳ３１１の処理へと戻る。
【0086】
送信バッファ３５１８２に書き込まれた応答データは、ＴＣＰ通信部３９０によってネットワーク３３０を通じて情報処理装置３２０から情報処理装置３１０へ送信され、ＴＣＰ通信部３６０で受信されてサーバ側プロキシモジュール３５０の受信バッファ３５２１１に書き込まれる。
【0087】
サーバ側プロキシモジュール３５０のネットワーク状態確認部３５３は、応答データが受信バッファ３５２１１に到着すると（Ｓ３０３でＹＥＳ）、それを取り出し（Ｓ３０４）、応答データに記載されたデータ転送時間をウインドウサイズ調整部３５４に通知する（Ｓ３０５）。そして、ネットワーク状態確認部３５３は、図５に示す処理を終える。
【0088】
ウインドウサイズ調整部３５４は、ネットワーク状態確認部３５３から通知されたデータ転送時間に従って、送信部３５１３の送信バッファ３５１３２のサイズを図４に示した式に基づいて変更する。またウインドウサイズ調整部３８４は、ネットワーク状態確認部３８３から通知されたデータ転送時間に従って、受信部３８２１の受信バッファ３８２１１のサイズを図４に示した式に基づいて変更する。送信バッファ３５１３２および受信バッファ３８２１１は、ソケットバッファである。ソケットバッファのサイズ変更は、ソケットＡＰＩのオプションを使用して行うことができる。そして、ソケットが送受信に使用するバッファのサイズが変更されることにより、ＴＣＰのウインドウのサイズが変更されることになる。
【0089】
上述したように本実施形態によれば、第２の実施形態と同様の効果が得られると共に、以下のような効果が得られる。
【0090】
定期的にネットワーク３３０の混雑状況を調査し、その調査結果に基づいてＴＣＰのウインドウサイズを調整するため、動的に最適なウインドウサイズで通信を行うことができる。
【0091】
サーバ側プロキシモジュール３５０における送信待ちのクライアント装置向けの情報の量が閾値以下であるタイミング（例えば中間バッファ３５１２が空であるタイミング）で、ネットワーク３３０の混雑状況を調査するためのテストデータをネットワーク３３０に送信することにより、ネットワーク３３０の混雑状況を調査する処理によってクライアント装置向けの情報の送信が遅延するのを防止することができる。
【0092】
クライアント側プロキシモジュール３８０における送信待ちのサーバ装置向けの情報の量が閾値以下であるタイミング（例えば中間バッファ３８１２が空であるタイミング）で、ネットワーク３３０の混雑状況を調査するためのテストデータに対する応答データをネットワーク３３０に送信することにより、ネットワーク３３０の混雑状況を調査する処理によってサーバ装置向けの情報の送信が遅延するのを防止することができる。
【0093】
本実施形態では、ネットワーク３３０の混雑状況を表す指標として、送信バッファ３５１３２から受信バッファ３８２１１までのデータ転送時間を使用したが、他の指標を使用しても良い。例えば、送信バッファ３５１３２から受信バッファ３８２１１までの行きのデータ転送時間と、送信バッファ３８１３２から受信バッファ３５２１１までの帰りのデータ転送時間の合計であるラウンドトリップ時間を指標としても良い。
【0094】
また本実施形態では、ＴＣＰ通信部３６０からＴＣＰ通信部３９０に向かう経路に関するネットワーク３３０の混雑状況を調査し、ＴＣＰ通信部３６０からＴＣＰ通信部３９０への送受信に使用するＴＣＰのウインドウサイズを調整した。しかし、これに代えて、或いはこれと共に、ＴＣＰ通信部３９０からＴＣＰ通信部３６０に向かう経路に関するネットワーク３３０の混雑状況を調査し、ＴＣＰ通信部３９０からＴＣＰ通信部３６０への送受信に使用するＴＣＰのウインドウサイズを調整しても良い。そのためには、図３におけるネットワーク状態確認部３８３の代わりに、ネットワーク状態確認部３５３と同様の機能を有するネットワーク状態確認部を使用するか、或いはネットワーク状態確認部３８３とネットワーク状態確認部３５３の機能を併せ持つネットワーク状態確認部を使用し、図３におけるネットワーク状態確認部３５３の代わりに、ネットワーク状態確認部３８３と同様の機能を有するネットワーク状態確認部を使用するか、或いはネットワーク状態確認部３５３とネットワーク状態確認部３８３の機能を併せ持つネットワーク状態確認部を使用すれば良い。また、図３におけるウインドウサイズ調整部３５４の代わりに、ウインドウサイズ調整部３８４と同様の機能を有するウインドウサイズ調整部を使用するか、或いはウインドウサイズ調整部３５４とウインドウサイズ調整部３８４の機能を併せ持つウインドウサイズ調整部を使用し、図３におけるウインドウサイズ調整部３８４の代わりに、ウインドウサイズ調整部３５４と同様の機能を有するウインドウサイズ調整部を使用するか、或いはウインドウサイズ調整部３８４とウインドウサイズ調整部３５４の機能を併せ持つウインドウサイズ調整部を使用すれば良い。
【0095】
[第４の実施形態]図７を参照すると、本発明の第４の実施形態にかかるリモートデスクトップシステム４００で使用されるサーバ側プロキシモジュール中の通信部４５１は、リモートデスクトップサーバモジュール４４０から、クライアント向けの情報を受信し、ＴＣＰ通信部４６０の機能を使ってＴＣＰ通信によりネットワークを通じてクライアント側へ送信する機能を有する。すなわち、通信部４５１は、図３に示した第３の実施形態における通信部３５１に相当する。
【0096】
通信部４５１は、受信部４５１１、中間バッファ４５１２、送信部４５１３を有する。このうち、受信部４５１１、それを構成する受信バッファ４５１１１と受信処理部４５１１２、中間バッファ４５１２は、図３に示した受信部３５１１、それを構成する受信バッファ３５１１１と受信処理部３５１１２、中間バッファ３５１２と同様の機能を有する。
【0097】
送信部４５１３は、送信処理部４５１３１、送信バッファ４５１３２、送信順序決定部４５１３３、重複画面イメージ削除部４５１３４、画面生成部４５１３５、画面記憶部４５１３６を有する。このうち、送信バッファ４５１３２は、図３に示した送信バッファ３５１３２と同様の機能を有する。
【0098】
送信順序決定部４５１３３は、中間バッファ４５１２に蓄積されている情報、すなわち通信部４５１がリモートデスクトップサーバモジュール４４０から受信しＴＣＰ通信部４６０を通じてクライアント側プロキシモジュールへ未だ送信していない情報の送信順序を決定する機能を有する。送信順序決定部４５１３３は、送信順序の決定は、情報の種別とその種別に対して予め定められた優先度とに基づいて行う。
【0099】
リモートデスクトップサーバモジュールとリモートデスクトップクライアントモジュールとで授受される情報には、画面データ、キーボードやマウスのイベントデータといった主要な情報以外に、音声データ、ストレージデータ、プリンタデータ、クリップボードデータ、スマートカードデータ、シリアルポートデータ、その他のＰｎＰデバイスのデータ、ユーザ定義データが存在する。これらを幾つかの種類に分類し、優先度を付与する。例えば、画面データとキーボードやマウスのイベントデータとに対して最も高い優先度を付与し、音声データに対して次に高い優先度を付与し、その他に対して最も低い優先度を付与する。
【0100】
送信順序決定部４５１３３は、中間バッファ４５１２に蓄積されている個々の情報の種別を判別し、判別した種別に対応する優先度に従って、中間バッファ４５１２内で情報を優先度順に並べ替える。ＲＤＰプロトコルを使用するリモートデスクトップ接続では、リモートデスクトップサーバモジュールとリモートデスクトップクライアントモジュールとで授受される情報にＲＤＰプロトコルヘッダが付与されており、そのＲＤＰプロトコルヘッダを解析することによって情報の種別を確認することができる。並べ替えは、より優先度の高い種別の情報がより優先的に送信処理部４５１３１から読み出せるように行う。同じ優先度の情報間では中間バッファ４５１２への到着順に並べる。
【0101】
また送信順序決定部４５１３３は、送信順序の決定だけでなく、閾値以下の優先度を有する情報を中間バッファ４５１２から削除する機能を有していて良い。また、この削除機能は、中間バッファ４５１２の空き容量が予め定めた閾値以下のときに限って有効として良い。
【0102】
重複画面イメージ削除部４５１３４は、中間バッファ４５１２に蓄積されている画面イメージ、すなわち通信部４５１がリモートデスクトップサーバモジュール４４０から受信しＴＣＰ通信部４６０を通じてクライアント側プロキシモジュールへ未だ送信していない画面イメージから、重複部分を削除する機能を有する。
【0103】
一般にリモートデスクトップ接続では、転送量を削減するために、サーバ画面のうち更新された領域を含む矩形領域の画面イメージをクライアント側へ送信する。このとき、同じ領域が繰り返し更新されると、同じ矩形領域の画面イメージが何度も送信されることになる。今、或る矩形領域の画面イメージが、画面イメージＡから画面イメージＢに変化し、さらに画面イメージＣに変化した場合、画面イメージＡ、画面イメージＢ、画面イメージＣという３つの画面イメージがリモートデスクトップサーバモジュール４４０から通信部４５１１を通じて中間バッファ４５１２に蓄積される。良好な通信環境の下では、中間バッファ４５１２に到着した画面イメージは速やかに送信処理部４５１３１によって送信バッファ４５１３２に移され、ＴＣＰ通信部４６０を通じてクライアント側へ送信されるため、中間バッファ４５１２に同じ矩形領域の複数の画面イメージが蓄積されることはない。しかし、通信環境が悪化し、送信バッファ４５１３２に空きがなくなると、中間バッファ４５１２に同じ矩形領域の複数の画面イメージが蓄積される。このような状況を放置すると、最後には中間バッファ４５１２が満杯となり、リモートデスクトップサーバモジュール４４０から新たなクライアント装置向けの情報を受信できない状況に至ってしまう。そこで、重複画面イメージ削除部４５１３４は、同じ矩形領域に関する複数の画面イメージが中間バッファ４５１２に蓄積されているか否かを監視し、発見すれば時刻的により古い（中間バッファへの到着時刻がより古い）画面イメージを中間バッファ４５１２から削除する。例えば、中間バッファ４５１２に、上記の画面イメージＢと画面イメージＣが蓄積されている場合、画面イメージＢを中間バッファ４５１２から削除する。これによって、クライアント側の当該矩形領域は画面イメージＡからいきなり画面イメージＣに変化するためにコマ送りのようになるけれども、中間バッファ４５１２の空き領域不足に起因する不都合な事態を回避することができる。
【0104】
上記の説明では、重複する画面イメージとして、同じ矩形領域に関する複数の画面イメージを例示したが、それだけには限定されない。例えば、或る矩形領域に関する画面イメージと、それより後の画面イメージであってその矩形領域が先の矩形領域を包含する画面イメージとを互いに重複する画面イメージとして認識しても良い。
【0105】
画面生成部４５１３５は、中間バッファ４５１２に蓄積された画面イメージ、すなわち通信部４５１がリモートデスクトップサーバモジュール４４０から受信した画面イメージを用いて、サーバのデスクトップ画面全体の画面イメージを生成し、画面記憶部４５１３６に格納する機能を有する。画面イメージを用いてデスクトップ画面の画面イメージを生成する方法は、リモートデスクトップクライアントモジュールにおいて、受信した画面イメージからサーバのデスクトップ画面の画面イメージを生成する方法と同様の方法を使用することができる。画面生成部４５１３５は、受信処理部４５１１２によって新たな画面イメージが中間バッファ４５１２に格納される毎に、画面記憶部４５１３６に記憶されたサーバのデスクトップ画面の画面イメージを更新する。
【0106】
また画面生成部４５１３５は、中間バッファ４５１２に蓄積されている画面イメージの総量、すなわち通信部４５１がリモートデスクトップサーバモジュール４４０から受信しクライアント側プロキシへ未だ送信していない画面イメージの総量を算出する機能と、画面記憶部４５１３６に記憶されているサーバのデスクトップ画面の画面イメージの総量を算出する機能とを有する。さらに画面生成部４５１３５は、上記算出した総量どうしを比較し、中間バッファ４５１２に蓄積されている画面イメージの総量が画面記憶部４５１３６に記憶されているデスクトップ画面の画面イメージの総量を上回っているならば、送信処理部４５１３１に対して、画面記憶部４５１３６に記憶されている画面イメージの送信を指示し、中間バッファ４５１２に蓄積されている全ての画面イメージを中間バッファ４５１２から削除する機能を有する。
【0107】
送信処理部４５１３１は、中間バッファ４５１２に蓄積されたクライアント装置向けの情報を読み出して送信バッファ４５１３２に書き込む機能を有する。また送信処理部４５１３１は、画面生成部４５１３５から上記の指示を受けると、画面記憶部４５１３６から画面イメージを読み出して送信バッファ４５１３２に書き込む機能を有する。
【0108】
次に本実施形態の動作を説明する。本実施形態に係るリモートデスクトップシステム４００の動作のうち、通信部４５１以外の動作は第３の実施形態と同じである。以下では、通信部４５１の動作について、図８のフローチャートを参照して説明する。
【0109】
送信処理部４５１３１は、中間バッファ４５１２が空か否か、すなわちクライアント装置向けの情報が蓄積されているか否かを監視する（Ｓ４０１）。中間バッファ４５１２にクライアント装置向けの情報が蓄積されている場合、送信部４５１３では以下のような動作が行われる。
【0110】
まず送信順序決定部４５１３３は、中間バッファ４５１２に蓄積されている個々の情報の種別を判別し、判別した種別に対応する優先度に従って、中間バッファ４５１２内で情報を優先度順に並べ替え、また閾値以下の優先度を有する情報を中間バッファ４５１２から削除する（Ｓ４０２）。
【0111】
次に重複画面イメージ削除部４５１３４は、中間バッファ４５１２に蓄積されている画面イメージから重複部分を削除する（Ｓ４０３）。
【0112】
次に画面生成部４５１３５は、中間バッファ４５１２に蓄積された画面イメージを用いて、サーバのデスクトップ画面の画面イメージを生成し、画面記憶部４５１３６に格納する（Ｓ４０４）。次に画面生成部４５１３５は、中間バッファ４５１２に蓄積されている画面イメージの総量と、画面記憶部４５１３６に記憶されているサーバのデスクトップ画面の画面イメージの総量とを算出して比較する（Ｓ４０５）。この比較結果により以降の処理が相違する。
【0113】
中間バッファ４５１２に蓄積されている画面イメージの総量が画面記憶部４５１３６に記憶されているデスクトップ画面の画面イメージの総量を上回っていなければ、送信処理部４５１３１は、送信バッファ４５１３２に空きがあるか否かを確認し（Ｓ４０６）、空きがあれば、中間バッファ４５１２からクライアント装置向けの情報を読み出して、送信バッファ２５１３２に書き込む（Ｓ４０７）。そして、ステップＳ４０１の処理へと戻る。送信バッファ４５１３２に空きがなければ、送信処理部４５１３１はステップＳ４０７をスキップしてステップＳ４０１の処理へと戻る。
【0114】
他方、中間バッファ４５１２に蓄積されている画面イメージの総量が画面記憶部４５１３６に記憶されているデスクトップ画面の画面イメージの総量を上回っているならば、画面生成部４５１３５は、中間バッファ４５１２に蓄積されている全ての画面イメージを中間バッファ４５１２から削除し、送信処理部４５１３１に対して画面記憶部４５１３６に記憶されている画面イメージの送信を指示する（Ｓ４０８）。送信処理部４５１３１は、送信バッファ４５１３２に空きがあるか否かを確認し（Ｓ４０９）、空きが無ければ、空きができるまで待ち合わせる。空きがあれば、画面記憶部４５１３６からデスクトップ画面の画面イメージを読み出して、送信バッファ２５１３２に書き込む（Ｓ４１０）。そして、ステップＳ４０１の処理へと戻る。ＴＣＰ通信部４６０では、送信バッファ４５１３２にクライアント装置向けの情報が蓄積されると、それを読み出して、ネットワークを通じてＴＣＰ通信によりリモートデスクトップクライアントモジュールが存在する情報処理装置に向けて送信する。
【0115】
上述したように本実施形態によれば、第３の実施形態と同様の効果が得られると共に、以下のような効果が得られる。
【0116】
送信順序決定部４５１３３を使用して、中間バッファ４５１２内で情報を優先度順に並べ替えることにより、優先度の高い画面イメージ等が優先度の低い他のデータより優先的に送信することが可能になり、中間バッファ４５１２に情報が滞留するほど通信環境が悪化している状況下におけるリモートデスクトップ接続のレスポンス低下を改善することができる。
【0117】
重複画面イメージ削除部４５１３４を使用して、中間バッファ４５１２に蓄積されている画面イメージから重複部分を削除することにより、中間バッファ４５１２に情報が滞留するほど通信環境が悪化している状況下におけるリモートデスクトップ接続のレスポンス低下を改善することができる。
【0118】
画面生成部４５１３５を使用して、中間バッファ４５１２に蓄積されている画面イメージの総量が、それらに基づいて生成したデスクトップ画面の画面イメージの総量を上回った場合に、中間バッファ４５１２に蓄積されている全ての画面イメージを削除し、生成したデスクトップ画面の画面イメージを代わりに送信することにより、中間バッファ４５１２が満杯となってリモートデスクトップサーバモジュール４４０から新たなクライアント装置向けの情報を受信できない等の状況を回避することができる。
【0119】
[その他の実施形態]以上、本発明を幾つかの実施形態を挙げて説明したが、本発明は以上の実施形態にのみ限定されず、その他各種の付加変更が可能である。例えば、上記第４の実施形態の構成から、送信順序決定部４５１３３、重複画面イメージ削除部４５１３４、および画面生成部４５１３５の何れか１つ、または何れか２つを省略した構成も本発明の実施形態に含まれる。
【符号の説明】
【0120】
１００…リモートデスクトップシステム１１０…サーバ装置
１２０…クライアント装置
１３０…ネットワーク
１４０…サーバ側プロキシ
１４１…第３の通信部
１４２…第４の通信部
１５０…クライアント側プロキシ
１５１…第１の通信部
１５２…第２の通信部