動作モード相違検出プログラム、方法及び装置

【課題】通信装置間の通信を観測することによって通信状態の問題を検出する。
【解決手段】あるアプリケーション間でやりとりされるメッセージは、当該メッセージのサイズが大きければ複数のセグメントに分割され、複数パケット（同じく複数フレーム）として送信される。この複数のフレームの送信間隔は短く、メッセージ間の送信間隔は相対的に長くなる。もし通信している装置間に動作モード相違が存在する場合に送信間隔が短ければ、フレーム衝突がより多く発生するので、メッセージ内衝突率が大きな値になる。一方、送信間隔が相対的に長いメッセージの先頭パケットについての衝突率であるメッセージ先頭衝突率は、動作モード相違の場合には相対的に小さくなる。従って、メッセージ内衝突率＞メッセージ先頭衝突率が成立する場合には、動作モード相違が存在するものとして記録する。

【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、通信状態の分析技術に関する。
【背景技術】
【０００２】
図１に示すように、２つの通信装置（例えばクライアント端末とスイッチ（ＳＷ）等）をイーサネット（登録商標）で接続し通信する場合、ＬＡＮ（Local Area Network）ポートの一方を「全二重固定」、他方を「自動識別」の設定で接続すると、自動認識が失敗し、「自動識別」側が「半二重」の動作モードに設定される場合が多い。この時、イーサネットの障害とは認識されず、２つの装置間で動作モードが異なる状態で接続される。「全二重固定」と「半二重」で通信を行う場合、送受信で同一伝送路を用いるため、同時にイーサフレームを送信するとフレーム衝突が発生し、衝突したフレームは破棄され相手装置に届かなくなる。しかしながら、イーサフレームの再送や上位レイヤでＴＣＰセグメントの再送処理を行うため、通信を行っているアプリケーションではパケット衝突を検出できないという問題がある。
【０００３】
このため、従来から全二重・半二重不整合検出装置が考案されている。この全二重・半二重不整合検出装置は、全二重・半二重不整合検出装置から連続送信パターンとして複数個の検査メッセージを短い間隔で連続送信し、分割送信パターンとして１つの検査メッセージを複数の通信フレームに分割して送信し、連続送信パターンにより送信された検査メッセージをそのままホスト側から折り返し送信し、分割送信パターンにより送信された検査メッセージを再組み立てしてホスト側から折り返し送信する。そして、全二重・半二重不整合検出装置により、連続送信パターンによる検査メッセージ送信におけるロス率と、分割送信パターンによる検査メッセージ送信におけるロス率と比較し、連続送信パターンによる検査メッセージ送信におけるロス率の方が大きい場合にネットワーク経路上に全二重・半二重不整合が存在すると判定するものである。このようなシステムでは、検査メッセージをわざわざ送信しなければならず、問題のないネットワークにおいて通信負荷を高めることになる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−３４５２２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上で述べた方式によれば、信頼性のある数値を得るためには、それなりの数の検査メッセージを送信しなければならず、通常運用しているネットワークやホストに対して負荷を与えることになる。
【０００６】
従って、本技術の目的は、通信装置間の通信を観測することによって通信状態の問題を検出するための新規な技術を提供することである。
【課題を解決するための手段】
【０００７】
本動作モード相違検出方法は、１のメッセージを１又は複数のセグメントに分割してパケットを送信する場合、２つの装置間のコネクション毎に、上記１のメッセージにおける先頭セグメントについての第１のパケットの数をカウントすると共に、上記１のメッセージにおける先頭セグメント以外のセグメントについての第２のパケットの数をカウントして、セグメント数データ格納部に格納するステップと、コネクション毎且つ上り方向及び下り方向の各々について、パケットに含まれるシーケンス番号とシーケンス番号の予測値と下位階層フレームの再送の有無とに基づき、第１のパケット及び第２のパケットに、ロス又は再送が発生しているか判断する判断ステップと、第１のパケットにロス又は再送が発生していると判断された場合には、コネクション毎に第１のパケットについての衝突数及び第２のパケットについての衝突数を格納する衝突数データ格納部において、第１のパケットが関連するコネクションで送信される第１のパケットについての衝突数を増加させ、第２のパケットにロス又は再送が発生していると判断された場合には、衝突数データ格納部において、第２のパケットが関連するコネクションで送信される第２のパケットについての衝突数を増加させるステップと、コネクション毎に、第１のパケットについての衝突数を第１のパケットの数で除することによって得られるメッセージ先頭衝突率と、第２のパケットについての衝突数を第２のパケットの数で除することによって得られるメッセージ内衝突率とを比較するステップと、メッセージ内衝突率がメッセージ先頭衝突率より大きい場合に、当該コネクションの両端の装置に動作モード相違が存在することを表す結果データを、コネクションの情報に対応付けて処理結果格納部に格納するステップとを含む。
【発明の効果】
【０００８】
通信装置間の通信を観測することによって通信状態の問題を検出できるようになる。
【図面の簡単な説明】
【０００９】
【図１】図１は、従来の問題点を説明するための図である。
【図２】図２は、装置接続の概要を示す図である。
【図３】図３は、動作モード違いによる衝突の一例を示す図である。
【図４】図４は、間欠障害の一例を示す図である。
【図５】図５は、メッセージのセグメントの送信間隔について説明するための図である。
【図６】図６は、ＴＣＰレベルでのパケットロスの検出と再送を示す図である。
【図７】図７は、ＴＣＰレベルでのパケットロスの検出と再送を示す図である。
【図８】図８は、イーサレベルの衝突検出と再送を示す図である。
【図９】図９は、ＴＣＰにおける通信の遷移を説明するシーケンス図である。
【図１０】図１０は、ＩＰパケットの構成図である。
【図１１】図１１は、ＩＰヘッダの構成図である。
【図１２】図１２は、ＴＣＰヘッダの構成図である。
【図１３】図１３は、分析装置の機能ブロック図である。
【図１４】図１４は、メインの処理フローを示す図である。
【図１５】図１５は、コネクション情報テーブルの一例を示す図である。
【図１６】図１６は、メインの処理フローを示す図である。
【図１７】図１７は、開始及び終了時処理の処理フローを示す図である。
【図１８】図１８は、第１シーケンス番号テーブルの一例を示す図である。
【図１９】図１９は、第２シーケンス番号テーブルの一例を示す図である。
【図２０】図２０は、セグメント数テーブルの一例を示す図である。
【図２１】図２１は、衝突数テーブルの一例を示す図である。
【図２２】図２２は、蓄積セグメント数テーブルの一例を示す図である。
【図２３】図２３は、蓄積衝突数テーブルの一例を示す図である。
【図２４】図２４は、上りパケット処理の処理フローを示す図である。
【図２５】図２５は、上りパケット処理の処理フローを示す図である。
【図２６】図２６は、下りパケット処理の処理フローを示す図である。
【図２７】図２７は、下りパケット処理の処理フローを示す図である。
【図２８】図２８は、集計処理の処理フローを示す図である。
【図２９】図２９は、蓄積データ格納部に格納されるデータの一例を示す図である。
【図３０】図３０は、集計処理の処理フローを示す図である。
【図３１】図３１は、集計結果の一例を示す図である。
【図３２】図３２は、コンピュータの機能ブロック図である。
【発明を実施するための形態】
【００１０】
［本実施の形態の前提］
まず、本実施の形態では、図２に示すように、分析装置１００で、通信装置間のイーサネットフレームをキャプチャし、イーサネットフレームの再送やＴＣＰセグメント（すなわちパケット）の再送又はロスを検出することで、通信装置間の動作モード違いを判別するものである。図２では、サーバとクライアント端末との間のスイッチに分析装置１００を接続して、イーサネットフレーム（以下、イーサフレームとも呼ぶ）をキャプチャする。
【００１１】
イーサフレームの再送、ＴＣＰセグメントの再送及びロスの検出は、イーサフレームの衝突以外に、伝送路の間欠障害、サーバや通信装置の高負荷など様々な要因が考えられる。すなわち、イーサフレームの再送やＴＣＰセグメントの再送及びロスの現象を、イーサフレーム衝突とそれ以外の要因に区別する必要がある。イーサフレームの衝突は、図３に示すように、イーサフレームの送信間隔が短い時に発生する傾向がある。衝突が発生して到達していないパケットがあることが分かれば、イーサレベルで自ら再送する場合もあれば、ロスを発見してＡＣＫにてロスを通知してＴＣＰレイヤで再送する場合もある。一方、伝送路の間欠障害、サーバや通信装置の高負荷などの場合、図４に示すようにイーサフレームの送信間隔が長い場合も、イーサフレームの送信間隔が短い場合にも発生する。しかしながら、イーサフレームの衝突が図３に示すように送信間隔が短い場合に明らかに発生しやすいという特性との対比においては、送信間隔が長い場合においてパケットの再送やロスの検出の頻度が高ければ、間欠障害であると言うことができる。
【００１２】
なお、ＴＣＰ上のアプリケーションが１パケット（１５１４バイト）に収まらないメッセージの送信を指示すると、カーネルがセグメント分割し、複数セグメントでメッセージを送信する。図５に示すように、セグメントの送信間隔には、同一メッセージ内と異なるメッセージ間の２種類が存在し、同一メッセージ内のセグメント送信間隔が短いという性質がある。これは、例えばサーバアプリケーションがカーネルに対して、メッセージ単位に送信要求を行うため、カーネル内で分割された同一メッセージ内のセグメントの送信間隔は短くなるためである。一方、サーバアプリケーションで分割された２つの異なるメッセージ送信要求は、別々にシーケンシャルにカーネルで処理されるので、セグメント送信間隔が長くなる。
【００１３】
本実施の形態では、イーサフレームの衝突とそれ以外の要因とに区別するため、同一メッセージ内でイーサフレームの再送又はＴＣＰセグメントの再送やロスが発生する割合と、メッセージ先頭で発生する割合を比較する。そして、同一メッセージ内の発生率がメッセージ先頭の発生率よりも大きい時、イーサフレームが衝突しており、動作モード違いが存在すると推測することができる。
【００１４】
本実施の形態では、セグメントに係るパケットのロスや再送をＴＣＰシーケンス番号を用いて検出する。すなわち、分析装置１００が接続されているスイッチなどでモニタするポート（以下、モニタポートと呼ぶ）を通過するパケットのＴＣＰヘッダに含まれるシーケンス番号をその直前のパケットのＴＣＰヘッダに含まれるＴＣＰヘッダから予測される予測シーケンス番号と比較する。図６に示すように、ＴＣＰのＡＣＫで、それまでに受信できたセグメントに係るパケットのシーケンス番号が通知されるので、最後に送信したパケットのシーケンス番号＋データ量より小さい応答確認番号がＡＣＫに含まれていれば、衝突があったことになり、ＴＣＰレベルにおいてパケットの再送が行われる。この場合には、予測より小さく且つ応答確認番号と同じ値のシーケンス番号のパケットが送信されるので、パケットの再送を検出できる。
【００１５】
さらに、図７に示すように、衝突によりパケットをロスしても通信装置側から次々にパケットが送信されてくる場合には、予測よりも大きな値のシーケンス番号を含むパケットを受信することから、パケットのロスを検出することができる。
【００１６】
また、図８に示すように、イーサレベルにおいて衝突を検出してイーサフレームの再送を行った場合には、イーサフレームをバッファリングしておくことで完全に一致するイーサフレームの再送を検出することができる。
【００１７】
以上述べた３つの衝突パターンを検出すると共に、当該衝突がメッセージの先頭なのかメッセージ内なのかを識別することで、メッセージ内の衝突率及びメッセージ先頭の衝突率を算出することができる。
【００１８】
また、図９に示すように、クライアント端末からサーバに接続する場合には、ＴＣＰレベルにおいて、ＳＹＮパケットをクライアント端末からサーバに送信し、これに対してサーバからクライアント端末にＳＹＮ＋ＡＣＫパケットを送信する。さらに、クライアント端末からサーバへＡＣＫパケットを送信する。これによってコネクションが確立したことになって、通信が双方向で行われる。その後、例えばクライアント端末からサーバへＦＩＮパケットを送信し、それに対してサーバからクライアント端末へＡＣＫパケットが返信される。さらに、サーバからクライアント端末へＦＩＮパケットが送信され、クライアント端末からサーバへＡＣＫパケットが送信されると、コネクションの切断が行われたことになる。ＴＣＰヘッダに設定されるシーケンス番号は、直前に受信したＡＣＫパケットに応じて設定される。すなわち、接続確立前であれば、クライアント端末からサーバへ送信したＡＣＫパケットに含まれる応答確認番号をシーケンス番号として含むパケットをサーバからクライアント端末へ送信することになる。同様に、サーバからクライアント端末へ送信したＳＹＮ＋ＡＣＫパケットに含まれる応答確認番号をシーケンス番号として含むパケットをクライアント端末からサーバへ送信することになる。なお、接続確立時であれば、クライアント端末からサーバに送られたＡＣＫパケットに含まれるシーケンス番号と応答確認番号をチェックすれば、開始シーケンス番号を特定できる。
【００１９】
さらに、図１０に示すように、ＩＰパケットには、ＩＰヘッダ、ＴＣＰヘッダ及びＴＣＰデータが含まれており、このＴＣＰデータの部分にアプリケーションのメッセージヘッダ及びメッセージデータが含まれる。メッセージヘッダには、メッセージ長が含まれる。なお、ＩＰパケットは、イーサフレームの中に含まれることになる。
【００２０】
また、ＩＰヘッダの模式図を図１１に示す。ＩＰヘッダは周知であるから詳しく述べないが、送信元ＩＰアドレスと宛先ＩＰアドレスを含むようになっている。同様に、図１２にＴＣＰヘッダの模式図を示す。ＴＣＰヘッダには、ＴＣＰヘッダについても周知であるから詳しく述べないが、コネクションを識別するための送信元ポート番号及び宛先ポート番号と、シーケンス番号及び確認応答番号とを含むようになっている。なお、フラグにおいてＳＹＮパケット、ＦＩＮパケット、ＡＣＫパケットであるか否かなどが指定されている。なお、ＴＣＰパケットのＴＣＰデータのサイズ（データ長）は、（ＩＰパケットに含まれるパケット長−ＩＰヘッダ長−ＴＣＰヘッダ長）にて算出可能である。
【００２１】
［実施の形態の具体的内容］
次に、本実施の形態に係る分析装置１００の構成及び処理内容について説明する。図１３に分析装置１００の機能ブロック図を示す。分析装置１００は、コネクション関連処理部１０１と、上りパケット処理部１０２と、下りパケット処理部１０３と、コネクション情報テーブル１０４と、セグメント数テーブル１０５と、衝突数テーブル１０６と、第１シーケンス番号テーブル１０７と、第２シーケンス番号テーブル１０８と、フレームバッファ１０９と、蓄積データ格納部１１０と、評価処理部１１１と、出力部１１２とを有する。
【００２２】
次に、図１３に示した分析装置１００の処理内容について図１４乃至図３１を用いて説明する。コネクション関連処理部１０１は、モニタポートを通過するパケットを受信したか判断する（ステップＳ１）。パケットを受信していない場合には、受信するまで待機する。一方、受信した場合には、コネクション関連処理部１０１は、受信パケットからコネクション情報を抽出する（ステップＳ３）。コネクション情報は、送信元ＩＰアドレス及び宛先ＩＰアドレスと送信元ポート番号及び宛先ポート番号とを含む。そして、コネクション関連処理部１０１は、抽出コネクション情報でコネクション情報テーブル１０４を検索する（ステップＳ５）。コネクション情報テーブル１０４には、例えば図１５に示すようなテーブルである。図１５の例では、レコードの生成時刻と、接続先ＩＰアドレス（＝宛先ＩＰアドレス）と、接続先ポート番号（＝宛先ポート番号）と、接続元ＩＰアドレス（＝送信元ＩＰアドレス）と、接続元ポート番号（＝送信元ポート番号）とが登録されるようになっている。なお、送信元と宛先が入れ替わっている場合にも同じコネクションであるが、ここでは両方テーブルに登録するのではなく、一方のみを登録することにする。
【００２３】
そして、ステップＳ５の結果として該当レコードが存在すれば（ステップＳ７：Ｙｅｓルート）、コネクション関連処理部１０１は、受信パケットが切断関連パケットであるか判断する（ステップＳ８）。切断関連パケットは、ＦＩＮパケットを含む。切断関連パケットであれば、端子Ａを介して図１６のステップＳ１５に移行する。一方、切断関連パケットでなければ、コネクション関連処理部１０１は、上りパケット処理部１０２に処理を依頼し、上りパケット処理部１０２は、上りパケット処理を実施する（ステップＳ９）。この上りパケット処理については後に詳しく述べる。その後端子Ｂを介して図１６のステップＳ１９に移行する。
【００２４】
一方、ステップＳ５の結果として該当レコードが存在しない場合には（ステップＳ７：Ｎｏルート）、コネクション関連処理部１０１は、接続先と接続元のＩＰアドレス及びポート番号を入れ替えて、下りコネクション情報を生成し（ステップＳ１１）、下りコネクション情報でコネクション情報テーブル１０４を検索する（ステップＳ１３）。処理は端子Ｃを介して図１６の処理に移行する。
【００２５】
そして、ステップＳ１３の結果として該当レコードが存在する場合には（ステップＳ１４：Ｙｅｓルート）、コネクション関連処理部１０１は、受信パケットが切断関連パケットであるか判断する（ステップＳ１６）。切断関連パケットであれば、ステップＳ１５に移行する。一方、切断関連パケットでなければ、コネクション関連処理部１０１は、下りパケット処理部１０３に処理を依頼し、下りパケット処理部１０３は、下りパケット処理を実施する（ステップＳ１７）。この下りパケット処理については後に詳しく述べる。その後ステップＳ１９に移行する。
【００２６】
一方、ステップＳ１３の結果として該当レコードが存在しない場合には（ステップＳ１４：Ｎｏルート）、コネクション関連処理部１０１は、開始及び終了時処理を実施する（ステップＳ１５）。この開始及び終了時処理については後に詳しく述べる。処理はステップＳ１９に移行する。
【００２７】
ステップＳ１９では、処理が終了するか判断し（ステップＳ１９）、処理終了でなければ端子Ｄを介して図１４のステップＳ１に戻る。一方、処理終了であれば、処理を終了する。
【００２８】
上りパケット処理及び下りパケット処理により、メッセージ先頭か否か及び衝突の検出を実施し、開始及び終了時処理により、コネクション情報等を設定する処理及び収集データを蓄積データ格納部１１０に移動させる処理を実施する。
【００２９】
次に、開始及び終了時処理について図１７乃至図２３を用いて説明する。最初に、コネクション関連処理部１０１は、受信パケットが第１の接続関連パケットであるか判断する（ステップＳ２１）。本実施の形態では、第１の接続関連パケットは、ＳＹＮ＋ＡＣＫパケットである。第１の接続関連パケットであれば、コネクション関連処理部１０１は、受信パケットのコネクション情報の接続先と接続元のＩＰアドレス及びポート番号を入れ替えて接続判断情報として、例えばメインメモリなどの記憶装置に格納する（ステップＳ２３）。そして元の処理に戻る。
【００３０】
一方、第１の接続関連パケットではない場合には、コネクション関連処理部１０１は、受信パケットが、接続判断情報と同じコネクション情報を含む第２の接続関連パケットであるか判断する（ステップＳ２５）。第２の接続関連パケットは、図９で示した接続シーケンスにおいてＳＹＮ＋ＡＣＫパケットの次に送信されるＡＣＫパケットである。従って、このようなＡＣＫパケットでは、ＳＹＮ＋ＡＣＫパケットとは接続先と接続元のＩＰアドレス及びポート番号が逆になっている。
【００３１】
受信パケットが、このような第２の接続関連パケットであれば、コネクション関連処理部１０１は、受信パケットのコネクション情報をコネクション情報テーブル１０４（図１５）に登録する（ステップＳ２７）。この際、処理時刻を生成時刻として一緒に登録する。さらに、第２の接続関連パケットのＴＣＰヘッダに含まれるシーケンス番号及び応答確認番号とコネクション情報などを、第１シーケンス番号テーブル１０７及び第２シーケンス番号テーブル１０８に登録する（ステップＳ２９）。第１シーケンス番号テーブル１０７の一例を図１８に示す。図１８の例では、生成時刻と、接続先ＩＰアドレス（＝宛先ＩＰアドレス）と、接続先ポート番号（＝宛先ポート番号）と、接続元ＩＰアドレス（＝送信元ＩＰアドレス）と、接続元ポート番号（＝送信元ポート番号）と、上りシーケンス番号と、上り終了シーケンス番号と、下りシーケンス番号と、下り終了シーケンス番号とを登録するようになっている。ここでは、上り終了シーケンス番号及び下り終了シーケンス番号については登録されない。また、上りシーケンス番号には、シーケンス番号が登録され、下りシーケンス番号には、応答確認番号が登録される。また、第２シーケンス番号テーブル１０８の一例を図１９に示す。図１９の例では、生成時刻と、接続先ＩＰアドレス（＝宛先ＩＰアドレス）と、接続先ポート番号（＝宛先ポート番号）と、接続元ＩＰアドレス（＝送信元ＩＰアドレス）と、接続元ポート番号（＝送信元ポート番号）と、上りロス回数と、下りロス回数と、上りロスシーケンス番号リストへのアドレスと、下りロスシーケンス番号リストへのアドレスとを登録するようになっている。この第２シーケンス番号テーブルは、パケットのロスを検出した場合にそのロスを管理するためのテーブルであり、上りロス回数及び下りロス回数はカウンタであり、上りロスシーケンス番号リストへのアドレスは、上り用のリスト構造における先頭リストのデータブロックへのポインタとなっており、下りロスシーケンス番号リストへのアドレスは、下り用のリスト構造における先頭リストのデータブロックへのポインタとなっている。図１９の例では、第２レコードにおける上りシーケンス番号リストにおける先頭リストのデータブロックのアドレスは「４５６」であり、アドレス「４５６」には、「Ｎｅｘｔアドレス」（＝次のリストのデータブロックへのポインタ。ここでは次のリストのデータブロックが存在しないので「０」。）と、ロス開始シーケンス番号（ここでは「３０００」）とが登録されるようになっている。同様に、第１レコードにおける下りシーケンス番号リストにおける先頭リストのデータブロックのアドレスは「１２３」であり、アドレス「１２３」には、「Ｎｅｘｔアドレス」（ここでは「７８９」）と、ロス開始シーケンス番号（ここでは「１００００」）とが登録されている。次のリストのデータブロックのアドレス「７８９」には、「Ｎｅｘｔアドレス」（ここでは存在していないので「０」）と、ロス開始シーケンス番号（ここでは「５０００００」）とが登録されている。このように、ロスを発見する毎に、カウンタがインクリメントされ、リスト構造の長さが伸びるようになっている。但し、以下で述べるように、再送が確認できた時点で該当リストのデータブロックについては削除され、リスト構造が変更される。
【００３２】
さらに、コネクション関連処理部１０１は、セグメント数テーブル１０５及び衝突数テーブル１０６に、コネクション情報などを登録する（ステップＳ３１）。セグメント数テーブル１０５の一例を図２０に示す。図２０の例では、生成時刻と、接続先ＩＰアドレス（＝宛先ＩＰアドレス）と、接続先ポート番号（＝宛先ポート番号）と、接続元ＩＰアドレス（＝送信元ＩＰアドレス）と、接続元ポート番号（＝送信元ポート番号）と、メッセージ内のセグメントの出現回数と、メッセージ先頭のセグメントの出現回数とが登録されるようになっている。但し、この時点では、出現回数は「０」となる。また、衝突数テーブル１０６の一例を図２１に示す。図２１の例では、生成時刻と、接続先ＩＰアドレス（＝宛先ＩＰアドレス）と、接続先ポート番号（＝宛先ポート番号）と、接続元ＩＰアドレス（＝送信元ＩＰアドレス）と、接続元ポート番号（＝送信元ポート番号）と、メッセージ内の衝突検出の回数と、メッセージ先頭の衝突検出の回数とを登録するようになっている。但し、この時点では、衝突検出の回数は「０」となる。そして元の処理に戻る。以上が、接続時の処理になる。
【００３３】
なお、切断時の処理（ステップＳ３５乃至Ｓ４１）は、ステップＳ２５で上で述べたような第２の接続関連パケットではなく、切断関連パケット（ここではＦＩＮパケット）である場合に実行される。
【００３４】
すなわち、コネクション関連処理部１０１は、受信パケットがステップＳ２５で上で述べたような第２の接続関連パケットではないと判断した場合には、受信パケットが切断関連パケットであるか判断する（ステップＳ３３）。受信パケットが切断関連パケットでもない場合には、そのまま元の処理に戻る。一方、受信パケットが切断関連パケットであれば、セグメント数テーブル１０５及び衝突数テーブル１０６における該当レコード（コネクション情報又は下りコネクション情報で特定されるレコード）を、蓄積データ格納部１１０の対応するテーブルに登録する（ステップＳ３５）。図２２に、蓄積データ格納部１１０に格納される蓄積セグメント数テーブルの一例を示す。図２２の例では、生成時刻と、消滅時刻（＝ステップＳ３５実行時刻）と、接続先ＩＰアドレス（＝宛先ＩＰアドレス）と、接続先ポート番号（＝宛先ポート番号）と、接続元ＩＰアドレス（＝送信元ＩＰアドレス）と、接続元ポート番号（＝送信元ポート番号）と、メッセージ内のセグメントの出現回数と、メッセージ先頭のセグメントの出現回数とを登録するようになっている。また、図２３に、蓄積データ格納部１１０に格納される蓄積衝突数テーブルの一例を示す。図２２の例では、生成時刻と、消滅時刻（＝ステップＳ３５実行時刻）と、接続先ＩＰアドレス（＝宛先ＩＰアドレス）と、接続先ポート番号（＝宛先ポート番号）と、接続元ＩＰアドレス（＝送信元ＩＰアドレス）と、接続元ポート番号（＝送信元ポート番号）と、メッセージ内の衝突検出の回数と、メッセージ先頭の衝突検出の回数とが登録されるようになっている。
【００３５】
また、コネクション関連処理部１０１は、セグメント数テーブル１０５及び衝突数テーブル１０６において該当レコード（コネクション情報又は下りコネクション情報で特定されるレコード）を削除する（ステップＳ３７）。さらに、第１及び第２シーケンス番号テーブル１０７及び１０８においても、該当レコードを削除する（ステップＳ３９）。第２シーケンス番号テーブル１０８に付随する関連リスト構造も削除する。最後に、コネクション情報テーブル１０４において、該当レコードを削除する（ステップＳ４１）。そして元の処理に戻る。
【００３６】
以上のような処理を実施することで、以下で述べる集計処理の前処理が実施されたことになり、さらに同じコネクションが確立されても異なるデータとして処理できるようになる。
【００３７】
次に、図２４及び図２５を用いて上りパケット処理について説明する。まず、上りパケット処理部１０２は、受信イーサフレームをそのままフレームバッファ１０９に格納する（ステップＳ５１）。フレームバッファ１０９は、１つのコネクションについて例えば２０ｍｓｅｃ分のイーサフレームを格納できる程度のサイズを有しており、古いものから順に上書きする形でバッファリングする。また、受信パケットにおいて、アプリケーション層のメッセージヘッダをチェックし（ステップＳ５３）、当該メッセージヘッダに含まれる情報からメッセージの先頭であるか否かを判断する（ステップＳ５５）。例えば、メッセージヘッダに、現パケットの、メッセージ先頭からのオフセットが含まれており、そのオフセットが「０」であれば先頭と判断できる。これは一例であるが一般的には、先頭か否かを特定可能なデータをメッセージヘッダは含むので、そのデータを用いる。メッセージの先頭でなければステップＳ５９に移行する。
【００３８】
メッセージの先頭であれば、上りパケット処理部１０２は、メッセージヘッダに含まれるメッセージ長のデータを用いてメッセージの末尾に相当するシーケンス番号を（第１シーケンス番号テーブル１０７の上りシーケンス番号＋メッセージ長）で算出し、第１シーケンス番号テーブル１０７における該当コネクションについてのレコードの上り終了シーケンス番号の列を更新する（ステップＳ５７）。上り終了シーケンス番号までのシーケンス番号であれば１つのメッセージについてのパケットであるが、上り終了シーケンス番号より大きな値のシーケンス番号については、次のメッセージについてのパケットである。なお、フロー上では明示していないが、コネクションを維持したまま次のメッセージを送信する場合もある。処理はステップＳ５９に移行する。
【００３９】
ステップＳ５９では、上りパケット処理部１０２は、セグメント数テーブル１０５において、ステップＳ５５の判断結果に応じて、メッセージ先頭のセグメントの出現回数又はメッセージ内のセグメントの出現回数を１インクリメントする。そして、フレームバッファ１０９にステップＳ５１で格納したイーサフレームと同一のイーサフレームが完全に重複してバッファリングされているか否かを判断する（ステップＳ６１）。これは、図８に示すようなイーサレベルでのフレームの衝突に応じたイーサフレームの再送を検出するためである。
【００４０】
重複していれば、上りパケット処理部１０２は、衝突数テーブル１０６において、ステップＳ５５の判断結果に応じて、メッセージ先頭又はメッセージ内の衝突回数を１インクリメントする（ステップＳ６３）。その後処理は端子Ｅを介して元の処理に戻る。
【００４１】
一方、重複していなければ、上りパケット処理部１０２は、受信パケットのＴＣＰヘッダからシーケンス番号（以下、上りシーケンス番号と呼ぶ）を抽出する（ステップＳ６５）。そして、上りシーケンス番号と第１シーケンス番号テーブル１０７における該当レコードの上りシーケンス番号（区別するために上り番号と呼ぶ）とが一致するか判断する（ステップＳ６７）。この条件を満たす場合には、ロスも再送も発生していないので端子Ｆを介して図２５のステップＳ８１に移行する。一方、この条件を満たさない場合には、ロス又は再送が発生しているので端子Ｇを介して図２５のステップＳ６９に移行する。
【００４２】
図２５の処理の説明に移行して、上りパケット処理部１０２は、受信パケットのＴＣＰヘッダにおける上りシーケンス番号が第１シーケンス番号テーブル１０７における該当レコードの上り番号より大きいか判断する（ステップＳ６９）。このような条件を満たす場合には、図７に示すような上りパケットロスを検出したことになる。従って、第２シーケンス番号テーブル１０８における該当レコードの上りロス回数を１インクリメントすると共に、リスト構造を辿って末端に上り番号を含むリストのデータブロックを追加する（ステップＳ７１）。リストのデータブロックは、ロスしたパケットの再送が後に発生した場合に衝突回数をダブルカウントしないようにするために用いられる。さらに、衝突数テーブル１０６における該当レコードにおいて、ステップＳ５５の判断結果に応じて、メッセージの先頭又はメッセージ内の衝突回数を１インクリメントする（ステップＳ７３）。そしてステップＳ８１に移行する。
【００４３】
一方、ステップＳ６９の条件を満たさない場合には、図６に示すようなパケットの再送が発生していることが分かるので、上りパケット処理部１０２は、受信パケットのコネクション情報で第２シーケンス番号テーブル１０８を検索して該当レコードを特定すると共に、該当レコードで指し示されているリスト構造において上りシーケンス番号に該当するリストを検索する（ステップＳ７５）。検索の結果リストが存在しない場合には、何らかの理由でロスを検出せずに再送が行われたという状態でありステップＳ７３に移行する。すなわち、衝突回数を１インクリメントする。一方、検索の結果リストが存在する場合には、再送において衝突回数を１インクリメントしているので、同じ事象について衝突回数をインクリメントすることはできない。従って、第２シーケンス番号テーブル１０８の該当レコードにおいて、上りシーケンス番号に該当するリストのデータブロックを削除する（ステップＳ７９）。なお、リンクの途中のリストが削除対象であれば、リンク切れが発生するので、１つ前のリストのデータブロックにおけるＮｅｘｔアドレスを１つ後のリストのデータブロックのアドレスに変更する。処理はステップＳ８１に移行する。
【００４４】
ステップＳ８１では、上りパケット処理部１０２は、受信パケットのセグメント長（＝（ＩＰパケットに含まれるパケット長−ＩＰヘッダ長−ＴＣＰヘッダ長））を取得する。そして、受信パケットのＴＣＰヘッダにおける上りシーケンス番号にセグメント長を加算し、当該加算結果で第１シーケンス番号テーブル１０７の該当レコードにおける上りシーケンス番号を更新する（ステップＳ８３）。この加算結果が予測シーケンス番号となる。そして元の処理に戻る。
【００４５】
このようにすれば、セグメントのデータを含むパケット（イーサフレームを含む）を検査して主にシーケンス番号をベースに判断することにより、図６乃至図８で示した衝突の事象を適切に検出して、衝突数テーブル１０６及びセグメント数テーブル１０５に反映させることができる。
【００４６】
次に、下りパケット処理について図２６及び図２７を用いて説明する。下りパケット処理はほぼ上りパケット処理と同様である。まず、下りパケット処理部１０３は、受信イーサフレームをそのままフレームバッファ１０９に格納する（ステップＳ９１）。フレームバッファ１０９は、１つのコネクションについて例えば２０ｍｓｅｃ分のイーサフレームを格納できる程度のサイズを有しており、古いものから順に上書きする形でバッファリングする。また、受信パケットにおいて、アプリケーション層のメッセージヘッダをチェックし（ステップＳ９３）、当該メッセージヘッダに含まれる情報からメッセージの先頭であるか否かを判断する（ステップＳ９５）。メッセージの先頭でなければステップＳ９９に移行する。
【００４７】
メッセージの先頭であれば、下りパケット処理部１０３は、メッセージヘッダに含まれるメッセージ長のデータを用いてメッセージの末尾に相当するシーケンス番号を（第１シーケンス番号テーブル１０７の下りシーケンス番号＋メッセージ長）で算出し、第１シーケンス番号テーブル１０７における該当コネクションについてのレコードの下り終了シーケンス番号の列を更新する（ステップＳ９７）。処理はステップＳ９９に移行する。
【００４８】
ステップＳ９９では、下りパケット処理部１０３は、セグメント数テーブル１０５において、ステップＳ９５の判断結果に応じて、メッセージ先頭のセグメントの出現回数又はメッセージ内のセグメントの出現回数を１インクリメントする。そして、フレームバッファ１０９にステップＳ５１で格納したイーサフレームと同一のイーサフレームが完全に重複しているか否かを判断する（ステップＳ１０１）。これは、図８に示すようなイーサレベルでのフレームの衝突に応じたイーサフレームの再送を検出するためである。
【００４９】
重複していれば、下りパケット処理部１０３は、衝突数テーブル１０６において、ステップＳ９５の判断結果に応じて、メッセージ先頭又はメッセージ内の衝突回数を１インクリメントする（ステップＳ１０３）。その後処理は端子Ｈを介して元の処理に戻る。
【００５０】
一方、重複していなければ、下りパケット処理部１０３は、受信パケットのＴＣＰヘッダからシーケンス番号（以下、下りシーケンス番号と呼ぶ）を抽出する（ステップＳ１０５）。そして、下りシーケンス番号と第１シーケンス番号テーブル１０７における該当レコードの下りシーケンス番号（区別するために下り番号と呼ぶ）とが一致するか判断する（ステップＳ１０７）。この条件を満たす場合には、ロスも再送も発生していないので端子Ｊを介して図２７のステップＳ１２１に移行する。一方、この条件を満たさない場合には、ロス又は再送が発生しているので端子Ｋを介して図２７のステップＳ１０９に移行する。
【００５１】
図２７の処理の説明に移行して、下りパケット処理部１０３は、受信パケットのＴＣＰヘッダにおける下りシーケンス番号が第１シーケンス番号テーブル１０７における該当レコードの下り番号より大きいか判断する（ステップＳ１０９）。このような条件を満たす場合には、図７に示すような下りパケットロスを検出したことになる。従って、第２シーケンス番号テーブル１０８における該当レコードの下りロス回数を１インクリメントすると共に、リスト構造を辿って末端に下り番号を含むリストのデータブロックを追加する（ステップＳ１１１）。リストのデータブロックは、ロスしたパケットの再送が後に発生した場合に衝突回数をダブルカウントしないようにするために用いられる。さらに、衝突数テーブル１０６における該当レコードにおいて、ステップＳ９５の判断結果に応じて、メッセージの先頭又はメッセージ内の衝突回数を１インクリメントする（ステップＳ１１３）。そしてステップＳ１２１に移行する。
【００５２】
一方、ステップＳ１０９の条件を満たさない場合には、図６に示すようなパケットの再送が発生していることが分かるので、下りパケット処理部１０３は、受信パケットの下りコネクション情報で第２シーケンス番号テーブル１０８を検索して該当レコードを特定すると共に、該当レコードで指し示されているリスト構造において下りシーケンス番号に該当するリストを検索する（ステップＳ１１５）。検索の結果リストが存在しない場合には、何らかの理由でロスを検出せずに再送が行われたという状態でありステップＳ１１３に移行する。すなわち、衝突回数を１インクリメントする。一方、検索の結果リストが存在する場合には、再送において衝突回数を１インクリメントしているので、同じ事象について衝突回数をインクリメントすることはできない。そこで、第２シーケンス番号テーブル１０８の該当レコードにおいて、下りシーケンス番号に該当するリストのデータブロックを削除する（ステップＳ１１９）。なお、リンクの途中のリストが削除対象であればリンク切れが発生するので、１つ前のリストのデータブロックにおけるＮｅｘｔアドレスを１つ後のリストのデータブロックのアドレスに変更する。処理はステップＳ１２１に移行する。
【００５３】
ステップＳ１２１では、下りパケット処理部１０３は、受信パケットのセグメント長（＝（ＩＰパケットに含まれるパケット長−ＩＰヘッダ長−ＴＣＰヘッダ長））を取得する。そして、受信パケットのＴＣＰヘッダにおける下りシーケンス番号にセグメント長を加算し、当該加算結果で第１シーケンス番号テーブル１０７の該当レコードにおける下りシーケンス番号を更新する（ステップＳ１２３）。この加算結果が予測シーケンス番号となる。そして元の処理に戻る。
【００５４】
このようにすれば、セグメントのデータを含むパケット（イーサフレームを含む）を検査して主にシーケンス番号をベースに判断することにより、図６乃至図８で示した衝突の事象を適切に検出して、衝突数テーブル１０６及びセグメント数テーブル１０５に反映させることができる。
【００５５】
次に、蓄積データ格納部１１０に格納されているデータを用いて動作モード違いや間欠障害が発生しているか否かについて判断する集計処理について図２８乃至図３１を用いて説明する。なお、集計処理については、定期的に実施するようにしても良いし、ユーザからの指示に応じて実施するようにしても良い。
【００５６】
まず、評価処理部１１１は、蓄積データ格納部１１０の蓄積セグメント数テーブル及び蓄積衝突数テーブルに格納されている、一定時間内のレコードをコネクション毎にソートする（ステップＳ１３１）。一定時間についてはユーザに指定された時間を採用するか、又は定期的に所定時間だけシフトさせるようにして決定する。また、例えば生成時刻と消滅時刻の両方が一定期間に含まれるレコードを処理対象とする。そして、未処理のコネクションを１つ特定する（ステップＳ１３３）。１つのコネクションにつき複数レコード抽出される場合がある。また、上りと下りとをここでは区別しない。さらに、特定されたコネクションの先頭衝突数（＝メッセージ先頭の衝突回数の合計）／先頭セグメント数（＝メッセージ先頭のセグメント出現回数の合計）によりメッセージ先頭衝突率を算出し、例えばメインメモリなどの記憶装置に格納する（ステップＳ１３５）。さらに、特定されたコネクションのメッセージ内衝突数（＝メッセージ内の衝突回数の合計）／メッセージ内セグメント数（＝メッセージ内のセグメントの出現回数の合計）によりメッセージ内衝突率を算出し、例えばメインメモリ等の記憶装置に格納する（ステップＳ１３７）。
【００５７】
その後、評価処理部１１１は、メッセージ先頭衝突率とメッセージ内衝突率が一致するか判断する（ステップＳ１３９）。例えば衝突数が０であればこのような条件が満たされることになる。この条件を満たす場合には、特に問題が発生しているわけではないので、コネクション情報と共に正常を表すデータを、例えば蓄積データ格納部１１０に格納する（ステップＳ１４１）。例えば図２９に示すような判定結果テーブルにデータを登録する。図２９の例では、接続先ＩＰアドレス（＝宛先ＩＰアドレス）と、接続先ポート番号（＝宛先ポート番号）と、接続元ＩＰアドレス（＝送信元ＩＰアドレス）と、接続元ポート番号（＝送信元ポート番号）と、判定結果（「正常」「動作モード違い」又は「間欠障害」）とが登録されるようになっている。処理は端子Ｌを介して図３０に移行して処理を終了する。
【００５８】
一方、メッセージ先頭衝突率とメッセージ内衝突率が一致しない場合には、評価処理部１１１は、メッセージ先頭衝突率＜メッセージ内衝突率であるか否かを判断する（ステップＳ１４３）。この条件を満たす場合には、上で述べたように動作モード違いと判断できるので、コネクション情報と動作モード違いを表すデータを、例えば蓄積データ格納部１１０の判定結果テーブルに格納する（ステップＳ１４７）。そしてステップＳ１４９に移行する。一方、この条件を満たさない場合には、コネクション情報と伝送路間欠障害を表すデータを、例えば蓄積データ格納部１１０の判定結果テーブルに格納する（ステップＳ１４５）。そしてステップＳ１４９に移行する。
【００５９】
ステップＳ１４９においては、評価処理部１１１は、全てのコネクションについて処理したか判断し、未処理のコネクションが存在する場合には、端子Ｍを介してステップＳ１３３に戻る。一方、全てのコネクションについて処理した場合には、端子Ｎを介して図３０の処理に移行する。
【００６０】
図３０の処理の説明に移行して、評価処理部１１１は、コネクション毎の結果を装置間毎に集計して、集計結果を例えば蓄積データ格納部１１０に格納する（ステップＳ１５１）。例えば図３１に示すようなデータを生成する。具体的には、接続先ＩＰアドレスと接続元ＩＰアドレスの組み合わせ毎に、正常と判定されたコネクションの有無と、動作モード違いと判定されたコネクションの有無と、間欠障害と判定されたコネクションの有無とを登録するようになっている。接続先ＩＰアドレスと接続元ＩＰアドレスとの組み合わせは入れ替わっていても同じものとして集約する。なお、動作モード違いと間欠障害とは同時に発生することもある。従って、動作モード違いと判定されたコネクションも間欠障害と判定されたコネクションも含む場合がある。
【００６１】
そして、出力部１１２は、蓄積データ格納部１１０に格納されているデータを、例えばユーザからの要求に応じて出力する（ステップＳ１５３）。例えば、蓄積データ格納部１１０に格納されているデータをそのまま要求された部分について出力するようにしても良いし、例えば間欠障害が検出された装置のデータや動作モード違いが検出された装置のデータのみを出力するようにしても良い。さらに、後者のようなデータについては、検出された場合には予め設定されているユーザに対してメールなどで通知するような構成を採用するようにしても良い。
【００６２】
以上のように、ネットワークの状況を、特別なパケットを送信することなく通常のパケットをキャプチャすることによって得られたデータにより把握することができるようになる。動作モード違いが検出された装置間の伝送路については、その設定の状態を確認して正しい設定に直せば通常どおり使用することができる。また、間欠障害が検出された場合には、ケーブルの交換などを含む他の周知の手法を用いて障害除去を行うことができる。
【００６３】
以上本技術の実施の形態を説明したが、本実施の形態はこれに限定されるものではない。例えば、ＡＣＫパケットを用いないような処理フローを示したが、ＡＣＫパケットの応答確認番号を参照した上でパケットのロスや再送を特定するようにしても良い。
【００６４】
さらに、上で述べた処理は一例であり、処理結果が変わらなければ処理ステップの順番を入れ替えたり並列に実行するようにしても良い。また、シーケンス番号を用いる処理で、正しく衝突がカウントできればよいので、他の処理フローを採用するようにしても良い。さらに、図１３の機能ブロック図も一例であって、必ずしも実際のプログラムモジュール構成と一致しない場合もある。
【００６５】
なお、上で述べた分析装置１００は、コンピュータ装置であって、図３２に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【００６６】
以上本実施の形態をまとめると以下のようになる。
【００６７】
本動作モード相違検出方法は、１のメッセージを１又は複数のセグメントに分割してパケットを送信する場合、２つの装置間のコネクション毎に、上記１のメッセージにおける先頭セグメントについての第１のパケットの数をカウントすると共に、上記１のメッセージにおける先頭セグメント以外のセグメントについての第２のパケットの数をカウントして、セグメント数データ格納部に格納するステップと、コネクション毎且つ上り方向及び下り方向の各々について、パケットに含まれるシーケンス番号とシーケンス番号の予測値と下位階層フレームの再送の有無とに基づき、第１のパケット及び第２のパケットに、ロス又は再送が発生しているか判断する判断ステップと、第１のパケットにロス又は再送が発生していると判断された場合には、コネクション毎に第１のパケットについての衝突数及び第２のパケットについての衝突数を格納する衝突数データ格納部において、第１のパケットが関連するコネクションで送信される第１のパケットについての衝突数を増加させ、第２のパケットにロス又は再送が発生していると判断された場合には、衝突数データ格納部において、第２のパケットが関連するコネクションで送信される第２のパケットについての衝突数を増加させるステップと、コネクション毎に、第１のパケットについての衝突数を第１のパケットの数で除することによって得られるメッセージ先頭衝突率と、第２のパケットについての衝突数を第２のパケットの数で除することによって得られるメッセージ内衝突率とを比較するステップと、メッセージ内衝突率がメッセージ先頭衝突率より大きい場合に、当該コネクションの両端の装置に動作モード相違が存在することを表す結果データを、コネクションの情報に対応付けて処理結果格納部に格納するステップとを含む。
【００６８】
あるアプリケーション間でやりとりされるメッセージは、当該メッセージのサイズが大きければ複数のセグメントに分割され、複数パケット（同じく複数フレーム）として送信される。この複数のフレームの送信間隔は短く、メッセージ間の送信間隔は相対的に長くなる。もし通信している装置間に動作モード相違が存在する場合に送信間隔が短ければ、フレーム衝突がより多く発生するので、上で述べるメッセージ内衝突率が大きな値になる。一方、送信間隔が相対的に長いメッセージの先頭パケットについての衝突率であるメッセージ先頭衝突率は、動作モード相違の場合には相対的に小さくなる。従って、上で述べたように、メッセージ内衝突率＞メッセージ先頭衝突率が成立する場合には、動作モード相違が存在するものとして記録するものである。
【００６９】
また、メッセージ内衝突率がメッセージ先頭衝突率より小さい場合に、伝送路間欠障害が存在することを表す結果データを、コネクションの情報に対応付けて処理結果格納部に格納するステップをさらに含むようにしても良い。間欠障害があればイーサフレームの衝突自体はメッセージ内もメッセージ先頭も均等に発生するが、上で述べたのと逆にメッセージ内衝突率＜メッセージ先頭衝突率が成立する場合には、伝送路間欠障害が発生していると推測できる。
【００７０】
さらに、処理結果格納部に登録されているコネクションを上記装置の組み合わせ毎に集約すると共に、コネクションに対応する結果データを上記装置の組み合わせ毎に集約するステップをさらに含むようにしても良い。このようにすれば、どの装置について設定を修正すべきなのか、どの伝送路の検査を行うべきなのかを総合的に特定することができるようになる。
【００７１】
なお、上で述べたような処理をコンピュータに実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。
【符号の説明】
【００７２】
１０１コネクション関連処理部１０２上りパケット処理部
１０３下りパケット処理部１０４コネクション情報テーブル
１０５セグメント数テーブル１０６衝突数テーブル
１０７第１シーケンス番号テーブル
１０８第２シーケンス番号テーブル
１０９フレームバッファ１１０蓄積データ格納部
１１１評価処理部１１２出力部

【特許請求の範囲】
【請求項１】
１のメッセージを１又は複数のセグメントに分割してパケットを送信する場合、２つの装置間のコネクション毎に、前記１のメッセージにおける先頭セグメントについての第１のパケットの数をカウントすると共に、前記１のメッセージにおける先頭セグメント以外のセグメントについての第２のパケットの数をカウントして、セグメント数データ格納部に格納するステップと、
前記コネクション毎且つ上り方向及び下り方向の各々について、前記パケットに含まれるシーケンス番号と前記シーケンス番号の予測値と下位階層フレームの再送の有無とに基づき、前記第１のパケット及び前記第２のパケットに、ロス又は再送が発生しているか判断する判断ステップと、
前記第１のパケットに前記ロス又は再送が発生していると判断された場合には、前記コネクション毎に前記第１のパケットについての衝突数及び前記第２のパケットについての衝突数を格納する衝突数データ格納部において、前記第１のパケットが関連するコネクションで送信される前記第１のパケットについての衝突数を増加させ、前記第２のパケットに前記ロス又は再送が発生していると判断された場合には、前記衝突数データ格納部において、前記第２のパケットが関連するコネクションで送信される前記第２のパケットについての衝突数を増加させるステップと、
前記コネクション毎に、前記第１のパケットについての衝突数を前記第１のパケットの数で除することによって得られるメッセージ先頭衝突率と、前記第２のパケットについての衝突数を前記第２のパケットの数で除することによって得られるメッセージ内衝突率とを比較するステップと、
前記メッセージ内衝突率が前記メッセージ先頭衝突率より大きい場合に、当該コネクションの両端の装置に動作モード相違が存在することを表す結果データを、前記コネクションの情報に対応付けて処理結果格納部に格納するステップと、
を、コンピュータに実行させるための動作モード相違検出プログラム。
【請求項２】
前記メッセージ内衝突率が前記メッセージ先頭衝突率より小さい場合に、伝送路間欠障害が存在することを表す結果データを、前記コネクションの情報に対応付けて前記処理結果格納部に格納するステップ
をさらにコンピュータに実行させるための請求項１記載の動作モード相違検出プログラム。
【請求項３】
前記処理結果格納部に登録されている前記コネクションを前記装置の組み合わせ毎に集約すると共に、前記コネクションに対応する前記結果データを前記装置の組み合わせ毎に集約するステップ
をさらにコンピュータに実行させるための請求項１又は２記載の動作モード相違検出プログラム。
【請求項４】
１のメッセージを１又は複数のセグメントに分割してパケットを送信する場合、２つの装置間のコネクション毎に、前記１のメッセージにおける先頭セグメントについての第１のパケットの数をカウントすると共に、前記１のメッセージにおける先頭セグメント以外のセグメントについての第２のパケットの数をカウントして、セグメント数データ格納部に格納するステップと、
前記コネクション毎且つ上り方向及び下り方向の各々について、前記パケットに含まれるシーケンス番号と前記シーケンス番号の予測値と下位階層フレームの再送の有無とに基づき、前記第１のパケット及び前記第２のパケットに、ロス又は再送が発生しているか判断する判断ステップと、
前記第１のパケットに前記ロス又は再送が発生していると判断された場合には、前記コネクション毎に前記第１のパケットについての衝突数及び前記第２のパケットについての衝突数を格納する衝突数データ格納部において、前記第１のパケットが関連するコネクションで送信される前記第１のパケットについての衝突数を増加させ、前記第２のパケットに前記ロス又は再送が発生していると判断された場合には、前記衝突数データ格納部において、前記第２のパケットが関連するコネクションで送信される前記第２のパケットについての衝突数を増加させるステップと、
前記コネクション毎に、前記第１のパケットについての衝突数を前記第１のパケットの数で除することによって得られるメッセージ先頭衝突率と、前記第２のパケットについての衝突数を前記第２のパケットの数で除することによって得られるメッセージ内衝突率とを比較するステップと、
前記メッセージ内衝突率が前記メッセージ先頭衝突率より大きい場合に、当該コネクションの両端の装置に動作モード相違が存在することを表す結果データを、前記コネクションの情報に対応付けて処理結果格納部に格納するステップと、
を含み、コンピュータに実行される動作モード相違検出方法。
【請求項５】
１のメッセージを１又は複数のセグメントに分割してパケットを送信する場合、２つの装置間のコネクション毎に、前記１のメッセージにおける先頭セグメントについての第１のパケットの数を上り方向についてカウントすると共に、前記１のメッセージにおける先頭セグメント以外のセグメントについての第２のパケットの数を前記上り方向についてカウントして、セグメント数データ格納部に格納し、前記コネクション毎であって前記上り方向について、前記パケットに含まれるシーケンス番号と前記シーケンス番号の予測値と下位階層フレームの再送の有無とに基づき、前記第１のパケット及び前記第２のパケットに、ロス又は再送が発生しているか判断し、前記第１のパケットに前記ロス又は再送が発生していると判断された場合には、前記コネクション毎に前記第１のパケットについての衝突数及び前記第２のパケットについての衝突数を格納する衝突数データ格納部において、前記第１のパケットが関連するコネクションで送信される前記第１のパケットについての衝突数を増加させ、前記第２のパケットに前記ロス又は再送が発生していると判断された場合には、前記衝突数データ格納部において、前記第２のパケットが関連するコネクションで送信される前記第２のパケットについての衝突数を増加させる手段と、
前記コネクション毎に、前記第１のパケットの数を下り方向についてカウントすると共に、前記１のメッセージにおける先頭セグメント以外のセグメントについての第２のパケットの数を前記下り方向についてカウントして、セグメント数データ格納部に格納し、前記コネクション毎であって前記下り方向について、前記パケットに含まれるシーケンス番号と前記シーケンス番号の予測値と下位階層フレームの再送の有無とに基づき、前記第１のパケット及び前記第２のパケットに、ロス又は再送が発生しているか判断し、前記第１のパケットに前記ロス又は再送が発生していると判断された場合には、前記衝突数データ格納部において、前記第１のパケットが関連するコネクションで送信される前記第１のパケットについての衝突数を増加させ、前記第２のパケットに前記ロス又は再送が発生していると判断された場合には、前記衝突数データ格納部において、前記第２のパケットが関連するコネクションで送信される前記第２のパケットについての衝突数を増加させる手段と、
前記コネクション毎に、前記第１のパケットについての衝突数を前記第１のパケットの数で除することによって得られるメッセージ先頭衝突率と、前記第２のパケットについての衝突数を前記第２のパケットの数で除することによって得られるメッセージ内衝突率とを比較し、前記メッセージ内衝突率が前記メッセージ先頭衝突率より大きい場合に、当該コネクションの両端の装置に動作モード相違が存在することを表す結果データを、前記コネクションの情報に対応付けて処理結果格納部に格納する手段と、
を有する動作モード相違検出装置。

【図１】