JP2015170203A - 検証方法、検証プログラムおよび検証装置 - Google Patents

検証方法、検証プログラムおよび検証装置 Download PDF

Info

Publication number
JP2015170203A
JP2015170203A JP2014045441A JP2014045441A JP2015170203A JP 2015170203 A JP2015170203 A JP 2015170203A JP 2014045441 A JP2014045441 A JP 2014045441A JP 2014045441 A JP2014045441 A JP 2014045441A JP 2015170203 A JP2015170203 A JP 2015170203A
Authority
JP
Japan
Prior art keywords
verification
response
query
server
transmitted
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
JP2014045441A
Other languages
English (en)
Inventor
智弘 清水
Toshihiro Shimizu
智弘 清水
武 安家
Takeshi Ake
武 安家
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2014045441A priority Critical patent/JP2015170203A/ja
Priority to US14/616,969 priority patent/US20150254293A1/en
Publication of JP2015170203A publication Critical patent/JP2015170203A/ja
Ceased legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44Program or device authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/64Protecting data integrity, e.g. using checksums, certificates or signatures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2455Query execution
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/34Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/284Relational databases

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Mining & Analysis (AREA)
  • Signal Processing (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Computational Linguistics (AREA)
  • Databases & Information Systems (AREA)
  • Debugging And Monitoring (AREA)

Abstract

【課題】パケットの順序を考慮した検証処理を実行することを課題とする。
【解決手段】検証装置は、検証対象装置からパケットを受信する。検証装置は、受信された前記パケットに対する応答を検証対象装置に送信する順序に関する情報を含んだ制御リストに基づいて、応答を検証対象装置に送信可能かを判定する。検証装置は、送信可能と判定した場合は、応答を検証対象装置に送信し、送信不可能と判断した場合は、応答が送信可能になるまで待機してから検証対象装置に送信する。
【選択図】図2

Description

本発明は、検証方法、検証プログラムおよび検証装置に関する。
従来から、稼働しているシステムにおいて、システムで動作するプログラムを更新またはシステムに新たなプログラムを追加する場合に、検証システムを用いて事前に検証することが行われている。例えば、Webサーバ、DB(DataBase)サーバ、クライアント装置で構成される3階層システムにおいて、Webサーバのプログラムをアップデートする場合に、同じ階層で構成された検証システムを用いてアップデートで異常が発生しないかを検証する。
検証システムとしては、キャプチャデータを利用した検証システムが知られている。例えば、検証システムは、実動システムからパケットをキャプチャして記録し、更新したプログラムを搭載した検証対象のサーバ装置に、キャプチャしたパケットを出力する。そして、検証システムは、検証対象のサーバ装置から受信した応答データと、キャプチャした応答データとを比較して、実動システムと同じ動きができているかを検証する。
特開2012−195699号公報 特開2010−282266号公報
しかしながら、上記技術では、所定のリクエストに対して応答があるか否かの検証しかできないので、検証環境でパケットの順序変更が発生した場合に、検証処理を維持することが困難であり、順序を考慮した検証を実行することができない。
例えば、3階層システムを例にして説明すると、検証システムにおいて、検証用Webサーバから検証用DBサーバへ発行されるリクエストの順番が何らかの要因で実動環境と変わる場合がある。この場合、検証用DBサーバは、キャプチャデータと異なる順序でリクエストを受信することになる。検証用DBサーバは、キャプチャしたデータ順序にしたがって応答を送信するので、リクエストの受信順序が異なると、応答を送信することができない。
また、検証用DBサーバが、リクエストの受信順に関係なく応答したとしても、応答されたデータが正しいデータか否かを判定できないので、検証処理そのものの信頼性が低下する。
1つの側面では、パケットの順序を考慮した検証処理を実行できる検証方法、検証プログラムおよび検証装置を提供することを目的とする。
第1の案では、検証方法は、検証対象装置からパケットを受信する処理を実行する。検証方法は、受信した前記パケットに対する応答を前記検証対象装置に送信する順序に関する情報を含んだ制御リストに基づいて、前記応答を前記検証対象装置に送信可能かを判定する処理を実行する。検証方法は、送信可能と判定した場合は、前記応答を前記検証対象装置に送信し、送信不可能と判断した場合は、前記応答が送信可能になるまで待機してから前記検証対象装置に送信する処理を実行する。
1実施形態によれば、パケットの順序を考慮した検証処理を実行できる。
図1は、実施例1に係るシステムの全体構成の例を示す図である。 図2は、実施例1に係る検証装置の機能構成を示す機能ブロック図である。 図3は、パケットキャプチャテーブルに記憶される情報の例を示す図である。 図4は、クエリ分析テーブルに記憶される情報の例を示す図である。 図5は、キュー管理テーブルに記憶される情報の例を示す図である。 図6は、検証結果テーブルに記憶される情報の例を示す図である。 図7は、クライアント擬似動作処理の流れを示すフローチャートである。 図8は、DBサーバ擬似動作処理の流れを示すフローチャートである。 図9は、観測時と検証時のパケット到着順を説明する図である。 図10は、実施例1に係る検証装置の処理を説明する図である。 図11は、実施例2に係るDBサーバ擬似動作処理の流れを示すフローチャートである。 図12は、実施例2に係る検証装置の処理を説明する図である。 図13は、デットロックの回避手法を説明する図である。 図14は、ハードウェア構成例を示す図である。
以下に、本願の開示する検証方法、検証プログラムおよび検証装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。各実施例は、矛盾のない範囲内で適宜組み合わせることができる。
[全体構成]
図1は、実施例1に係るシステムの全体構成の例を示す図である。図1に示すように、このシステムは、複数のクライアント端末1と実動AP(Application)サーバ2と実動DBサーバ3とスイッチ5とを有する実動環境と、検証装置10と検証APサーバ50とを有する検証環境とを有して構成される。なお、各環境が有する装置の数は一例であり、図示したものに限定されない。
実動環境は、検証環境とは別のネットワークで形成され、各クライアント端末1に対してWebサービス等の各種サービスを提供するシステムである。検証環境は、実動環境とは別のネットワークで形成され、実動環境で動作するサーバ等に対して、パッチやバージョンアップなどの更新作業を行う前に、更新作業後に機能面または性能面で退化がないかを検証するための検証システムである。
各クライアント端末1は、Webブラウザ等を用いて実動APサーバ2にアクセスして各サービスを利用するコンピュータであり、例えば実動APサーバ2を介して実動DBサーバ3が保持するデータベースを更新する。
実動APサーバ2は、クライアント端末1から要求を受信して、実動DBサーバ3へのトランザクションを実行するサーバであり、HTML文書などを蓄積してWebサービスを提供するWebアプリケーションサーバとしての機能を有していてもよい。
例えば、実動APサーバ2は、クライアント端末1から受信した要求に対応したアプリケーションを実行して、実動DBサーバ3へリクエストを送信する。そして、実動APサーバ2は、当該リクエストに対するレスポンスを実動DBサーバ3から受信して、クライアント端末1に送信する。
実動DBサーバ3は、データベースを有し、実動APサーバ2から受信したリクエストに応じてデータベース等の更新を実行し、その結果をレスポンスとして実動APサーバ2に送信する。なお、実動DBサーバ3が有するデータベースは、関係データベース、オブジェクトデータベース、KVS(キーバリューストア)など様々なデータベースを利用できる。
スイッチ5は、実動APサーバ2、実動DBサーバ3、各クライアント端末1の各々とポートを介して接続し、各装置間の通信をスイッチングするデータ中継装置である。例えば、スイッチ5としては、スイッチングハブ、ルータ、タップなどを用いることができる。このスイッチ5は、ポートミラーリングを実行しており、実動APサーバ2、実動DBサーバ3、クライアント端末1の各々から受信したデータを検証装置10に送信する。
検証環境は、実動環境で動作するサーバや実動環境に新たに接続するサーバを検証サーバとして検証装置10に接続する環境である。検証するタイミングとしては、上述した更新後の性能等を確認する他にも、サーバの移設等様々な状況が想定される。例えば、上記実動環境を自社内で運用していたが、実動APサーバ2だけをシステムインテグレータ等が提供するクラウド環境に移行する場合も該当する。この場合、検証装置10は、実動APサーバ2と同様の機能を有する検証APサーバ50に対して検証を実行する。
ここでは、一例として、実動APサーバ2を検証することとするので、検証環境は検証APサーバ50を有するものとする。検証APサーバ50は、実動APサーバ2と同様の機能を実装した検証対象のサーバであり、検証装置10と接続される。この検証APサーバ50には、検証APサーバ50が直接通信する検証対象外の装置である、実動DBサーバ3とクライアント端末1各々のアドレスとして、検証装置10のIP(Internet Protocol)アドレスを設定しておく。
すなわち、検証環境は、検証装置10がクライアント端末1および実動DBサーバ3の動作を擬似して、実動APサーバ2の動作を検証する。なお、クライアント端末1の動作を擬似する検証装置と、実動DBサーバ3の動作を擬似する検証装置とを別々の筐体で実行してもよい。
検証APサーバ50は、実動環境の実動APサーバ2が処理する実トランザクションと同様のトランザクションを実行して、データを検証装置10に送信する。また、検証APサーバ50は、検証装置10からパケットを受信した場合に、当該データに対応する応答データを検証装置10に送信する。
検証装置10は、検証対象装置である検証APサーバ50からパケットを受信する。そして、検証装置10は、受信したパケットに対する応答を検証APサーバ50に送信する順序に関する情報を含んだ制御リストに基づいて、検証APサーバ50に送信可能かを判定する。その後、検証装置10は、送信可能と判定した場合は、応答を検証APサーバ50に送信し、送信不可能と判断した場合は、受信したパケットに対する応答が送信可能になるまで待機してから検証APサーバ50に送信する。
例えば、検証装置10は、スイッチ5のポートミラーリング等を利用して、実動環境のパケットをキャプチャして保持する。そして、検証装置10は、検証APサーバ50の検証時に、検証環境で検証APサーバ50から受信したリクエストの到着順ではなく、実動環境で観測されたリクエストの到着順で、レスポンスを応答する。この結果、検証装置10は、パケットの順序を考慮した検証ができる。
[検証装置の機能構成]
図2は、実施例1に係る検証装置の機能構成を示す機能ブロック図である。図2に示すように、検証装置10は、通信処理部11、記憶部12、制御部20を有する。
通信処理部11は、少なくとも1つのポートを有し、検証装置10と検証APサーバ50との間の通信を制御する。また、通信処理部11は、検証装置10とスイッチ5との間の通信も制御する。
この通信処理部11の各ポートには、実動環境で使用するIPアドレスと、検証対象外装置のIPアドレスが設定される。図1の場合、通信処理部11の第1ポートには、実動環境用のIPアドレスが設定される。そして、通信処理部11の第2ポートには、実動DBサーバ3宛として使用されるIPアドレスが設定される。さらに、通信処理部11の第3ポートには、クライアント端末1宛として使用されるIPアドレスが設定される。
記憶部12は、メモリやハードディスクなどの記憶装置であり、パケットキャプチャテーブル13、クエリ分析テーブル14、キュー管理テーブル15、検証結果テーブル16を記憶する。
パケットキャプチャテーブル13は、複数の装置を有する実動環境内のパケットをキャプチャして得られた実キャプチャデータを保持するテーブルである。すなわち、パケットキャプチャテーブル13は、実動環境で実行されたトランザクションで発生したパケット情報を記憶する。パケットキャプチャテーブル13には、後述するパケットキャプチャ部21によって、1日や1週間など所定間隔でキャプチャされたキャプチャデータが格納される。
図3は、パケットキャプチャテーブルに記憶される情報の例を示す図である。図3に示すように、パケットキャプチャテーブル13は、「シーケンシャル番号、送信元、宛先、送信パケット、送信時間」などを対応付けて記憶する。
ここで記憶される「シーケンシャル番号」は、パケットキャプチャリングされた順番を示し、「送信元」は、キャプチャされたパケットの送信元を示す。「宛先」は、キャプチャされたパケットの宛先を示し、「送信パケット」は、キャプチャされたパケットの情報を示す。「送信時間」は、キャプチャされたパケットの送信時間を示す。なお、パケットキャプチャテーブル13は、上述した情報に対応付けて、キャプチャしたパケットそのものを保持していてもよい。また、パケットキャプチャテーブル13は、上記情報以外の情報として、例えばパケットの種別、処理の成否などを記憶してもよい。
図3の例の場合、1番目に、クライアント端末1から実動APサーバ2に対して、時刻T0に送信されたHTTP:req1がキャプチャされたことを示す。2番目に、クライアント端末1から実動APサーバ2に対して、時刻T1に送信されたHTTP:req2がキャプチャされたことを示す。3番目に、実動APサーバ2から実動DBサーバ3に送信されたSQL:req1がキャプチャされたことを示す。4番目に、実動DBサーバ3から実動APサーバ2に送信されたSQL:res1がキャプチャされたことを示す。なお、Reqは、Requestの略であり、Resは、Responseの略である。
クエリ分析テーブル14は、実動DBサーバ3に送信されたパケットの情報を記憶するテーブルである。すなわち、クエリ分析テーブル14は、実動環境で実動DBサーバ3へ発行されたSQL(Structured Query Language)文に関する情報を記憶する。
図4は、クエリ分析テーブルに記憶される情報の例を示す図である。図4に示すように、クエリ分析テーブル14は、「応答、クエリ番号、クエリ、要求種別、参照テーブル、成否、送信時間」を対応付けて記憶する。この情報は、後述するキャプチャ分析部22によって生成される。
ここで記憶される「応答」は、検証環境で応答として送信されたか否かを示す情報であり、送信された場合にはチェックされる。「クエリ番号」は、実動環境で発生したクエリの順番を示す番号である。「クエリ」は、実動環境で発生したクエリであり、例えばSQL文の詳細が設定される。「要求種別」は、発行されたSQL文の種別であり、ReadやWriteが設定される。「参照テーブル」は、発行されたSQL文の実行対象のテーブルを示す情報である。「成否」は、発行されたSQL文の成否であり、成功した場合は「成」、失敗した場合は「否」が設定される。「送信時間」は、実動環境においてSQLが発行された時間である。
図4の例は、いずれもまだ検証環境で実行されていない例である。また、図4の例は、クエリ番号1、2、3の順に、クエリ「SQL:req1」、「SQL:req2」、「SQL:req3」を発行して検証することを示している。そして、「SQL:req1」は、テーブルAをReadするクエリであり、実動環境では時刻T2に実行されて成功したことを示す。
キュー管理テーブル15は、検証環境で検証APサーバ50に送信するパケットを保持するキューの状態を管理するテーブルである。図5は、キュー管理テーブルに記憶される情報の例を示す図である。ここで記憶される情報は、随時更新される。図5に示すように、キュー管理テーブル15は、「先行クエリ待ちキュー、待ちクエリ」を対応付けて記憶する。
ここで記憶される「先行クエリ待ちキュー」は、検証環境で未到着のクエリの列を示し、「待ちクエリ」は、検証環境で現在到着を待っている、次に届くべきクエリを示す。図5の場合、検証環境で未到着のクエリはなく、クエリ名が「SQL:req1」であるクエリが次に送信すべきクエリであることを示している。
検証結果テーブル16は、検証APサーバ50に対して実行した検証処理の検証結果を記憶するテーブルである。図6は、検証結果テーブルに記憶される情報の例を示す図である。図6に示すように、検証結果テーブル16は、「検証対象装置、シーケンシャル番号、送信パケット、受信パケット、検証結果」を対応付けて記憶する。
ここで記憶される「検証対象装置」は、検証処理の対象を示し、本実施例では検証APサーバ50である。「シーケンシャル番号」は、検証したパケットの順番であり、パケットキャプチャテーブル13のシーケンシャル番号と同じである。「送信パケット」は、検証処理で送信したパケットを示し、「受信パケット」は、検証処理で受信したパケットを示す。「検証結果」は、検証結果を示し、実動環境と同じパケットが送受信された場合は「成功」が設定され、それ以外は「失敗」が設定される。
図6は、検証APサーバ50への検証結果を示している。この検証処理は、まず「HTTP:req1」が送信され、次に「HTTP:req2」が送信され、その後「SQL:req1」が受信され、いずれも実動環境と同じ順番であり、成功したことを示す。
制御部20は、プロセッサなどであり、パケットキャプチャ部21、キャプチャ分析部22、クライアント擬似部23、DBサーバ擬似部24、検証部25を有する。なお、各処理部は、電子回路やプロセッサが実行するプロセスの一例である。
パケットキャプチャ部21は、スイッチ5を介して、実動環境で実際に送受信されたパケットをキャプチャして、パケットキャプチャテーブル13に格納する処理部である。例えば、クライアント端末1が、実動APサーバ2にアクセスしてアプリケーションを実行し、実動APサーバ2が、アプリケーションの実行によって実動DBサーバ3に対してDBアクセスを実行したとする。
この場合、はじめに、パケットキャプチャ部21は、クライアント端末1から実動APサーバ2へのDB処理要求を示すパケットをキャプチャする。次に、パケットキャプチャ部21は、実動APサーバ2から実動DBサーバ3へ送信されたDBリクエストを示すパケットをキャプチャする。続いて、パケットキャプチャ部21は、実動DBサーバ3から実動APサーバ2へ送信されたDBレスポンスを示すパケットをキャプチャする。最後に、パケットキャプチャ部21は、実動APサーバ2からクライアント端末1へ送信されたDB処理要求に対する応答を示すパケットをキャプチャする。
つまり、パケットキャプチャ部21は、実動環境で実行されたトランザクションによって、実際に発生したパケットを発生した順番でキャプチャして、パケットキャプチャテーブル13に格納する。なお、パケットキャプチャ部21は、キャプチャしたパケットそのものをパケットキャプチャテーブル13に格納してもよい。
キャプチャ分析部22は、キャプチャされたパケットの情報から実動DBサーバ3へ発行されたパケットを抽出する処理部である。具体的には、キャプチャ分析部22は、パケットキャプチャテーブル13に記憶される情報を参照し、実動APサーバ2から実動DBサーバ3へ発行されたSQL文を抽出する。そして、キャプチャ分析部22は、抽出したSQL文について、参照先のテーブル、要求種別、成否、送信時間等を抽出する。その後、キャプチャ分析部22は、抽出した情報をクエリ分析テーブル14に格納する。
なお、キャプチャ分析部22が処理を実行するタイミングは、検証部25によって検証処理の開始を指示されたタイミングでもよく、パケットキャプチャテーブル13に情報が格納されたタイミングでもよく、任意に設定できる。検証処理の開始を指示されたタイミングで実行する場合、キャプチャ分析部22は、分析が完了したことをクライアント擬似部23およびDBサーバ擬似部24に通知する。
クライアント擬似部23は、実動環境におけるクライアント端末1の動作を擬似する処理部である。具体的には、クライアント擬似部23は、検証処理が開始されると、パケットキャプチャテーブル13を参照して、クライアント端末1が送信したHTTP:reqを検証APサーバ50に送信する。また、クライアント擬似部23は、検証APサーバ50からHTTP:resを受信する。
そして、クライアント擬似部23は、HTTP:reqを送信したことおよび送信時間と、HTTP:resを受信したことおよびHTTP:resの受信時間とを検証部25に出力する。
例えば、図3の場合、クライアント擬似部23は、検証APサーバ50にHTTP:req1を送信した後、「T1−T0」時間経過後に、検証APサーバ50にHTTP:req2を送信する。
DBサーバ擬似部24は、判定部24aと送信部24bとを有し、これらによって実動環境における実動DBサーバ3の動作を擬似する処理部である。
判定部24aは、検証対象の検証APサーバ50からパケットを受信すると、当該パケットに対する応答が送信可能か否かを判定する処理部である。具体的には、判定部24aは、検証対象の検証APサーバ50からSQL文を受信した場合、受信したSQL文の実行結果を検証APサーバ50に送信する順序に関する情報を含んだクエリ分析テーブル14やキュー管理テーブル15を参照する。そして、DBサーバ擬似部24は、応答を検証APサーバ50に送信可能かを判定する。
例えば、判定部24aは、検証処理が開始されると、クエリ分析テーブル14を参照して、応答を返信していない未受信のクエリのうち、最もクエリ番号が若いクエリを特定する。そして、判定部24aは、特定したクエリ番号に対応するクエリの名称等をキュー管理テーブル15の待ちクエリに格納して、キューの状態を管理する。
この状態で、判定部24aは、検証APサーバ50から新たなクエリを受信すると、新たなクエリがキュー管理テーブル15の待ちクエリと一致するかを判定する。そして、判定部24aは、新たなクエリが待ちクエリと一致する場合、応答を送信可能と判定し、新たなクエリの情報を送信部24bに出力する。また、判定部24aは、上記手法と同様の手法で、次の待ちクエリを特定して、キュー管理テーブル15の待ちクエリに格納する。
一方、判定部24aは、新たなクエリが待ちクエリと一致しない場合、応答を送信不可能と判定する。そして、判定部24aは、受信した新たなクエリの名称等を、キュー管理テーブル15の先行クエリ待ちキューに格納する。
その後、判定部24aは、検証APサーバ50からクエリをさらに受信すると、受信クエリがキュー管理テーブル15の待ちクエリと一致するかを判定する。そして、判定部24aは、受信クエリが待ちクエリと一致する場合、応答を送信可能と判定し、受信クエリの情報を送信部24bに出力する。続いて、判定部24aは、キュー管理テーブル15の先行クエリ待ちキューに格納されているクエリのうち先頭のクエリの情報を、待ちクエリに格納する。
一方、判定部24aは、受信クエリが待ちクエリと一致しない場合、応答を送信不可能と判定する。そして、判定部24aは、格納順になるように、先行クエリ待ちキューに格納されている最後のクエリの後ろに、受信クエリの情報を格納する。
このようにして、判定部24aは、キュー管理テーブル15を使用して待ちクエリの状態を管理し、検証APサーバ50から受信したクエリが実動環境で受信された順番と同じか否かを判定する。このようにして、判定部24aは、検証時も実動環境と同じ順番でパケットを送受信して、検証処理を実行する。
送信部24bは、判定部24aによって送信可能と判定されたクエリの応答を検証APサーバ50に送信する処理部である。具体的には、送信部24bは、判定部24aから送信可能と判定されたクエリの情報を受信すると、パケットキャプチャテーブル13を参照して、当該クエリの応答を特定する。その後、送信部24bは、特定したクエリの応答を検証APサーバ50に送信する。また、送信部24bは、クエリが受信されたこと、受信したクエリの情報、送信した応答クエリの情報などを検証部25に出力する。
検証部25は、ユーザの指示操作にしたがって検証処理を開始し、各処理部から検証結果を受信して検証結果テーブル16を作成する処理部である。具体的には、検証部25は、検証開始の指示を受け付けると、キャプチャ分析部22、クライアント擬似部23、DBサーバ擬似部24等に検証開始を指示する。
その後、検証部25は、クライアント擬似部23から、クライアント擬似部23が送信したHTTPリクエストとクライアント擬似部23が受信したHTTPレスポンスとに関する情報を受信する。同様に、検証部25は、DBサーバ擬似部24から、DBサーバ擬似部24が受信したSQLリクエストとDBサーバ擬似部24が送信したSQLレスポンスとに関する情報を受信する。
そして、検証部25は、受信したこれらの情報を検証結果テーブル16に格納するとともに、実動環境と同じ情報を送受信したかを判定する。検証部25は、実動環境と同じ情報を送受信した場合、検証結果に「成功」を格納し、実動環境と異なる情報を送受信した場合、検証結果に「失敗」を格納する。このようにして、検証部25は、検証環境で送受信された情報が実動環境と同じか否かを判定し、その結果を検証結果テーブル16に格納する。
[クライアント擬似処理の流れ]
図7は、クライアント擬似動作処理の流れを示すフローチャートである。図7に示すように、クライアント擬似部23は、検証部25によって検証処理の開始が指示されると(S101:Yes)、パケットキャプチャリングした全パケットの送信が完了しているかを判定する(S102)。
そして、クライアント擬似部23は、全パケットの送信が完了している場合(S102:Yes)、処理を終了する。
一方で、クライアント擬似部23は、全パケットの送信が完了していない場合(S102:No)、パケットキャプチャテーブル13を参照して、送信待ちのパケットがあるかを判定する(S103)。
そして、クライアント擬似部23は、送信待ちのパケットがある場合(S103:Yes)、クライアント端末1の動作を擬似的に実行して、検証対象の検証APサーバ50に対してパケットを送信する(S104)。つまり、クライアント擬似部23は、検証環境に、実動環境と同様のトランザクションを発生させる。
そして、クライアント擬似部23は、検証APサーバ50に対してパケットを送信したことで、パケットキャプチャテーブル13の全パケットに対して処理を実行した場合には(S102:Yes)、処理を終了する。
なお、S103において、クライアント擬似部23は、パケットキャプチャテーブル13に送信待ちのパケットが存在しないと判定した場合には(S103:No)、S102以降の処理を繰り返す。
[DBサーバ擬似処理の流れ]
図8は、DBサーバ擬似動作処理の流れを示すフローチャートである。図8に示すように、DBサーバ擬似部24の判定部24aは、検証APサーバ50からリクエストを受信すると(S201:Yes)、受信したリクエストがキュー管理テーブル15の待ちクエリと同一かを判定する(S202)。
そして、判定部24aによって受信クエリが待ちクエリと同一であると判定された場合(S202:Yes)、送信部24bは、受信クエリに対応するレスポンスをパケットキャプチャテーブル13から特定して、検証APサーバ50に応答する(S203)。
その後、判定部24aは、送信部24bによってリクエストが送信されると、キュー管理テーブル15の待ちクエリを更新する(S204)。例えば、判定部24aは、クエリ分析テーブル14において、送信したリクエストに対応するクエリの「応答」にチェックする。さらに、判定部24aは、クエリ分析テーブル14に記憶される分析結果にしたがって次の受信対象のクエリを特定して、キュー管理テーブル15の待ちクエリに格納する。
ここで、判定部24aは、キュー管理テーブル15の先行クエリ待ちキューが空である場合(S205:Yes)、処理中フラグを真に設定する(S206)。すなわち、判定部24aは、実動環境と同じ順番でリクエスト(SQL文)を受信していると判定する。なお、処理中フラグは、メモリ等に格納されており、判定部24aによって随時更新される。
一方、判定部24aは、キュー管理テーブル15の先行クエリ待ちキューにクエリが格納されている場合(S205:No)、先行クエリ待ちキューに格納されているクエリの先頭を削除して新たな待ちクエリとして登録する(S207)。
また、S202において、判定部24aが、受信クエリが待ちクエリと同一ではないと判定した場合(S202:No)、受信クエリをキュー管理テーブル15の先行クエリ待ちキューに格納する(S208)。続いて、判定部24aは、処理中フラグを偽に設定する(S209)、処理を終了する。
[パケットの到着順序の説明]
ここでは、パケットの到着順が観測時と検証時とで異なる場合の例を説明する。図9は、観測時と検証時のパケット到着順を説明する図である。なお、図9では、クライアント端末をCL、APサーバをAP、DBサーバをDBと記憶する場合がある。
図9に示すように、観測時すなわちパケットキャプチャリング時は、クライアント端末1から実動APサーバ2にHTTP:req1が送信された後、HTTP:req2が送信される。
実動APサーバ2は、上記2つのHTTPリクエストを受信した後、実動DBサーバ3にSQL:req1を送信し、実動DBサーバ3は、SQL:res1を実動APサーバ2に応答する。続いて、実動APサーバ2は、実動DBサーバ3にSQL:req2を送信し、実動DBサーバ3は、SQL:res2を実動APサーバ2に応答する。
その後、実動APサーバ2は、上記2つのSQLリクエストに対する応答を受信すると、HTTP:req1に対する応答としてHTTP:res1をクライアント端末1に応答する。さらにその後、実動APサーバ2は、HTTP:req2に対する応答としてHTTP:res2をクライアント端末1に応答する。
これに対して、検証時、クライアント端末1の動作を擬似する検証装置10から検証APサーバ50にHTTP:req1が送信された後、HTTP:req2が送信される。
検証APサーバ50は、上記2つのHTTPリクエストを受信した後、実動DBサーバ3の動作を擬似する検証装置10にSQL:req2を送信し、検証装置10は、SQL:res2を検証APサーバ50に応答する。続いて、検証APサーバ50は、検証装置10にSQL:req1を送信し、検証装置10は、SQL:res1を検証APサーバ50に応答する。
その後、検証APサーバ50は、上記2つのSQLリクエストに対する応答を受信すると、HTTP:res2、HTTP:res1を、クライアント端末1の動作を擬似する検証装置10に順次応答する。
両方を比較すると、クライアント端末1からAPサーバへのHTTPリクエストの順は、観測時と検証時とで順番が同じである。しかし、APサーバからDBサーバへのSQLリクエストは、観測時と検証時とで順番が異なる。このため、DBサーバからAPサーバへのSQLレスポンスも、観測時と検証時とで順番が異なる。さらに、APサーバからクライアント端末1へのHTTPレスポンスも異なる。
つまり、図9のような検証結果が得られた場合、検証装置10は、各リクエストに対する各レスポンスを受信しているが、受信順序が異なるところがある。この場合、検証装置10は、検証APサーバ50の内部処理等が原因か、検証装置10と検証APサーバ50間のネットワークが原因か、それ以外の原因があるのか判断できないので、検証処理の結果を判定することができない。
したがって、実施例1に係る検証装置10は、検証APサーバ50から受信したリクエストの順番が観測時と異なる場合でも、観測時と異なる順序になってから、レスポンスを応答する。つまり、検証装置10は、到着パケットの順番が変わった場合でも、意味的に正しい動作で、観測した結果との比較による単純なテストが可能な検証処理を再現する。
[処理の説明(具体例)]
次に、検証装置10がリクエストの到着順が観測時と異なる場合の処理の具体例を説明する。図10は、実施例1に係る検証装置の処理を説明する図である。なお、キュー管理テーブル15には、クエリ名等が登録されるが、ここでは説明上、クエリと記載する。しかし、クエリそのものではなくクエリ名と同一であるとする。
図10に示すように、検証装置10は、クエリ分析テーブル14を参照して、キュー管理テーブル15の待ちクエリに「SQL:req1」を格納する。この状態で、検証装置10は、検証APサーバ50から「SQL:req2」を受信する(S1)。
すると、検証装置10は、キュー管理テーブル15の待ちクエリ「SQL:req1」と、受信クエリ「SQL:req2」とが一致しないので、キュー管理テーブル15の先行クエリ待ちキューに受信クエリ「SQL:req2」を格納する(S2)。つまり、検証装置10は、受信クエリと待ちクエリとが一致しないので、到着順が変更されたと判断して、クエリに対する応答を抑制する。
その後、検証装置10は、検証APサーバ50から「SQL:req1」を受信する(S3)。すると、検証装置10は、キュー管理テーブル15の待ちクエリ「SQL:req1」と、受信クエリ「SQL:req1」とが一致するので、受信クエリ「SQL:req1」に対する応答「SQL:res1」を検証APサーバ50に送信する(S4)。そして、検証装置10は、クエリ分析テーブル14のクエリ「SQL:req1」の「応答」にフラグを立てる。
さらに、検証装置10は、先行クエリ待ちキューの「SQL:req2」を待ちクエリに移動させるが、「SQL:req2」はすでに受信済みなので、続けて、「SQL:req2」に対する応答「SQL:res2」を検証APサーバ50に送信する(S5)。そして、検証装置10は、クエリ分析テーブル14のクエリ「SQL:req2」の「応答」にフラグを立てる。
その後、検証装置10は、クエリ分析テーブル14を参照して、次の待ちクエリに「SQL:req3」を格納する(S6)。この状態で、検証装置10は、検証APサーバ50から「SQL:req3」を受信する(S7)。
すると、検証装置10は、キュー管理テーブル15の待ちクエリ「SQL:req3」と、受信クエリ「SQL:req3」とが一致するので、受信クエリ「SQL:req3」に対する応答「SQL:res3」を検証APサーバ50に送信する(S8)。そして、検証装置10は、クエリ分析テーブル14のクエリ「SQL:req3」の「応答」にフラグを立てる。
[効果]
このように、検証装置10は、キュー管理テーブル15とクエリ分析テーブル14とを用いて、次の受信対象であるクエリを管理することで、受信クエリが応答可能なクエリかを判断し、観測時と同じ順序で応答することができる。したがって、検証装置10は、到着パケットの順番が変わった場合でも、意味的に正しい動作で、観測した結果との比較による単純なテストが可能な検証処理を再現することができ、順序を考慮した検証を実行することができる。
実施例1では、検証時のリクエストの到着が観測時と異なる場合は、観測時と応答順が同じになるように、リクエストの到着を待って応答する例を説明したが、これに限定されるものではない。例えば、検証装置10は、未受信の先行クエリが後続のクエリに影響を与えないクエリの場合は、先行クエリを待たずに受信済みの後続クエリに対して応答することもできる。
そこで、実施例2では、検証装置10が、未受信の先行クエリが後続のクエリに影響を与えないクエリか否かを判定して、先行クエリを待たずに受信済みの後続クエリに対して応答する例を説明する。なお、検証装置10の機能構成は、実施例1と同様なので詳細な説明は省略する。
[処理の流れ]
図11は、実施例2に係るDBサーバ擬似動作処理の流れを示すフローチャートである。図11に示すように、DBサーバ擬似部24の判定部24aは、検証APサーバ50からリクエストを受信すると(S301:Yes)、受信したリクエストがキュー管理テーブル15の待ちクエリと同一かを判定する(S302)。
続いて、判定部24aによって受信クエリが待ちクエリと同一であると判定された場合(S302:Yes)、送信部24bは、処理中フラグが偽か否かを判定する(S303)。
そして、送信部24bは、処理中フラグが偽であると判定した場合(S303:Yes)、リクエストの到着順が観測時と同じ状態に戻ったことを示す到着順序復帰通知を検証APサーバ50に送信する(S304)。さらに、送信部24bは、受信クエリに対応するレスポンスをパケットキャプチャテーブル13から特定して検証APサーバ50に応答する(S305)。なお、S304とS305は、どちらが先に実行されてもよい。
一方で、送信部24bは、処理中フラグが偽ではないと判定した場合(S303:No)、受信クエリに対応するレスポンスをパケットキャプチャテーブル13から特定して検証APサーバ50に応答する(S306)。
S305またはS306の後、判定部24aは、送信部24bによってリクエストが送信されると、キュー管理テーブル15の待ちクエリを更新する(S307)。続いて、判定部24aは、キュー管理テーブル15の先行クエリ待ちキューが空である場合(S308:Yes)、処理中フラグを真に設定する(S309)。つまり、判定部24aは、リクエストの到着順が観測時とは異なっていたが、観測時と同じ状態に戻ったと判定する。
一方、判定部24aは、キュー管理テーブル15の先行クエリ待ちキューにクエリが格納されている場合(S308:No)、先行クエリ待ちキューに格納されているクエリの先頭を削除して新たな待ちクエリとして登録する(S310)。
また、S302において、判定部24aは、受信クエリが待ちクエリと同一ではないと判定した場合(S302:No)、受信クエリがread命令であるか否かを判定する(S311)。すなわち、判定部24aは、受信クエリに記述されるSQL文がテーブルをreadするSQL文か否かを判定する。
続いて、判定部24aは、受信クエリがread命令であると判定した場合(S311:Yes)、受信クエリが先行クエリを待たずに送信可能な条件を満たすか否かを判定する(S312)。例えば、判定部24aは、待ちクエリから受信クエリまで間の各クエリで受信クエリが参照するテーブルと共通のテーブル参照し、write命令かつ成功したクエリがあるかを、クエリ分析テーブル14等を用いて判定する。
そして、判定部24aは、受信クエリが先行クエリを待たずに送信可能な条件を満たすと判定した場合(S312:Yes)、処理中フラグを偽に設定する(S313)。つまり、判定部24aは、実動環境と異なる順番でリクエストを受信していると判定する。
送信部24bは、リクエストの到着順が観測時と異なることを示す到着順序変更通知を検証APサーバ50に送信する(S314)。さらに、送信部24bは、受信クエリに対応するレスポンスをパケットキャプチャテーブル13から特定して、検証APサーバ50に応答する(S315)。その後、判定部24aがS308以降を実行する。なお、S314とS315は、どちらが先に実行されてもよい。
一方、S312において、判定部24aは、受信クエリが先行クエリを待たずに送信可能な条件を満たないと判定した場合(S312:No)、受信クエリをキュー管理テーブル15の先行クエリ待ちキューに格納する(S316)。続いて、判定部24aは、処理中フラグを偽に設定して(S317)、処理を終了する。
また、S311において、判定部24aは、受信クエリがread命令ではないと判定した場合(S311:No)、S312を実行することなく、S316を実行する。
[処理の説明(具体例)]
次に、実施例2に係る検証装置10がリクエストの到着順が観測時と異なる場合の処理の具体例を説明する。図12は、実施例2に係る検証装置の処理を説明する図である。なお、キュー管理テーブル15には、クエリ名が登録されるが、ここでは説明上、クエリと記載するがクエリそのものではなくクエリ名と同一であるとする。
図12に示すように、検証装置10は、クエリ分析テーブル14を参照して、キュー管理テーブル15の待ちクエリに「SQL:req1」を格納する。この状態で、検証装置10は、検証APサーバ50から「SQL:req2」を受信する(S10)。
すると、検証装置10は、キュー管理テーブル15の待ちクエリ「SQL:req1」と、受信クエリ「SQL:req2」とが一致しないので、到着順序変更通知を検証APサーバ50およびクライアント擬似部23に送信する(S11)。
続いて、検証装置10は、受信クエリが先行クエリを待たずに送信可能な条件を満たすか否かを判定する。
具体的には、検証装置10は、クエリ分析テーブル14を参照して、受信クエリ「SQL:req2」がread命令であることを特定する。さらに、検証装置10は、クエリ分析テーブル14を参照して、受信クエリ「SQL:req2」の参照テーブルがTであることと、待ちクエリ「SQL:req1」の参照テーブルもTであることを特定する。そして、検証装置10は、クエリ分析テーブル14を参照して、待ちクエリ「SQL:req1」がread命令かつ成功しているクエリであると特定する。
この結果、検証装置10は、受信クエリがread命令であり、待ちクエリに登録される先行クエリが受信クエリと同じテーブルを参照するread命令かつ成功クエリであると判定し、先行クエリを待たずに受信クエリを応答可能と判定する。
したがって、検証装置10は、受信クエリ「SQL:req2」に対する応答「SQL:res2」を検証APサーバ50に送信する(S12)。そして、検証装置10は、クエリ分析テーブル14のクエリ「SQL:req2」の「応答」にフラグを立てる(S13)。
その後、検証装置10は、検証APサーバ50から「SQL:req1」を受信する(S14)。すると、検証装置10は、キュー管理テーブル15の待ちクエリ「SQL:req1」と、受信クエリ「SQL:req1」とが一致するので、受信クエリ「SQL:req1」に対する応答「SQL:res1」を検証APサーバ50に送信する(S15)。
続いて、検証装置10は、到着順序復帰通知およびクライアント擬似部23を検証APサーバ50に送信し(S16)クエリ分析テーブル14のクエリ「SQL:req1」の「応答」にフラグを立てる(S17)。
その後、検証装置10は、クエリ分析テーブル14を参照して、次のクエリが「SQL:req2」と判定するが、すでに受信済みおよび応答済みなので、さらに次の「SQL:req3」を待ちクエリに格納する(S18)。
この状態で、検証装置10は、検証APサーバ50から「SQL:req3」を受信し、待ちクエリ「SQL:req3」と受信クエリ「SQL:req3」とが一致するので、応答「SQL:res3」を検証APサーバ50に送信する。
[効果]
このように、検証装置10は、検証時のリクエスト順が観測時と異なる場合であっても、順序に関係なく応答可能な場合は、応答を送信することができる。したがって、観測時を同一順序になるまで待つ場合と比べて、検証処理の時間が短縮できる。さらに、時間が短縮できるにも関わらず、到着順による検証処理の不具合の発生を抑制できる。
また、検証装置10は、クライアントの擬似動作によってHTTPリクエストの発行の再現を観測通りに行うので、入力に対するレスポンスの順序が変わったときに、DBクエリの順序が変わったことによるものが原因と推測することができる。つまり、検証装置10は、リクエストの到着順が変更になった原因がネットワークの状態やサーバの状態というプログラムの変更に関連しない可能性が高いと判断できる。
また、検証装置10は、到着順が異なるリクエストの応答を送信する前に、到着順序変更通知を送信することができる。この結果、検証者は、どのリクエストの順序がどのタイミングで変更になったかを簡単に特定でき、原因究明にかかる時間の短縮が図れる。
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。
[デットロックの回避]
例えば、実施例1に係る検証装置10は、待ちクエリが到着するまで、それまでに受信した他のクエリに対して応答することができない。この場合、待ちクエリが、検証APサーバ50のプログラムミス等により、送信までに相当な時間がかかるクエリになったり、送信されなくなったクエリになったりすることも考えられる。このような場合、実施例1に係る検証装置10では、待ちクエリの到着を待ち続けることになり、検証処理が遅延するどころか検証処理そのものを終了できない。
そこで、検証装置10は、図13に示す手法で、このようなデットロック状態を回避することができる。図13は、デットロックの回避手法を説明する図である。例えば、検証装置10は、イベントの関連性からSQLリクエストを待つ上限時間を算出し、その上限時間を経過するまでにSQLリクエストを受信しない場合は、上限時間経過後に応答を送信する。ここで、検証装置10は、受信できなかったSQLリクエストに対する応答と受信できなかったことを示す通知とを送信してもよく、エラー通知を送信してもよい。
図13の例において、検証環境で、検証装置10が「SQL:req1」を受信できない状態とする。この場合、検証装置10は、観測時の情報から「SQL:req1」の前に送信されたHTTPリクエストが「HTTP:req1」と「HTTP:req2」であることを特定する。この結果、検証装置10は、「SQL:req1」と「HTTP:req1」および「HTTP:req2」について、イベントに関連性がある可能性が高いと判定する。
そして、検証装置10は、パケットキャプチャテーブル13を参照して、観測時の「HTTP:req1の送信時間−HTTP:res1の送信時間」と「HTTP:req2の送信時間−HTTP:res2の送信時間」のうち長い方の時間を算出する。続いて、検証装置10は、算出した長い方の時間(TTT)の定数倍を上記上限時間として算出する。
この結果、検証装置10は、デットロック状態を回避して、検証処理を続けることができる。また、検証装置10は、定数倍を乗算することにより、上記上限時間が短すぎになることを抑制し、本来成功するはずのものが失敗になる危険性を抑制できる。
[判定条件]
実施例2では、検証装置10は、待ちクエリから受信クエリまで間の各クエリにおいて、受信クエリが参照するテーブルと共通のテーブルを参照し、write命令かつ成功したクエリがあるかを判定する例を説明したが、判定条件はこれに限定されるものではない。
例えば、検証装置10は、受信クエリが参照するテーブルと同じテーブルを参照する待ちクエリが存在しない場合は、待ちクエリを待たずに、受信クエリの応答を送信可能と判断することもできる。このように、検証装置10は、未受信の先行クエリが後続のクエリに影響を与えない範囲で任意に条件を設定することができる。
なお、検証装置10は、複数のDBを統合して一つのDBにみせるデータウェアハウスを用いたアプリケーションや、複数の問い合わせをして最初に帰ってきた結果を返すアプリケーションについては、実施例1と同様に先行クエリを待ってから応答することもできる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
(ハードウェア)
図14は、ハードウェア構成例を示す図である。図14に示すように、検証装置10は、通信インタフェース10a、HDD(Hard Disk Drive)10b、メモリ10c、CPU(Central Processing Unit)10dを有する。また、図14に示した各部は、バス等で相互に接続される。
通信インタフェース10aは、他の装置との通信を制御するインタフェースであり、例えばネットワークインタフェースカードである。HDD10bは、図2等に示した機能を動作させるプログラムやDBを記憶する。
CPU10dは、図2等に示した各処理部と同様の処理を実行するプログラムをHDD10b等から読み出してメモリ10cに展開することで、図2等で説明した各機能を実行するプロセスを動作させる。
すなわち、このプロセスは、検証装置10が有する各処理部と同様の機能を実行する。具体的には、CPU10dは、パケットキャプチャ部21、キャプチャ分析部22、クライアント擬似部23、DBサーバ擬似部24、検証部25等と同様の機能を有するプログラムをHDD10b等から読み出す。そして、CPU10dは、パケットキャプチャ部21、キャプチャ分析部22、クライアント擬似部23、DBサーバ擬似部24、検証部25と同様の処理を実行するプロセスを実行する。
このように検証装置10は、プログラムを読み出して実行することで検証作成方法を実行する情報処理装置として動作する。また、検証装置10は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、検証装置10によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。
1 クライアント端末
2 実動APサーバ
3 実動DBサーバ
5 スイッチ
10 検証装置
11 通信処理部
12 記憶部
13 パケットキャプチャテーブル
14 クエリ分析テーブル
15 キュー管理テーブル
16 検証結果テーブル
20 制御部
21 パケットキャプチャ部
22 キャプチャ分析部
23 クライアント擬似部
24 DBサーバ擬似部
24a 判定部
24b 送信部
25 検証部
50 検証APサーバ

Claims (8)

  1. コンピュータが、
    検証対象装置からパケットを受信し、
    受信した前記パケットに対する応答を前記検証対象装置に送信する順序に関する情報を含んだ制御リストに基づいて、前記応答を前記検証対象装置に送信可能かを判定し、
    送信可能と判定した場合は、前記応答を前記検証対象装置に送信し、送信不可能と判断した場合は、前記応答が送信可能になるまで待機してから前記検証対象装置に送信する
    処理を実行することを特徴とする検証方法。
  2. 前記受信する処理は、前記検証対象装置がクライアント装置から受信したリクエストに基づいて送信したデータアクセス要求を前記パケットとして受信し、
    前記判定する処理は、前記制御リストに基づいて、前記データアクセス要求に先行する先行データアクセス要求が受信されたか否かを判定し、前記先行データアクセス要求が受信されていない場合に、前記データアクセス要求に対するアクセス応答を送信不可能と判定することを特徴とする請求項1に記載の検証方法。
  3. 前記判定する処理は、前記データアクセス要求に先行する前記先行データアクセス要求が未受信の場合であっても、前記制御リストに基づいて前記先行データアクセス要求がデータの読み出し要求と判定した場合、前記データアクセス要求に対する前記アクセス応答を前記検証対象装置に送信可能と判定することを特徴とする請求項2に記載の検証方法。
  4. 前記送信する処理は、前記データアクセス要求に対する前記アクセス応答を前記先行データアクセス要求に対するアクセス応答よりも先に送信する場合、データアクセス要求の受信順序が変更されたことを通知する順序変更通知を、前記クライアント装置に送信することを特徴とする請求項3に記載の検証方法。
  5. 前記送信する処理は、前記順序変更通知の送信後に受信されたデータアクセス要求が前記制御リストに基づいて順序通りと判定された場合、当該データアクセス要求に対するアクセス応答を送信する際に、データアクセス要求の受信順序が復帰したことを通知する順序復帰通知を前記クライアント装置に送信することを特徴とする請求項4に記載の検証方法。
  6. 前記送信する処理は、前記データアクセス要求に対する前記アクセス応答が送信不可能と判定された場合、前記クライアント装置が前記リクエストを送信してからレスポンスを受信するまでにかかる応答時間を前記制御リストに基づいて算出し、前記応答時間を用いて算出された所定時間が経過した後に、前記アクセス応答を前記検証対象装置に送信することを特徴とする請求項1に記載の検証方法。
  7. コンピュータに、
    検証対象装置からパケットを受信し、
    受信した前記パケットに対する応答を前記検証対象装置に送信する順序に関する情報を含んだ制御リストに基づいて、前記応答を前記検証対象装置に送信可能かを判定し、
    送信可能と判定した場合は、前記応答を前記検証対象装置に送信し、送信不可能と判断した場合は、前記応答が送信可能になるまで待機してから前記検証対象装置に送信する
    処理を実行させることを特徴とする検証プログラム。
  8. 検証対象装置からパケットを受信する受信部と、
    前記受信部によって受信された前記パケットに対する応答を前記検証対象装置に送信する順序に関する情報を含んだ制御リストに基づいて、前記応答を前記検証対象装置に送信可能かを判定する判定部と、
    前記判定部が送信可能と判定した場合は、前記応答を前記検証対象装置に送信し、前記判定部が送信不可能と判断した場合は、前記応答が送信可能になるまで待機してから前記検証対象装置に送信する送信部と
    を有することを特徴とする検証装置。
JP2014045441A 2014-03-07 2014-03-07 検証方法、検証プログラムおよび検証装置 Ceased JP2015170203A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2014045441A JP2015170203A (ja) 2014-03-07 2014-03-07 検証方法、検証プログラムおよび検証装置
US14/616,969 US20150254293A1 (en) 2014-03-07 2015-02-09 Information processing method, verifying device, and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014045441A JP2015170203A (ja) 2014-03-07 2014-03-07 検証方法、検証プログラムおよび検証装置

Publications (1)

Publication Number Publication Date
JP2015170203A true JP2015170203A (ja) 2015-09-28

Family

ID=54017553

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014045441A Ceased JP2015170203A (ja) 2014-03-07 2014-03-07 検証方法、検証プログラムおよび検証装置

Country Status (2)

Country Link
US (1) US20150254293A1 (ja)
JP (1) JP2015170203A (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007026306A (ja) * 2005-07-20 2007-02-01 Nec Corp プログラムテスト装置、方法、及び、プログラム
JP2010225044A (ja) * 2009-03-25 2010-10-07 Seiko Epson Corp テストプログラム生成方法、プログラム
JP2012195699A (ja) * 2011-03-15 2012-10-11 Fujitsu Ltd 検証装置、検証方法および検証プログラム

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2553609B1 (fr) * 1983-10-14 1985-12-27 Chomel Denis Systeme de multiplexage numerique temporel asynchrone a bus distribue
US4959816A (en) * 1987-12-28 1990-09-25 Kabushiki Kaisha Toshiba Semiconductor integrated circuit
US8260723B2 (en) * 2000-12-01 2012-09-04 Carrott Richard F Transactional security over a network
US7539760B1 (en) * 2003-09-12 2009-05-26 Astute Networks, Inc. System and method for facilitating failover of stateful connections
US20110264851A1 (en) * 2006-12-07 2011-10-27 Tae-Keun Jeon Memory system and data transmitting method thereof
GB2499415B (en) * 2012-02-15 2014-09-24 Tivarri Ltd A method of backing-up, and making available by alternative means, electronic data and software initially stored on a client server
JP5902702B2 (ja) * 2012-02-20 2016-04-13 パナソニック株式会社 イニシエータ装置、ターゲット装置、通信システム、タイムアウト検出方法、およびタイムアウト検出プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007026306A (ja) * 2005-07-20 2007-02-01 Nec Corp プログラムテスト装置、方法、及び、プログラム
JP2010225044A (ja) * 2009-03-25 2010-10-07 Seiko Epson Corp テストプログラム生成方法、プログラム
JP2012195699A (ja) * 2011-03-15 2012-10-11 Fujitsu Ltd 検証装置、検証方法および検証プログラム

Also Published As

Publication number Publication date
US20150254293A1 (en) 2015-09-10

Similar Documents

Publication Publication Date Title
US11385975B2 (en) Systems and methods for enabling a highly available managed failover service
US9367261B2 (en) Computer system, data management method and data management program
CN103034735B (zh) 一种大数据分布式文件导出方法
US11366728B2 (en) Systems and methods for enabling a highly available managed failover service
US11341005B2 (en) Systems and methods for enabling a highly available managed failover service
WO2020224098A1 (zh) 基于全局负载均衡的云存取方法、装置及存储介质
US20230052935A1 (en) Asynchronous accounting method and apparatus for blockchain, medium and electronic device
JP2012146083A (ja) セッション管理システム、セッション管理装置、サーバ装置およびセッション管理方法
WO2016070651A1 (zh) 软件中心系统
JP5157586B2 (ja) エミュレータ装置
JP5708078B2 (ja) 検証装置、検証方法および検証プログラム
US10091288B2 (en) Ordered execution of tasks
US10516628B2 (en) Transfer device, transfer system, and transfer method
US9378230B1 (en) Ensuring availability of data in a set being uncorrelated over time
JP5109901B2 (ja) セッションデータ共有方法
US9253244B1 (en) Subscription based polling for resource updates
CN116743619A (zh) 网络服务的测试方法、装置、设备及存储介质
KR20210044281A (ko) 클라우드 저하 모드에서 지속적인 디바이스 동작 안정성을 보장하기 위한 방법 및 장치
JP2015170203A (ja) 検証方法、検証プログラムおよび検証装置
CN111782721B (zh) 一种数据同步方法、装置、电子设备及存储介质
US12124344B2 (en) Systems and methods for enabling a highly available managed failover service
JP6101500B2 (ja) 情報管理装置、情報管理方法、情報管理プログラム
WO2014006713A1 (ja) システム、情報処理装置、取得方法および取得プログラム
CN116016374A (zh) 基于区块链的数据处理方法、装置、设备及可读存储介质
WO2022120313A1 (en) Methods for distributed key-value store

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20161102

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170804

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170808

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171006

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180306

A045 Written measure of dismissal of application [lapsed due to lack of payment]

Free format text: JAPANESE INTERMEDIATE CODE: A045

Effective date: 20180731