JP2010079329A - シンクライアント体感性能管理システム及びそれに用いる方法並びにそのプログラム - Google Patents

Abstract

【課題】 ユーザの体感品質に直結するクライアントにおける応答性能を管理することができ、品質劣化を検出することが可能なシンクライアント体感性能管理システムを提供する。
【解決手段】 シンクライアント体感性能管理システムは、クライアント装置で行われた操作データがサーバ装置にて処理されるシンクライアントシステムにおけるクライアント装置からサーバ装置に送信されるパケットを捕捉することでクライアント装置におけるユーザの操作がテキスト入力であることを判定するテキスト入力判定モジュール（１）と、クライアント装置からサーバ装置へ送信される２つのパケットの間にサーバ装置からクライアント装置へのパケットの返信があるかどうかを判定する応答パケット検出モジュール（２）とを有し、応答パケット検出モジュールが前記返信が存在しないと判定した場合に品質劣化が発生している旨を外部に出力する。
【選択図】 図１

Description

本発明はシンクライアント体感性能管理システム及びそれに用いる方法並びにそのプログラムに関し、特にシンクライアントの体感性能を管理するための技術に関する。

シンクライアントシステムでは、文書作成ソフトウェアや表計算ソフトウェア等のアプリケーションがすべてサーバ装置側で動作する。クライアント装置で行われたキーボードやマウス等の操作データはサーバ装置に送信され、サーバ装置で操作データに対する処理が実行された後、画面の更新データがクライアント装置に返される。

このようなシンクライアントシステムでは、サーバ装置とクライアント装置との間のデータ送受信がリアルタイムに行われ、実際にそのアプリケーションを利用するユーザレベルでの主観的あるいは客観的な品質等のユーザ体感品質を用いた品質管理が重要視されている。

このユーザ体感品質を用いた品質管理としては、サーバ装置の処理時間を算出する方法がある（例えば、特許文献１参照）。特許文献１に記載の管理装置は、サーバ装置に接続されている。この管理装置で用いられるサーバ装置の処理時間を算出するためのモジュールの構成を図６に示す。図６において、サーバ処理時間算出モジュール６は、リクエスト時刻推定モジュール６１と、応答完了時刻推定モジュール６２と、処理時間算出モジュール６３とから構成されている。

リクエスト時刻推定モジュール６１は、クライアント装置（図示せず）からサーバ装置（図示せず）に入力されるパケットを捕捉し、サーバ装置がパケット（リクエスト）の処理を開始した時刻を推定する。

応答完了時刻推定モジュール６２は、サーバ装置からクライアント装置に出力されるパケットを捕捉し、サーバ装置がリクエストの処理を完了した時刻を推定する。

処理時間算出モジュールは、リクエスト時刻推定モジュール６１及び応答完了時刻推定モジュール６２で推定した処理完了時刻から処理開始時刻を減じることにより、サーバ装置がリクエストの処理に要した時間を算出する。

図７は、サーバ装置への入力パケットと、サーバ装置からの出力パケットとの時間変化に対し、管理装置によって算出されるサーバ装置の処理時間を概念的に示している。

ユーザ体感品質を用いた品質管理としては、以下の特許文献２〜４に記載の方法がある。特許文献２に記載の方法では、メディア用パケットの遅延揺らぎに応じたフレーム再生間隔の変動による影響を考慮してユーザ体感品質値を高い精度で推定している。

特許文献３に記載の方法では、品質管理目標値として利用可能なリアルタイム系アプリケーションのユーザ体感品質を推定可能な推定モデルを生成している。特許文献４に記載の方法では、バースト損失が発生するパケット通信網において、バースト損失という現象が、リアルタイム系アプリケーションの各種メディア（音声や映像等）に対するユーザ体感品質（主観品質または客観品質）に与える影響を考慮して、パケット通信網を管理できるようにしている。

特開２００７−２２１２０７号公報 特開２００７−３２９７７５号公報 特開２００６−３５２５２８号公報 特許第３９０５８９１号公報

上述したユーザ体感品質を用いた品質管理では、サーバ装置における応答性能を管理しており、ユーザの体感品質に直結するクライアントにおける応答性能を管理していないという問題がある。

また、上述したユーザ体感品質を用いた品質管理では、サーバ装置の処理時間がリクエスト間隔よりも長い場合に処理時間を算出することができないため、品質劣化を検出することができないという問題がある。

そこで、本発明の目的は上記の問題点を解消し、ユーザの体感品質に直結するクライアントにおける応答性能を管理することができ、品質劣化を検出することができるシンクライアント体感性能管理システム及びそれに用いる方法並びにそのプログラムを提供することにある。

本発明によるシンクライアント体感性能管理システムは、クライアント装置に対するユーザの操作で入力された操作データがサーバ装置にて処理されるシンクライアントシステムにおける前記クライアント装置から前記サーバ装置に送信されるパケットを捕捉することで、前記ユーザの操作がテキスト入力であることを判定するテキスト入力判定モジュールと、
前記クライアント装置から前記サーバ装置へ送信される２つのパケットの間に前記サーバ装置から前記クライアント装置へのパケットの返信があるかどうかを判定する応答パケット検出モジュールとを有し、
前記応答パケット検出モジュールが前記返信が存在しないと判定した場合に品質劣化の発生を少なくとも記憶装置に記憶している。

本発明によるシンクライアント体感性能管理方法は、クライアント装置に対するユーザの操作で入力された操作データがサーバ装置にて処理されるシンクライアントシステムにおける前記クライアント装置から前記サーバ装置に送信されるパケットを捕捉することで、前記ユーザの操作がテキスト入力であることを判定するテキスト入力判定処理と、
前記クライアント装置から前記サーバ装置へ送信される２つのパケットの間に前記サーバ装置から前記クライアント装置へのパケットの返信があるかどうかを判定する応答パケット検出処理とを有し、
前記応答パケット検出処理において前記返信が存在しないと判定した場合に品質劣化の発生を少なくとも記憶装置に記憶している。

本発明によるプログラムは、クライアント装置に対するユーザの操作で入力された操作データがサーバ装置にて処理されるシンクライアントシステムに接続される装置内のコンピュータに実行させるプログラムであって、
前記シンクライアントシステムにおける前記クライアント装置から前記サーバ装置に送信されるパケットを捕捉することで、前記ユーザの操作がテキスト入力であることを判定するテキスト入力判定処理と、
前記クライアント装置から前記サーバ装置へ送信される２つのパケットの間に前記サーバ装置から前記クライアント装置へのパケットの返信があるかどうかを判定する応答パケット検出処理とを含み、
前記応答パケット検出処理において前記返信が存在しないと判定した場合に品質劣化の発生を少なくとも記憶装置に記憶させることを特徴とする。

本発明は、上記のような構成及び動作とすることで、ユーザの体感品質に直結するクライアントにおける応答性能を管理することができ、品質劣化を検出することができるという効果が得られる。

次に、本発明の実施の形態について図面を参照して説明する。図１は本発明の第１の実施の形態によるシンクライアント体感性能管理システムの構成例を示すブロック図である。図１において、本発明の第１の実施の形態によるシンクライアント体感性能管理システムは、シンクライアントシステムのクライアント装置（図示せず）と通信可能に接続されており、テキスト入力判定モジュール１と、応答パケット検出モジュール２とを備えている。

テキスト入力判定モジュール１は、さらに第１のリクエスト時刻取得モジュール１１と、第２のリクエスト時刻取得モジュール１２と、リクエスト間隔算出モジュール１３とから構成されている。尚、テキスト入力判定モジュール１及び応答パケット検出モジュール２は、図示せぬコンピュータ［例えば、ＣＰＵ（中央処理装置）等］が、後述するシンクライアント体感性能管理方法の処理を実現するためのプログラムを実行することによって実現可能である。

図２は本発明の第１の実施の形態によるシンクライアント体感性能管理システムによる処理を示すフローチャートである。図１及び図２を参照して、本発明の第１の実施の形態によるシンクライアント体感性能管理方法について説明する。尚、図２に示す処理は、上記のコンピュータ（例えば、ＣＰＵ等）がプログラムを実行することで実現される。

まず、テキスト入力判定モジュール１は、シンクライアントシステムのクライアント装置からサーバ装置（図示せず）に送信されるパケットを捕捉することで、クライアント装置におけるユーザの操作がテキスト入力であることを判定する。

クライアント装置が送受信するパケットは、クライアント装置上のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ：オペレーティングシステム）やライブラリ等の機能を利用して取得することができる。また、このパケットは、クライアント装置とネットワーク的に接続されたネットワークスイッチやハブ、ルータ等の通信機器（図示せず）から取得することもできる。

シンクライアントシステムでは、文書作成ソフトウェアや表計算ソフトウェア等のアプリケーションがすべてサーバ装置側で動作する。クライアント装置で行われたキーボードやマウス等による操作データ（クライアント装置に対するユーザの操作で入力された操作データ）は、サーバ装置に送信され、サーバ装置で操作データに対する処理が実行された後、この操作データに対する処理の結果を示す画面の更新データがクライアント装置に返される。

クライアント装置での操作がテキスト入力であるかどうかの判定は、第１のリクエスト時刻取得モジュール１１、第２のリクエスト時刻取得モジュール１２、リクエスト間隔算出モジュール１３の３つのモジュールの連携によって実現される。

まず、第１のリクエスト時刻取得モジュール１１は、シンクライアントシステムのクライアント装置からサーバ装置に送信される第１のパケットを捕捉し、パケットの送信時刻を取得する（図２ステップＳ１）。

次に、第２のリクエスト時刻取得モジュール１２は、第１のパケットの次にクライアント装置からサーバ装置に送信される第２のパケットを捕捉し、上記と同様に、パケットの送信時刻を取得する（図２ステップＳ２）。

リクエスト間隔算出モジュール１３は、第２のパケットの送信時刻から第１のパケットの送信時刻を減じることにより、パケットの送信間隔を算出する（図２ステップＳ３）。次に、リクエスト間隔算出モジュール１３は、算出した送信間隔が所定の範囲内に収まっているかどうかを応答パケット検出モジュール２に通知する。

この判定に用いられる送信間隔の範囲は、ユーザによるキーボードの打鍵速度から決定される。熟練者の場合、キーボードを打つ速度は、たいてい毎分４００打から６００打の間である。この時、打鍵間隔は１００ｍｓ（ミリ秒）から１５０ｍｓとなる。したがって、テキスト入力判定モジュール１は、クライアント装置からサーバ装置に送信されるパケットの送信間隔が１００〜１５０ｍｓの時に、第１のパケットに対応するクライアント装置の操作がテキスト入力であると判定する。

キーボードを打つ速度は、人や状況によって異なる。言い換えれば、パケットの送信間隔が１００〜１５０ｍｓの範囲から外れていても、パケットの送出を引き起こした操作がテキスト入力でないとは限らない。しかしながら、後述の都合上、本実施の形態では、この範囲のパケットを分析の対象とする。また、キーボードを打つのが遅いユーザは、シンクライアントシステムに高い応答性能を要求しない可能性が高い。

続いて、クライアント装置のパケット送信間隔に関する通知を受けた応答パケット検出モジュール２は、リクエスト間隔が所定の範囲内に収まっていなければ（図２ステップＳ４のＦａｌｓｅ）、なにもせずに処理を終了する。

応答パケット検出モジュール２は、リクエスト間隔が所定の範囲内に収まっていた場合（図２ステップＳ４のＴｒｕｅ）、次に第１のパケットと第２のパケットとの間にサーバ装置からクライアント装置に向けて送信された応答パケットが存在するかどうかを調べる。

応答パケット検出モジュール２は、応答パケットが存在した場合（図２ステップＳ５のＦａｌｓｅ）、応答パケット検出モジュールは処理を終了する。応答パケット検出モジュール２は、応答パケットが存在しなかった場合（図２ステップＳ５のＴｒｕｅ）、品質劣化の発生を図示せぬ記憶装置等に記憶し、品質劣化が発生している旨を外部の出力装置等（図示せず）に出力する（図２ステップＳ６）。

この時の応答パケットは、クライアント装置のテキスト入力操作に対する画面更新データを含んでいる。第１のパケット送信と第２のパケット送信との間に応答パケットがクライアントに届かなかったということは、第１のパケット送信に対応するテキスト入力操作に対して画面の更新がなされなかった（間に合わなかった）ことを意味している。応答パケット検出モジュール２は、これを劣化と判定する。

ところで、人間は１００ｍｓないし１５０ｍｓ以上の遅延が発生した場合に、遅延を実際に遅延として知覚するという性質をもつため、ある文字の入力から１００〜１５０ｍｓ後の次の文字の入力までに画面の更新がなされない場合、ユーザはシンクライアントシステムの応答が遅いことを知覚する可能性が高い。この時、ユーザにとってシンクライアントシステムの体感品質は低下しているといえる。このため、本実施の形態では、パケットの送信間隔が１００〜１５０ｍｓの場合に、応答性能が低下していると判定する。もちろん、これらの数値は一例であり、適宜変更することができる。

仮に、ユーザのキーボードの打鍵間隔が２０ｍｓ（毎分３０００打）であれば、２つのキー入力の間に画面の更新が行われなくても、ユーザは遅延に気がつかない。本実施の形態は、熟練者のテキスト入力間隔が１００〜１５０ｍｓであることと、人間の知覚能力の性質との２つを利用してなされている。

例として、Ｗｉｎｄｏｗｓ（登録商標） Ｓｅｒｖｅｒ（Ｍｉｃｒｏｓｏｆｔ社のサーバ用ＯＳ）が提供するターミナルサービスを利用したシンクライアントシステムを考える。ターミナルサービスでは、ＲＤＰ（Ｒｅｍｏｔｅ Ｄｅｓｋｔｏｐ Ｐｒｏｔｏｃｏｌ）を用いてクライアント装置とサーバ装置とが操作データや画面データをやりとりする。データは、パケットに分割されてネットワーク上に流れる。

パケットキャプチャデータは、クライアント装置上のソフトウェアか、あるいはクライアント装置とネットワーク的に近いネットワークスイッチ等が備えるパケットキャプチャ用のポートから取得される。ＲＤＰのパケットは、特定のポート番号を使って送受信されるため、パケットのデータのうち、ポート番号を記述した部分を解析することで、パケットがＲＤＰを用いたものかどうかを判定することが可能である。

クライアント装置が送受信するパケットからＲＤＰパケットだけを抽出した結果、「１４時２５分３７秒」付近で以下のようなキャプチャデータが得られたとする。
１： Ｃ→Ｓ ＲＤＰ １４：２５：３７．０６８
２： Ｃ→Ｓ ＲＤＰ １４：２５：３７．１０２
３： Ｓ→Ｃ ＲＤＰ １４：２５：３７．１５２
４： Ｃ→Ｓ ＲＤＰ １４：２５：３７．２３７
５： Ｃ→Ｓ ＲＤＰ １４：２５：３７．３７１
６： Ｓ→Ｃ ＲＤＰ １４：２５：３７．４９２
７： Ｃ→Ｓ ＲＤＰ １４：２５：３７．５１８
８： Ｃ→Ｓ ＲＤＰ １４：２５：３８．００５

このデータは、１行が１つのパケットに対応している。例えば、１行目は、クライアント装置Ｃからサーバ装置Ｓへのパケットの送信が「１４時２５分３７．０６８秒」に行われたことを表す。

第１のリクエスト時刻取得モジュール１１は、まず第１のパケットとして１行目のパケットが送信された時刻「１４：２５：３７．０６８」を取得する。

次に、第２のリクエスト時刻取得モジュール１２は、第２のパケットとして２行目のパケットが送信された時刻「１４：２５：３７．１０２」を取得する。

そして、リクエスト間隔算出モジュール１３は、時刻「１４：２５：３７．１０２」から時刻「１４：２５：３７．０６８」を減算し、送信間隔である「０．０３４（秒）」を算出する。

ここでは、クライアント装置の操作の判定に用いる送信間隔が１２０〜１５０ｍｓ（０．１２０〜０．１５０秒）であったとする。算出した送信間隔は「０．０３４（秒）」であり、この範囲に収まらないため、リクエスト間隔算出モジュール１３は、クライアント装置の操作がテキスト入力ではないことを応答パケット検出モジュール２に通知する。

通知を受けた応答パケット検出モジュール２は、なにもせずに処理を終了する。あるいは、応答パケット検出モジュール２が劣化が発生していない旨をディスプレイ等の外部の出力装置に出力してもよい。

以上が第１のケースである。次に第２のケースについて説明する。第２のケースでは、第１のリクエスト時刻取得モジュール１１が第１のパケットとして２行目のパケットが送信された時刻「１４：２５：３７．１０２」を取得する。

次に、第２のリクエスト時刻取得モジュール１１は、第２のパケットとしてクライアント装置からサーバ装置に送信される次のパケットである４行目のパケットが送信された時刻「１４：２５：３７．２３７」を取得する。

リクエスト間隔算出モジュール１３は、時刻「１４：２５：３７．２３７」から時刻「１４：２５：３７．１０２」を減算し、送信間隔「０．１２５（秒）」を算出する。この値は、所定の範囲（０．１２０〜０．１５０秒）に収まっているため、リクエスト間隔算出モジュール１３はその旨を応答パケット検出モジュール２に通知する。

通知を受けた応答パケット検出モジュール２は、クライアント装置の操作がテキスト入力であるため、第１のパケットと第２のパケットとの間に、サーバ装置からクライアント装置へのパケットの返信があるかどうかを調べる。キャプチャデータを見ると、３行目に返信パケットが存在するため、この場合も、応答パケット検出モジュール２は処理を終了する。第１のケースと同様に、応答パケット検出モジュール２が劣化の発生していない旨をディスプレイ等の外部の出力装置に出力してもよい。

次に、第３のケースについて説明する。第３のケースでは、第１のリクエスト時刻取得モジュール１１が第１のパケットとして４行目のパケットが送信された時刻「１４：２５：３７．２３７」を取得する。

次に、第２のリクエスト時刻取得モジュール１２は、第２のパケットとして５行目のパケットが送信された時刻「１４：２５：３７．３７１」を取得する。

リクエスト間隔算出モジュール１３は、時刻「１４：２５：３７．３７１」から時刻「１４：２５：３７．２３７」を減算し、送信間隔「０．１３４（秒）」を算出する。この値は、所定の範囲（０．１２０〜０．１５０秒）に収まっているため、リクエスト間隔算出モジュール１３はその旨を応答パケット検出モジュール２に通知する。

通知を受けた応答パケット検出モジュール２は、クライアント装置の操作がテキスト入力であるため、第１のパケットと第２のパケットとの間に、サーバ装置からクライアント装置へのパケットの返信があるかどうかを調べる。４行目と５行目との間にサーバ装置からクライアント装置へのパケットの返信が存在しないため、応答パケット検出モジュール２は、応答性能に劣化があることを外部の別のシステムやディスプレイ等の出力装置に出力する。

同様に、第４のケースでは、５行目と７行目とにおけるクライアント装置からサーバ装置へのパケットの送信間隔が、時刻「１４：２５：３７．５１８」−時刻「１４：２５：３７．３７１」＝送信間隔「０．１４７」と所定の範囲に収まるため、テキスト入力判定モジュール１によってクライアント装置の操作がテキスト入力と判定される。

しかし、その間の６行目にサーバ装置からクライアント装置への返信があることが検出されるため、応答パケット検出モジュール２によって劣化はないと判定される。

第５のケースでは、７行目と８行目とにおけるクライアント装置からサーバ装置へのパケットの送信間隔が、時刻「１４：２５：３８．００５」−時刻「１４：２５：３７．５１８」＝送信間隔「０．４８７」と所定の範囲外であるため、テキスト入力判定モジュール１によってクライアント装置の操作がテキスト入力ではないと判定され、劣化検出の対象とならない。

以上に説明したように、本実施の形態によれば、クライアント装置におけるテキスト入力操作に対して、ユーザに知覚され得るような応答の遅延が発生しているかどうかを判定することができる。これによって、本実施の形態では、シンクライアントシステムがユーザに提供する体感品質を管理することが可能となる。

図３は本発明の第２の実施の形態によるシンクライアント体感性能管理システムの構成例を示すブロック図である。図３において、処理装置３は、上述した本発明の第１の実施の形態におけるテキスト入力判定モジュール１と応答パケット検出モジュール２とに加えて、劣化率算出モジュール３１を備えている。

また、処理装置３は、テキスト入力回数記憶部４１及び劣化回数記憶部４２を備えた記憶装置４と出力装置５とに接続されている。尚、テキスト入力判定モジュール１及び応答パケット検出モジュール２については、上記の図１及び図２に示す本発明の第１の実施の形態による構成及び動作と同様であるので、その説明については省略する。

図４は本発明の第２の実施の形態によるシンクライアント体感性能管理システムの処理を示すフローチャートである。図３及び図４を参照して本発明の第２の実施の形態によるシンクライアント体感性能管理システムの処理について説明する。尚、本実施の形態では、テキスト入力と判定されたパケットのうち、劣化と判定されたものの割合が算出される。また、図４に示す処理は、上記のコンピュータ（例えば、ＣＰＵ等）がプログラムを実行することで実現される。

劣化と判定されたものの割合の算出にあたり、処理装置３は、記憶装置４中のテキスト入力回数記憶部４１が保持するテキスト入力回数と、劣化回数記憶部４２が保持する劣化回数とをともに０に初期化する（図４ステップＳ１１）。

さらに、処理装置３は、処理すべきクライアント装置からサーバ装置へ送信されるパケット（リクエスト）がなくなるまで（図４ステップＳ１２のＦａｌｓｅ）、ステップＳ１３以降の処理を繰り返す。尚、ステップＳ１２においては、例えば、次のパケットが所定時間こなくなった時にパケット（リクエスト）がなくなったと判定する。処理装置３は、処理すべきパケットがなくなれば（図４ステップＳ１２のＴｒｕｅ）、劣化率を算出して（図４ステップＳ２０）、処理を完了する。

ステップＳ１３〜Ｓ１６の処理におけるテキスト入力判定モジュール１の動作は、上述した本発明の第１の実施の形態と同様である。本実施の形態では、さらに、テキスト入力判定モジュール１がパケットの送信間隔が所定の範囲内であった場合に（図４ステップＳ１６のＴｒｕｅ）、テキスト入力回数記憶部４１に保持されたテキスト入力回数の値を１増やす（図４ステップＳ１７）。

ステップＳ１８における応答パケット検出モジュール２の判定処理も、上述した本発明の第１の実施の形態と同様である。本実施の形態では、応答パケットが存在せず、劣化ありと判定された場合に（図４ステップＳ１８のＴｒｕｅ）、応答パケット検出モジュール２が劣化回数記憶部の保持する劣化回数の値を１増やす（図４ステップＳ１９）。

本実施の形態では、上記のステップＳ１２〜Ｓ１９の処理を繰り返すことにより、テキスト入力に対応すると判定されたパケットの数と、そのうち劣化と判定されたパケットの数とがカウントされる。

最後に、処理装置３の劣化率算出モジュール３１は、劣化率＝劣化回数／テキスト入力回数と定義される応答性能の劣化率を算出する（図４ステップＳ２０）。

図５は本発明の第２の実施の形態におけるシンクライアントシステムのサーバ装置とクライアント装置との間でやりとりされるパケットの送受信時刻と流量との関係を表す図である。

図５では、クライアント装置からサーバ装置への上りパケットのうち、リクエスト間隔が１００〜１５０ｍｓのパケット（☆印のパケット）がテキスト入力と判定される。このテキスト入力と判定されたパケットは全部で６あり、そのうちの２つについては応答（サーバ装置からクライアント装置への下りパケット）がないため、劣化率は２／６（≒０．３３３）と算出される。

この時、さらに、本実施の形態では、応答があった率を表す応答率＝１−劣化率＝４／６を算出してもよい。また、本実施の形態では、時間帯毎の劣化率を算出し、表やグラフ等の形式で出力することもできる。例えば、３０分毎の劣化率を算出し、劣化率のグラフを作成することで、劣化の発生している時間帯を視覚的に把握することが可能となる。

次に、本発明の第１の実施の形態で説明した具体例と同様の例を用いて、本発明の第２の実施の形態における具体的な処理例について説明する。本例では、クライアント装置が送受信するＲＤＰパケットに関して、クライアント装置からサーバ装置に送信されるパケットが６個あるため、５回の送信間隔の判定と、応答の有無の検出とを行う。本発明の第１の実施の形態で述べた５ケースは、それぞれこの判定及び検出処理に対応している。

５ケースのパケットの判定のうちの３ケース（パケット）は、テキスト入力と判定され、さらにそのうちの１ケースは劣化と判定されている。この時、テキスト入力回数は３、劣化回数は１となり、劣化率算出モジュール３１によって劣化率は１／３と算出される。

例えば、１日分のキャプチャデータを取得した場合、これを時間帯によって分割し、分割したそれぞれのデータ群に対する劣化率を算出して表やグラフにまとめれば、１日における劣化率の変化を把握することができる。

このように、本実施の形態では、一定期間の劣化率を算出することによって、劣化の度合いを定量的に把握することが可能となる。

本発明は、シンクライアントシステムの体感品質を監視または分析するための装置またはシステムに好適である。

本発明の第１の実施の形態によるシンクライアント体感性能管理システムの構成例を示すブロック図である。 本発明の第１の実施の形態によるシンクライアント体感性能管理システムによる処理を示すフローチャートである。 本発明の第２の実施の形態によるシンクライアント体感性能管理システムの構成例を示すブロック図である。 本発明の第２の実施の形態によるシンクライアント体感性能管理システムの処理を示すフローチャートである。 本発明の第２の実施の形態におけるシンクライアントシステムのサーバ装置とクライアント装置との間でやりとりされるパケットの送受信時刻と流量との関係を表す図である。 本発明に関連する管理装置で用いられるサーバ装置の処理時間を算出するためのモジュールの構成を示すブロック図である。 本発明に関連する管理装置においてサーバ装置への入力パケットとサーバ装置からの出力パケットとの時間変化に対し、算出されるサーバ装置の処理時間を概念的に示す図である。

符号の説明

１ テキスト入力判定モジュール
２ 応答パケット検出モジュール
３ 処理装置
４ 記憶装置
５ 出力装置
１１ 第１のリクエスト時刻取得モジュール
１２ 第２のリクエスト時刻取得モジュール
１３ リクエスト間隔算出モジュール
３１ 劣化率算出モジュール
４１ テキスト入力回数記憶部
４２ 劣化回数記憶部

Claims (15)

1. クライアント装置に対するユーザの操作で入力された操作データがサーバ装置にて処理されるシンクライアントシステムにおける前記クライアント装置から前記サーバ装置に送信されるパケットを捕捉することで、前記ユーザの操作がテキスト入力であることを判定するテキスト入力判定モジュールと、
   前記クライアント装置から前記サーバ装置へ送信される２つのパケットの間に前記サーバ装置から前記クライアント装置へのパケットの返信があるかどうかを判定する応答パケット検出モジュールとを有し、
   前記応答パケット検出モジュールが前記返信が存在しないと判定した場合に品質劣化の発生を少なくとも記憶装置に記憶することを特徴とするシンクライアント体感性能管理システム。
2. 前記応答パケット検出モジュールが前記返信が存在しないと判定した場合に前記品質劣化が発生した旨を外部に出力することを特徴とする請求項１記載のシンクライアント体感性能管理システム。
3. 前記テキスト入力と判定されたパケットのうちの劣化と判定されたものの割合を算出する劣化率算出モジュールを含むことを特徴とする請求項１または請求項２記載のシンクライアント体感性能管理システム。
4. 前記テキスト入力判定モジュールは、
   前記クライアント装置から前記サーバ装置に送信される第１のパケットを捕捉してその送信時刻を取得する第１のリクエスト時刻取得モジュールと、
   前記第１のパケットに続いて前記クライアント装置から前記サーバ装置に送信される第２のパケットを捕捉してその送信時刻を取得する第２のリクエスト時刻取得モジュールと、
   前記第１のパケットの送信時刻と前記第２のパケットの送信時刻とに基づいてパケットの送信間隔を算出するリクエスト間隔算出モジュールとを含むことを特徴とする請求項１から請求項３のいずれか記載のシンクライアント体感性能管理システム。
5. 前記リクエスト間隔算出モジュールが算出した送信間隔が所定の範囲内の数値である場合に前記第１のパケットが前記テキスト入力に対応していることを判定することを特徴とする請求項４記載のシンクライアント体感性能管理システム。
6. 前記所定の範囲の上限として１５０ミリ秒を用いることを特徴とする請求項５記載のシンクライアント体感性能管理システム。
7. 前記所定の範囲の下限として１００ミリ秒を用いることを特徴とする請求項６記載のシンクライアント体感性能管理システム。
8. クライアント装置に対するユーザの操作で入力された操作データがサーバ装置にて処理されるシンクライアントシステムにおける前記クライアント装置から前記サーバ装置に送信されるパケットを捕捉することで、前記ユーザの操作がテキスト入力であることを判定するテキスト入力判定処理と、
   前記クライアント装置から前記サーバ装置へ送信される２つのパケットの間に前記サーバ装置から前記クライアント装置へのパケットの返信があるかどうかを判定する応答パケット検出処理とを有し、
   前記応答パケット検出処理において前記返信が存在しないと判定した場合に品質劣化の発生を少なくとも記憶装置に記憶することを特徴とするシンクライアント体感性能管理方法。
9. 前記応答パケット検出モジュールが前記返信が存在しないと判定した場合に前記品質劣化が発生した旨を外部に出力することを特徴とする請求項８記載のシンクライアント体感性能管理方法。
10. 前記テキスト入力と判定されたパケットのうちの劣化と判定されたものの割合を算出する劣化率算出処理を含むことを特徴とする請求項８または請求項９記載のシンクライアント体感性能管理方法。
11. 前記テキスト入力判定処理は、
    前記クライアント装置から前記サーバ装置に送信される第１のパケットを捕捉してその送信時刻を取得する第１のリクエスト時刻取得処理と、
    前記第１のパケットに続いて前記クライアント装置から前記サーバ装置に送信される第２のパケットを捕捉してその送信時刻を取得する第２のリクエスト時刻取得処理と、
    前記第１のパケットの送信時刻と前記第２のパケットの送信時刻とに基づいてパケットの送信間隔を算出するリクエスト間隔算出処理とを含むことを特徴とする請求項８から請求項１０のいずれか記載のシンクライアント体感性能管理方法。
12. 前記リクエスト間隔算出処理において算出した送信間隔が所定の範囲内の数値である場合に前記第１のパケットが前記テキスト入力に対応していることを判定することを特徴とする請求項１１記載のシンクライアント体感性能管理方法。
13. 前記所定の範囲の上限として１５０ミリ秒を用いることを特徴とする請求項１２記載のシンクライアント体感性能管理方法。
14. 前記所定の範囲の下限として１００ミリ秒を用いることを特徴とする請求項１３記載のシンクライアント体感性能管理方法。
15. クライアント装置に対するユーザの操作で入力された操作データがサーバ装置にて処理されるシンクライアントシステムに接続される装置内のコンピュータに実行させるプログラムであって、
    前記シンクライアントシステムにおける前記クライアント装置から前記サーバ装置に送信されるパケットを捕捉することで、前記ユーザの操作がテキスト入力であることを判定するテキスト入力判定処理と、
    前記クライアント装置から前記サーバ装置へ送信される２つのパケットの間に前記サーバ装置から前記クライアント装置へのパケットの返信があるかどうかを判定する応答パケット検出処理とを含み、
    前記応答パケット検出処理において前記返信が存在しないと判定した場合に品質劣化の発生を少なくとも記憶装置に記憶させることを特徴とするプログラム。

Images