JP5630033B2 - バッファ管理プログラム及び方法、並びにメッセージ分析装置 - Google Patents

バッファ管理プログラム及び方法、並びにメッセージ分析装置 Download PDF

Info

Publication number
JP5630033B2
JP5630033B2 JP2010045010A JP2010045010A JP5630033B2 JP 5630033 B2 JP5630033 B2 JP 5630033B2 JP 2010045010 A JP2010045010 A JP 2010045010A JP 2010045010 A JP2010045010 A JP 2010045010A JP 5630033 B2 JP5630033 B2 JP 5630033B2
Authority
JP
Japan
Prior art keywords
packet
buffer
message
connection
transmission direction
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.)
Expired - Fee Related
Application number
JP2010045010A
Other languages
English (en)
Other versions
JP2011182211A (ja
Inventor
岩倉 廣和
廣和 岩倉
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 JP2010045010A priority Critical patent/JP5630033B2/ja
Publication of JP2011182211A publication Critical patent/JP2011182211A/ja
Application granted granted Critical
Publication of JP5630033B2 publication Critical patent/JP5630033B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Description

本技術は、コンピュータ間でやりとりされるメッセージの分析技術に関する。
例えばサーバ間でメッセージのやりとりを行って処理を進めるシステムの分析を、メッセージに含まれるパケットを取り込んで解析することによって行う場合、図1に示すような処理を行う。
具体的には、図1左側に示すように、例えばサーバを接続しているスイッチが当該スイッチを通過するパケットをコピーしてシステム分析装置に送信し、システム分析装置は自身が保持するNIC(Network Interface Card)を介してスイッチから送られてくるパケットの受信処理を実施する。この際パケットに対して受信時刻などの管理情報が付加される。その後、システム分析装置は、パケットバッファへのパケットの書込処理を行う。一方、図1右側に示すように、この書込処理とは非同期に、パケットをパケットバッファから読み出すパケット読み出し処理を実施し、1又は複数のパケットから1つのメッセージを組み立てるメッセージ組み立て処理を実施した後、メッセージ解析処理を実施する。
通常、図1左側に示した、パケットを取り込む処理よりも、図1右側に示したメッセージ解析処理の方が遅いため、パケットバッファを設けている。しかしながら、近年、ネットワークの高速化により、バースト的に流れるパケットの量が増加しているため、メッセージ解析処理を行うまでにパケットバッファが溢れてしまうという問題が発生する。
パケットバッファの容量はメッセージ分析装置のメモリ量で決まるため、バッファ容量を無限に確保する事はできない。従って、図1にも示しているように、パケットをパケットバッファに書き込む時には、空きバッファ容量とパケットサイズを比較して、空きバッファ容量が大きい場合は保存、パケットサイズが大きい場合は破棄するといった輻輳制御処理を行わなければならない。図1の例では、メッセージ3の3番目のパケットcが破棄されてしまっている。しかしながら、空きバッファ容量とパケットサイズで保存や破棄を判定すると、複数のパケットを含むメッセージの場合、図1に示すように、メッセージ組み立て処理でメッセージに含まれる全てのパケットが揃わなくなる。従って、バッファリングしたにもかかわらずメッセージ解析処理を行うことができないパケット(図1ではメッセージ3のパケットa及びb)を破棄することになるので、バッファ容量を無駄に使用したことになる。また、メッセージ組み立て処理も余分に行われたことになる。
なお、ATM(Asynchronous Transfer Mode)において、バッファ管理については以下のような従来技術が存在している。すなわち、パケットを複数に分割してなるセルを、宛先コネクション毎に個別にバッファに格納し、各バッファでは受信順にセルを格納するとともに、格納順にセルを送出する。各バッファでは、格納を完了したパケットと、格納途中のパケットを区別し、バッファが限界容量に達した時には、この格納途中のパケットに属する格納済みのセルを廃棄するとともに、バッファに格納すべき新たなパケットに属するセルが到着するまでの間、セルの格納を行わない。しかしながら、本従来技術は、処理で判別が必要となるEOP(End Of Packet)セルを、ヘッダのPTI(ペイロードタイプ識別子)によって判断しており、ATM技術に特化したものである。従って、ATMではないスイッチなどによってミラーリングでコピーされ且つサーバ間でやりとりされているパケットに対して、そのまま適用できるわけではない。
特開2001−223702号公報
以上述べたように、コンピュータ間でメッセージのやりとりを行って処理を進める分析対象システムの分析を、メッセージに含まれるパケットを取り込んで解析するような場合に、従来技術に示されたATM技術はそのまま適用できない。
従って、本技術の目的は、コンピュータ間でメッセージのやりとりを行って処理を進めるような分析対象システムの分析時に、効率的にパケットバッファを利用するための技術を提供することである。
本バッファ管理方法は、解析に用いるパケットの記憶制御を実行させるバッファ管理方法であって、(A)コンピュータ間で送受信されるメッセージに係るパケットを取得するステップと、(B)取得したパケットを記憶部に格納するステップと、(C)取得した複数のパケットのうち、コネクション及び送信方向が一致し且つ取得間隔が所定の時間幅より短い関係を有するパケット群の少なくとも一部のパケットについて記憶部における記憶領域が不足する場合に、パケット群のうち記憶部に記憶されたパケットを破棄する破棄ステップとを含む。
効率的なパケットバッファの利用が可能となる。
図1は、従来技術の問題を説明するための図である。 図2は、本技術の実施の形態におけるシステム概要を示す図である。 図3は、パケット間隔を説明するための図である。 図4は、パケット間隔を説明するための図である。 図5は、メッセージシーケンス例を示す図である。 図6は、パケットのフォーマットを示す図である。 図7は、IPヘッダのフォーマットを示す図である。 図8は、TCPヘッダのフォーマットを示す図である。 図9は、メッセージ分析装置の機能ブロック図である。 図10は、メッセージ分析装置の動作の概要を説明するための図である。 図11は、メッセージ分析装置のメインの処理フローを示す図である。 図12は、コネクション情報テーブルの一例を示す図である。 図13は、メッセージ分析装置のメインの処理フローを示す図である。 図14は、開始及び終了時処理を示す図である。 図15は、パケット処理の処理フローを示す図である。 図16は、受信時刻データテーブルの一例を示す図である。 図17は、削除フラグテーブルの一例を示す図である。 図18は、パケットバッファを説明するための模式図である。 図19は、パケット処理の処理フローを示す図である。 図20は、コンピュータの機能ブロック図である。 図21は、メッセージ分析装置の機能ブロック図である。
図2に本実施の形態に係るシステム概要を示す。例えば、図2に示すように複数のサーバがスイッチSWに接続されており、サーバ間でメッセージのやりとりを行って処理を進めるシステムが分析対象システムである。このような分析対象システムのスイッチSWは、本実施の形態における主要な処理を実施するメッセージ分析装置100に接続されており、スイッチSWを通過する全てのパケットをミラーリングしてメッセージ分析装置100に送信する。メッセージ分析装置100は、スイッチSWから送られてくるパケットを受信し、以下で述べるような処理を実施する。
なお、サーバにおいて実行されている、TCP(Transmission Control Protocol)上のアプリケーションが1パケット(1514バイト。TCPセグメント又はセグメントとも呼ぶ。)に収まらないメッセージの送信を指示すると、サーバのカーネルがセグメント分割し、複数パケットでメッセージを送信する。図3に示すように、パケットの送信間隔には、同一メッセージ内と異なるメッセージ間の2種類が存在し、同一メッセージ内のパケット送信間隔の方が短いという性質がある。これは、例えばサーバアプリケーションがカーネルに対して、メッセージ単位に送信要求を行うため、カーネル内で分割された同一メッセージ内のパケットの送信間隔は短くなるためである。一方、サーバアプリケーションで分割された2つの異なるメッセージ送信要求は、別々にシーケンシャルにカーネルで処理されるので、パケット送信間隔が長くなる。
本実施の形態では、このような特性を利用してパケットの分類を行うが、図2に示したようなシステムにおいてスイッチSWがミラーリングによってパケットをコピーしてメッセージ分析装置100に送信する場合にも、コネクション毎且つ送信方向毎にパケットを分類すれば、上で述べたパケットの送信間隔は維持される。すなわち、図4に示すように、サーバAからサーバBへのパケット列と、サーバBからサーバCへのパケット列とが同時期にスイッチSWを通過する場合、模式的に図示されているように、スイッチSWから2つのパケット列がシリアルにマージされた形でメッセージ分析装置100に出力される。しかしながら、パケットのヘッダなどによってサーバAからサーバBへのパケット列とサーバBからサーバCへのパケット列とを分離すれば、パケットの送信順番は変化することなく、さらにタイミングについてもあまり変化することはない。すなわち、同一メッセージ内におけるパケットの送信間隔は、異なるメッセージ間におけるパケット送信間隔より短いという特徴は維持される。
また、図5に示すように、サーバAからサーバBに接続する場合には、TCPレベルにおいて、SYNパケットをサーバAからサーバBに送信し、これに対してサーバBからサーバAにSYN+ACKパケットを送信する。さらに、サーバAからサーバBへACKパケットを送信する。これによってコネクションが確立したことになって、通信が双方向で行われる。その後、例えばサーバAからサーバBへFINパケットを送信し、それに対してサーバBからサーバAへACKパケットが返信される。さらに、サーバBからサーバAへFINパケットが送信され、サーバAからサーバBへACKパケットが送信されると、コネクションの切断が行われたことになる。本実施の形態では、コネクションの確立を検出して、コネクション確立状態においてはパケットの送信方向毎にパケットの受信間隔によってメッセージの異同を判断する。また、コネクションの切断も検出して、管理データを更新する。
さらに、図6に示すように、IPパケットには、IPヘッダ、TCPヘッダ及びTCPデータが含まれており、このTCPデータの部分にアプリケーションのメッセージヘッダ及びメッセージデータが含まれる。メッセージヘッダには、メッセージ長が含まれる。なお、IPパケットは、例えばイーサフレームの中に含まれることになる。
また、IPヘッダの模式図を図7に示す。IPヘッダは周知であるから詳しく述べないが、送信元IPアドレスと宛先IPアドレスを含むようになっている。同様に、図8にTCPヘッダの模式図を示す。TCPヘッダには、TCPヘッダについても周知であるから詳しく述べないが、コネクションを識別するための送信元ポート番号及び宛先ポート番号を含むようになっている。なお、フラグにおいてSYNパケット、FINパケット、ACKパケットであるか否かなどが指定されている。なお、TCPパケットのTCPデータのサイズ(データ長)は、(IPパケットに含まれるパケット長−IPヘッダ長−TCPヘッダ長)にて算出可能である。
次に、メッセージ分析装置100の機能ブロック図を図9に示す。メッセージ分析装置100は、スイッチSWに接続されるNICなどの通信ユニット110と、通信ユニット110を介してスイッチSWから受信したパケットに対して受信時刻等の管理データを付与するなどの処理を実施するパケット受信処理部120と、パケットを格納するためのパケットバッファ140と、受信したパケットをパケットバッファ140に書き込むための処理などを実施するメッセージ処理部130と、パケットバッファ140に蓄積されているパケットに対して解析処理等を実施するメッセージ解析処理部150とを有する。
通信ユニット110は、プロミスキャスモードで、全てのパケットをパケット受信処理部120に対してオペレーティングシステム(OS)を介して出力する。
メッセージ処理部130は、前処理部131と、メッセージ及びバッファ状況判断処理部132と、バッファ書込処理部133と、バッファ削除処理部134と、管理データ格納部135とを有する。各処理部は、管理データ格納部135にデータを書き込んだり、管理データ格納部135からデータを読み出したりしつつ以下で述べるような処理を実施する。
パケットバッファ140は、パケットのデータを保持するために確保されたメモリの領域であり、本実施の形態ではパケットのデータをキュー形式で保持するようになっている。
メッセージ解析処理部150は、図1で示したパケット読み出し処理、メッセージ組み立て処理及びメッセージ解析処理を実施する。これらの処理については従来と同じであるから詳しくは述べない。
図10を用いて本実施の形態に係るメッセージ分析装置100の動作の概要を説明する。メッセージ分析装置100の通信ユニット110は、スイッチSWから送信されてきたパケットを受信してパケット受信処理部120に出力する。パケット受信処理部120は、通信ユニット110からパケットを受信すると受信時刻などのデータを添付してメッセージ処理部130の前処理部131に出力する。メッセージ処理部130の前処理部131は、パケットのデータを受け取ると、パケットのヘッダからコネクション及び送信方向を特定するための前処理を実施する。また、メッセージ及びバッファ状況判断処理部132は、同一コネクション及び同一送信方向についての直前パケットの受信時刻と今回受信したパケットの受信時刻との差からメッセージにおける先頭パケットであるか否かを判断すると共に、同一メッセージについてパケットバッファ140においてパケットの破棄を既に行ったか否かを判断するといったメッセージ及びバッファ状況判断処理を実施する。同一メッセージについてパケットの破棄を既に行っている場合には、このパケットについてバッファ書き込み処理を行わなくともよいので、このパケットについてはここで処理を終了する。
例えば、メッセージ3にパケットa乃至cが含まれる場合、先頭のパケットaについてバッファ溢れが発生してしまうと、後続のパケットb及びcについてはバッファ書き込み処理を行わず、受信パケットb及びcをそのまま破棄する。
さらに、同一メッセージについてパケットの破棄を行っていない場合には、バッファ書込処理部133は、今回のパケットについてバッファ書き込み処理を実施する。但し、バッファ書き込み処理でバッファ溢れが発生したことが分かると、バッファ削除処理部134は、今回のパケットと同一のメッセージに含まれる他のパケットのデータをパケットバッファ140から削除するバッファ削除処理を実施する。例えば、メッセージ3に含まれるパケットcをパケットバッファ140に書き込もうとした際にバッファ溢れが発生すると、同一のメッセージに含まれており且つ既にパケットバッファ140に格納されている先行パケットa及びbのデータを削除する。
このようにすれば、揃うことのないパケットについてのメッセージは無駄にパケットバッファ140のバッファ領域を消費することが無くなるので、パケットバッファ140の有効活用が図られる。また、メッセージ解析処理部150がメッセージ組み立て処理で、パケットの破棄を行う頻度が少なくなる。すなわち、メッセージ組み立て処理の処理効率が向上する。
次に、図11乃至図19を用いて、メッセージ分析装置100の処理内容について詳細に説明する。なお、既に通信ユニット110が受信したパケットは、パケット受信処理部120に出力され、パケット受信処理部120は、受信時刻のデータなどを付加した上で、メッセージ処理部130に当該パケットのデータが出力される、という前提の処理について、これ以上の説明は省略する。
まず、メッセージ処理部130の前処理部131は、パケット受信処理部120からパケットを受信したか判断する(ステップS1)。パケットを受信していない場合には、受信するまで待機する。一方、受信した場合には、前処理部131は、受信パケットからコネクション情報を抽出する(ステップS3)。コネクション情報は、送信元IPアドレス及び宛先IPアドレスと送信元ポート番号及び宛先ポート番号とを含む。そして、前処理部131は、抽出コネクション情報で、管理データ格納部135に格納されているコネクション情報テーブルを検索する(ステップS5)。コネクション情報テーブルは、例えば図12に示すようなテーブルである。
図12の例では、接続先IPアドレス(=宛先IPアドレス)と、接続先ポート番号(=宛先ポート番号)と、接続元IPアドレス(=送信元IPアドレス)と、接続元ポート番号(=送信元ポート番号)と、コネクション番号とが登録されるようになっている。なお、送信元と宛先が入れ替わっている場合にも同じコネクションであるが、ここでは両方テーブルに登録するのではなく、一方のみを登録することにする。コネクション番号は、以下で述べるデータの識別情報として用いられ、コネクション情報テーブルにコネクション情報を登録する際に発行される。
そして、ステップS5の結果として該当レコードが存在すれば(ステップS7:Yesルート)、前処理部131は、受信パケットが切断関連パケットであるか判断する(ステップS8)。切断関連パケットは、FINパケットを含む。切断関連パケットであれば、端子Aを介して図13のステップS15に移行する。一方、切断関連パケットでなければ、前処理部131は、メッセージ及びバッファ状況判断処理部132等に処理を依頼し、メッセージ及びバッファ状況判断処理部132等は、上りについてのパケット処理を実施する(ステップS9)。このパケット処理については後に詳しく述べる。但し、ステップS9では、パケットの送信方向が上りであることが特定されており、この方向を特定した上でパケット処理を実施する。その後端子Bを介して図13のステップS19に移行する。
一方、ステップS5の結果として該当レコードが存在しない場合には(ステップS7:Noルート)、前処理部131は、接続先と接続元のIPアドレス及びポート番号を入れ替えて、下りコネクション情報を生成し(ステップS11)、下りコネクション情報で、管理データ格納部135に格納されているコネクション情報テーブルを検索する(ステップS13)。処理は端子Cを介して図13の処理に移行する。
図13の処理の説明に移行して、ステップS13の結果として該当レコードが存在する場合には(ステップS14:Yesルート)、前処理部131は、受信パケットが切断関連パケットであるか判断する(ステップS16)。切断関連パケットであれば、ステップS15に移行する。一方、切断関連パケットでなければ、前処理部131は、メッセージ及びバッファ状況判断処理部132等に処理を依頼し、メッセージ及びバッファ状況判断処理部132等は、下りについてのパケット処理を実施する(ステップS17)。このパケット処理については後に詳しく述べる。但し、ステップS17では、パケットの送信方向が下りであることが特定されており、この方向を特定した上でパケット処理を実施する。その後ステップS19に移行する。
一方、ステップS13の結果として該当レコードが存在しない場合には(ステップS14:Noルート)、前処理部131は、開始及び終了時処理を実施する(ステップS15)。この開始及び終了時処理については後に詳しく述べる。処理はステップS19に移行する。
ステップS19では、処理が終了するか判断し(ステップS19)、処理終了でなければ端子Dを介して図11のステップS1に戻る。一方、処理終了であれば、処理を終了する。
次に、開始及び終了時処理について図14を用いて説明する。最初に、前処理部131は、受信パケットが第1の接続関連パケットであるか判断する(ステップS21)。本実施の形態では、第1の接続関連パケットは、SYN+ACKパケットである。第1の接続関連パケットであれば、前処理部131は、受信パケットのコネクション情報の接続先と接続元のIPアドレス及びポート番号を入れ替えて接続判断情報として、例えばメインメモリなどの記憶装置に格納する(ステップS23)。そして元の処理に戻る。
一方、第1の接続関連パケットではない場合には、前処理部131は、受信パケットが、接続判断情報と同じコネクション情報を含む第2の接続関連パケットであるか判断する(ステップS25)。第2の接続関連パケットは、図5で示した接続シーケンスにおいてSYN+ACKパケットの次に送信されるACKパケットである。従って、このようなACKパケットでは、SYN+ACKパケットとは接続先と接続元のIPアドレス及びポート番号が逆になっている。
受信パケットが、このような第2の接続関連パケットであれば、前処理部131は、受信パケットのコネクション情報を、管理データ格納部135におけるコネクション情報テーブル(図12)に登録する(ステップS27)。ここで、コネクション番号を発行して一緒に登録する。そして、元の処理に戻る。
なお、切断時の処理(ステップS41)は、ステップS25で上で述べたような第2の接続関連パケットではなく、切断関連パケット(ここではFINパケット)である場合に実行される。
すなわち、前処理部131は、受信パケットがステップS25で上で述べたような第2の接続関連パケットではないと判断した場合には、受信パケットが切断関連パケットであるか判断する(ステップS33)。受信パケットが切断関連パケットでもない場合には、そのまま元の処理に戻る。一方、受信パケットが切断関連パケットであれば、前処理部131は、管理データ格納部135に格納されているコネクション情報テーブル等において、該当レコードを削除する(ステップS41)。管理データ格納部135には、まだ説明していない受信時刻データテーブル及び削除フラグテーブルが格納されており、これらはコネクション番号で管理されている。従って、コネクション情報テーブルにおける該当レコードのコネクション番号で、受信時刻データテーブル及び削除フラグテーブルを検索して、該当レコードを削除する。
次に、図15乃至図19を用いてパケット処理(ステップS9及びS17)について説明する。パケット処理は、コネクション番号及びパケットの送信方向を特定した上で実施される。パケットの送信方向は、管理データ格納部135において参照すべきデータ及び記録すべきデータを区別するために用いられるが、実質的な処理内容が異なるわけではない。従って、以下では、注意すべき部分を除き、特に区別することなく説明する。
まず、メッセージ及びバッファ状況判断処理部132は、管理データ格納部135に格納されている受信時刻データテーブルから、今回のコネクション番号及び送信方向(上り又は下り)について登録されている、直前のパケットの受信時刻を読み出し、今回のパケットの受信時刻との差(すなわちパケット間隔)を算出する(ステップS51)。
受信時刻データテーブルには、例えば図16に示すようなデータが格納されている。図16の例では、コネクション番号と、上りパケット時刻(上りのパケット受信時刻)と、上りメッセージ番号と、下りパケット時刻(下りのパケット受信時刻)と、下りメッセージ番号とが登録されるようになっている。すなわち、コネクション毎且つ送信方向毎に、直前パケットの受信時刻が登録されるようになっている。また、メッセージを区別するためにメッセージ番号も登録されるようになっている。従って、ステップS51では、今回のコネクション番号及び送信方向に該当する時刻を読み出す。なお、今回のコネクション番号及び送信方向について初めてのパケットである場合には、該当レコードが登録されていないので、このような場合には十分に小さい値を直前パケットの受信時刻とする。
そして、メッセージ及びバッファ状況判断処理部132は、今回のパケットの受信時刻で、受信時刻データテーブルの該当部分(今回のコネクション番号及び送信方向に対応する受信時刻)を更新する(ステップS53)。次回パケットを受信した際に参照するためである。なお、初めてのパケットの場合には、該当レコードが存在しないので、新規に登録する。
その後、メッセージ及びバッファ状況判断処理部132は、ステップS51で算出したパケット間隔が所定の閾値以上であるか否かを判断することによって、今回受信したパケットがメッセージの先頭パケットであるか否かを判断する(ステップS55)。所定の閾値は、例えば予め測定した結果に基づき管理データ格納部135に格納しておき、ステップS55で読み出して用いる。
パケット間隔が所定の閾値以上である場合には、1つのメッセージの先頭パケットであると判定し、メッセージ及びバッファ状況判断処理部132は、メッセージ番号を発行し、受信時刻データテーブルの該当部分(今回のコネクション番号及び送信方向に対応するメッセージ番号)に登録する(ステップS57)。さらに、メッセージ及びバッファ状況判断処理部132は、管理データ格納部135に格納されている削除フラグテーブルにおいて、今回のコネクション番号及び送信方向についての削除フラグをOFFにセットする(ステップS59)。そしてステップS63に移行する。
削除フラグテーブルには、例えば図17に示すようなデータが格納されている。図17の例では、コネクション番号と、送信方向と、削除フラグ(ここでは「0」がOFFを表し、「1」が「ON」を表す。)とが登録されるようになっている。削除フラグがONであれば、既に同一メッセージのパケットの破棄が行われており、同一メッセージに含まれるパケットであればバッファ書き込みは不要である。一方、削除フラグがOFFであれば、同一メッセージのパケットについては破棄が行われておらず、バッファ書き込み処理を行うことになる。
ステップS59では、今回のコネクション番号及び送信方向についての削除フラグを更新する。但し、今回のコネクション番号及び送信方向について初めてのパケットである場合には、該当レコードが存在しないので、今回のコネクション番号及び送信方向と削除フラグ「OFF」とを含むレコードを新たに登録する。
一方、パケット間隔が所定の閾値未満である場合には、1つのメッセージの2番目以降のパケットであると判定し、メッセージ及びバッファ状況判断処理部132は、削除フラグテーブルにおいて今回のコネクション番号及び送信方向についての削除フラグがONになっているか判断する(ステップS61)。削除フラグがONであれば、今回受信したパケットについてはバッファ書き込み処理を実施せずに、元の処理に戻る。すなわち、メッセージ解析処理の対象から除外することによって、処理の効率化を図る。これに対して、削除フラグがOFFになっている場合には、ステップS63に移行する。
ステップS59の後又はステップS61で削除フラグがOFFである場合には、メッセージ及びバッファ状況判断処理部132は、バッファ書込処理部133に対して、今回受信したパケットのバッファ書き込み処理を依頼する。
バッファ書込処理部133は、メッセージ及びバッファ状況判断処理部132からの依頼に応じて、パケットバッファ140の空きバッファサイズと今回受信したパケットのサイズとを比較する(ステップS63)。
空きバッファサイズの方が今回受信したパケットのサイズよりも大きい場合には(ステップS65:Yesルート)空きがあるので、バッファ書込処理部133は、パケットバッファ140において今回受信したパケットのデータのためのバッファ領域を確保する(ステップS67)。そして、バッファ書込処理部133は、今回受信したパケットのデータ(受信時刻などを含む)及び今回のパケットが属するメッセージのメッセージ番号(ステップS57で発行されたメッセージ番号又は受信時刻データテーブルにおいて今回のコネクション番号及び送信方向に対応付けて登録されているメッセージ番号)を、確保したバッファ領域に書き込む(ステップS69)。また、バッファ書込処理部133は、キューの最後尾のバッファ領域に、今回確保したバッファ領域のアドレスを登録することでキューイングを行う(ステップS71)。そして元の処理に戻る。
図18を用いてパケットバッファ140におけるキューについて説明する。パケットバッファ140では、受信した順番にメッセージ番号及びパケットのデータをキューイングするようになっている。図18の例では、メッセージ番号1及びパケットデータ(例えば1番目のパケットのデータ)、メッセージ番号1及びパケットデータ(例えば2番目のパケットのデータ)、メッセージ番号1及びパケットデータ(例えば3番目のパケットのデータ)、メッセージ番号2及びパケットデータ(例えば1番目のパケットのデータ)、メッセージ番号3及びパケットデータ(例えば1番目のパケットのデータ)及びメッセージ番号3及びパケットデータ(例えば2番目のパケットのデータ)がポインタでつながれた形で格納されている。例えば、メッセージ番号1のパケット群と、メッセージ番号2のパケットと、メッセージ番号3のパケット群とは、それぞれ異なるコネクション又は送信方向であってもよい。このように、コネクション毎や送信方向毎にパケットバッファ140を分割することがないので、パケットバッファ140を効率的に利用することができる。なお、ステップS69及びS71で新たにパケットのデータを格納する場合には、空きバッファプールに登録されている領域142に、メッセージ番号及びパケットのデータを書き込み、メッセージ番号3及び2番目のパケットデータの領域141から今回の領域142へのポインタを設定する。
なお、ステップS65において空きなしと判断された場合には(ステップS65:Noルート)、処理は端子Eを介して図19の処理に移行する。この際、バッファ書込処理部133は、バッファ削除処理部134に処理の依頼を行う。
図19の処理の説明に移行して、バッファ削除処理部134は、受信パケットがメッセージの先頭パケットであるか確認する(ステップS73)。ステップS55における判断結果をメインメモリなどの記憶装置に保持しておき、ステップS73で確認する。先頭パケットである場合には、バッファ削除処理部134は、管理データ格納部135に格納されている削除フラグテーブルにおいて、今回のコネクション番号及び送信方向についての削除フラグをONにセットする(ステップS79)。今回受信したパケットについては書き込みを行うことなく破棄した上、同一メッセージに属する後続パケットについてもパケットバッファ140への書き込みを行わせないようにするためである。
一方、受信パケットが先頭パケットではない場合、バッファ削除処理部134は、今回のメッセージ番号でキューを検索して、該当するパケットデータを格納しているバッファ領域を検出する(ステップS75)。さらに、バッファ削除処理部134は、検出されたバッファ領域を空き領域として空きバッファプールに登録すると共に、キューにおけるポインタの変更を行う(ステップS77)。図18では、今回のメッセージ番号が「2」である例を示しており、メッセージ番号「2」を格納しているバッファ領域を検出し、当該バッファ領域を空きバッファプールに登録する。さらに、当該バッファ領域を指しているポインタのアドレスを、当該バッファ領域が指しているポインタのアドレスに変更する。図18の例では、メッセージ番号1及び3番目のパケットデータを格納する領域が、メッセージ番号3及び1番目のパケットデータを格納する領域を指すように変更する。複数のバッファ領域が検出された場合でも同様に処理する。さらに、最後尾の領域を開放する際には、当該バッファ領域を指しているポインタのアドレスを削除する。
その後処理はステップS79に移行して、上で述べたような処理を実施する。
以上のような処理を実施することで、パケットバッファ140の領域を有効活用でき、さらにメッセージ解析処理の処理効率も向上される。また、本実施の形態によれば、1つのメッセージに含まれる先頭パケットと後続パケットとを、簡単な処理で特定のプロトコルに依存することなく区別することができるようになる。
以上本技術の実施の形態について説明したが、本技術はこれに限定されるものではない。例えば、図2に示したメッセージ分析装置100の機能ブロックは一例であって、必ずしも実際のプログラムモジュール構成と一致するわけではない。
また、処理フローについても、処理結果が変わらない限り、処理順番を入れ替えたり並列処理しても良い。例えば、図15及び図19に示したパケット処理において、ステップS59で削除フラグをOFFにセットしているが、例えばステップS67以降において削除フラグをOFFにするような処理でも処理結果は変わらない。また、ステップS79をステップS73よりも前に移動させても処理結果は変わらない。
また、パケットバッファ140におけるキューの構成についても変更することが可能である。例えば、コネクション毎又はコネクション毎且つ送信方向毎にキューを設けるようにしてもよい。但し、空きバッファプールは1つだけにして、バッファ領域の有効活用を図ることが好ましい。
なお、上で述べたメッセージ分析装置100は、コンピュータ装置であって、図20に示すように、メモリ2501とCPU2503(プロセッサ、処理部若しくは処理装置とも呼ぶ)とハードディスク・ドライブ(HDD)2505と表示装置2509に接続される表示制御部2507とリムーバブル・ディスク2511用のドライブ装置2513と入力装置2515とネットワークに接続するための通信制御部2517(通信ユニット110に相当)とがバス2519で接続されている。オペレーティング・システム(OS:Operating System)及び本実施例における処理を実施するためのアプリケーション・プログラムは、HDD2505に格納されており、CPU2503により実行される際にはHDD2505からメモリ2501に読み出される。必要に応じてCPU2503は、表示制御部2507、通信制御部2517、ドライブ装置2513を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ2501に格納され、必要があればHDD2505に格納される。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク2511に格納されて頒布され、ドライブ装置2513からHDD2505にインストールされる。インターネットなどのネットワーク及び通信制御部2517を経由して、HDD2505にインストールされる場合もある。このようなコンピュータ装置は、上で述べたCPU2503、メモリ2501などのハードウエアとOS及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
以上述べた本実施の形態をまとめると、以下のようになる。
本実施の形態の第1の態様に係るバッファ管理方法は、(A)解析対象コンピュータ間で送受信されるメッセージに係るパケットを取得し、当該パケットのヘッダ情報からコネクション及び送信方向を特定するステップと、(B)取得されたパケットの受信時刻と、特定されたコネクション及び送信方向について取得された直前のパケットの受信時刻(取得時刻とも呼ぶ)との差が所定の閾値以上であるか判断する判断ステップと、(C)取得されたパケットの受信時刻と直前のパケットの受信時刻との差が所定の閾値未満であって且つ取得されたパケットを格納するためのバッファ領域が不足する場合には、取得されたパケットより前に受信されてバッファに格納されている同一メッセージに係るパケットのデータを破棄する破棄ステップとを含む。
これによってバッファを効率的に利用することができるようになる。なお、判断ステップのような処理によって1つのメッセージの先頭パケットであるか2番目以降のパケットであるか判別することができ、パケット自体に先頭パケット又は最終パケットであるということを表す情報が含まれないような場合においても対処可能である。また、ネットワーク内に設置されている中継装置(スイッチ等)自身のバッファであれば入力ポートと出力ポートとの関係でコネクション及び送信方向を特定できるが、本実施の形態のように中継装置が複数のポートで受信した全てのパケットがシリアルに送信されてくるような状況においてはそのようなデータは存在せず、(A)で示したステップのように分類すれば正しく処理できる。
なお、(C)上で述べた破棄ステップが実行された場合、又は取得されたパケットの受信時刻と直前のパケットの受信時刻との差が所定の閾値以上であって且つ取得されたパケットを格納するためのバッファ領域が不足する場合、特定されたコネクション及び送信方向に対応付けて同一メッセージについてパケットの破棄が行われたことを表す削除フラグを管理データ格納部に格納するステップと、(D)同一のコネクション及び送信方向について次に受信したパケットについて判断ステップにおいて受信時刻の差が所定の閾値未満と判断された場合に、管理データ格納部に、同一のコネクション及び送信方向に対応付けて格納されている削除フラグが、同一メッセージについてパケットの破棄が行われたことを表しているか否かを判断するステップと、(E)削除フラグが同一メッセージについてパケットの破棄が行われたことを表している場合には、次に受信したパケットを破棄するステップとをさらに含むようにしても良い。
このような削除フラグを導入することによって、同一のメッセージにおける後続のパケットの処理が簡略化される。
また、(F)取得されたパケットの受信時刻と直前のパケットの受信時刻との差が所定の閾値以上であって且つ取得されたパケットを格納するためのバッファ領域が存在する場合には、新たに発行されたメッセージ番号と共にパケットのデータをバッファ内のキューの最後尾に追加するステップと、(G)取得されたパケットの受信時刻と直前のパケットの受信時刻との差が所定の閾値未満であって且つ取得されたパケットを格納するためのバッファ領域が存在する場合には、特定されたコネクション及び送信方向について直前に発行されたメッセージ番号と共にパケットのデータをバッファ内のキューの最後尾に追加するステップとをさらに含むようにしても良い。その際、上で述べた破棄ステップにおいて、キューを、特定されたコネクション及び送信方向について直前に発行されたメッセージ番号で検索して同一メッセージに係るパケットのデータを特定し、当該同一メッセージに係るパケットのデータの破棄後に当該データのためのバッファ領域を空きバッファプールに返却するようにしてもよい。
キュー形式でパケットデータを管理することで、管理が容易になると共に、メッセージ番号を付加することで、破棄する処理を容易に行うことができるようになる。
さらに、バッファ内のキューが、コネクション及び送信方向の区別無く設けられる場合もある。このように受信した順番に従ってキューの最後尾にデータを付加するような形態を導入することによって、コネクション毎やコネクション毎且つ送信方向毎などでバッファ領域を分割する場合に比して、バッファ領域の有効活用が図られる。
また、本実施の形態に係るバッファ管理装置(図21:1000)は、解析に用いるパケットの記憶制御を実行するバッファ管理装置であって、(A)コンピュータ間で送受信されるメッセージに係るパケットを取得し、取得したパケットを記憶部(図21:1300)に格納する前処理部(図21:1100)と、(B)取得した複数のパケットのうち、コネクション及び送信方向が一致し且つ取得間隔が所定の時間幅より短い関係を有するパケット群の少なくとも一部のパケットについて記憶部における記憶領域が不足する場合に、パケット群のうち記憶部に記憶されたパケットを破棄するバッファ削除処理部(図21:1200)とを有する。
なお、上で述べたような処理をコンピュータに実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、CD−ROM、光磁気ディスク、半導体メモリ(例えばROM)、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、RAM等の記憶装置に一時保管される。
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
(付記1)
解析に用いるパケットの記憶制御を実行させるプログラムであって、
コンピュータ間で送受信されるメッセージに係るパケットを取得するステップと、
取得したパケットを記憶部に格納するステップと、
取得した複数のパケットのうち、コネクション及び送信方向が一致し且つ取得間隔が所定の時間幅より短い関係を有するパケット群の少なくとも一部のパケットについて前記記憶部における記憶領域が不足する場合に、前記パケット群のうち前記記憶部に記憶されたパケットを破棄する破棄ステップと、
を、解析用コンピュータに実行させるプログラム。
(付記2)
前記破棄ステップが実行された場合、前記コネクション及び送信方向に対応付けて、同一メッセージについてパケットの破棄が行われたことを表す削除情報を管理データ格納部に格納するステップと、
同一のコネクション及び送信方向について次に受信したパケットが前記パケット群に属する場合、前記管理データ格納部に前記同一のコネクション及び送信方向に対応付けて格納されている削除情報が、同一メッセージについてパケットの破棄が行われたことを表しているか否かを判断するステップと、
前記削除情報が前記同一メッセージについてパケットの破棄が行われたことを表している場合には、前記次に受信したパケットを破棄するステップと、
をさらに前記解析用コンピュータに実行させるための付記1記載のプログラム。
(付記3)
取得したパケットの取得時刻と直前のパケットの取得時刻との差が所定の閾値以上であって且つ取得したパケットを格納するためのバッファ領域が存在する場合には、新たに発行されたメッセージ番号と共に前記パケットのデータを前記バッファ内のキューの最後尾に追加するステップと、
取得したパケットの取得時刻と直前のパケットの受信時刻との差が所定の閾値未満であって且つ取得したパケットを格納するためのバッファ領域が存在する場合には、前記コネクション及び送信方向について直前に発行されたメッセージ番号と共に前記パケットのデータを前記バッファ内のキューの最後尾に追加するステップと、
をさらに前記分析用コンピュータに実行させ、
前記破棄ステップにおいて、前記キューを前記直前に発行されたメッセージ番号で検索して前記同一メッセージに係るパケットのデータを特定し、当該同一メッセージに係るパケットのデータの破棄後に当該データのためのバッファ領域を空きバッファプールに返却する
付記1又は2記載のプログラム。
(付記4)
前記バッファ内のキューが、前記コネクション及び送信方向の区別無く設けられる
付記3記載のバッファ管理プログラム。
(付記5)
解析に用いるパケットの記憶制御を実行させるバッファ管理方法であって、
コンピュータ間で送受信されるメッセージに係るパケットを取得するステップと、
取得したパケットを記憶部に格納するステップと、
取得した複数のパケットのうち、コネクション及び送信方向が一致し且つ取得間隔が所定の時間幅より短い関係を有するパケット群の少なくとも一部のパケットについて前記記憶部における記憶領域が不足する場合に、前記パケット群のうち前記記憶部に記憶されたパケットを破棄する破棄ステップと、
を含み、解析用コンピュータにより実行されるバッファ管理方法。
(付記6)
解析に用いるパケットの記憶制御を実行するバッファ管理装置であって、
コンピュータ間で送受信されるメッセージに係るパケットを取得し、取得したパケットを記憶部に格納する前処理部と、
取得した複数のパケットのうち、コネクション及び送信方向が一致し且つ取得間隔が所定の時間幅より短い関係を有するパケット群の少なくとも一部のパケットについて前記記憶部における記憶領域が不足する場合に、前記パケット群のうち前記記憶部に記憶されたパケットを破棄するバッファ削除処理部と、
を有するバッファ管理装置。
100 メッセージ分析装置 110 通信ユニット
120 パケット受信処理部 130 メッセージ処理部
140 パケットバッファ 150 メッセージ解析処理部
131 前処理部 132 メッセージ及びバッファ状況判断処理部
133 バッファ書込処理部 134 バッファ削除処理部
135 管理データ格納部

Claims (5)

  1. 解析に用いるパケットの記憶制御を実行させるプログラムであって、
    コンピュータ間で送受信されるメッセージに係るパケットを取得するステップと、
    取得したパケットを記憶部に格納するステップと、
    取得したパケットのコネクション及び送信方向が、既に取得しているパケットのコネクション及び送信方向と一致するか否かを判定し、コネクション及び送信方向が一致し且つ取得間隔が所定の時間幅より短い関係を有するパケット群の少なくとも一部のパケットについて前記記憶部における記憶領域が不足する場合に、前記パケット群のうち前記記憶部に記憶されたパケットを破棄する破棄ステップと、
    を、解析用コンピュータに実行させるプログラム。
  2. 前記破棄ステップが実行された場合、前記コネクション及び送信方向に対応付けて、同一メッセージについてパケットの破棄が行われたことを表す削除情報を管理データ格納部に格納するステップと、
    同一のコネクション及び送信方向について次に受信したパケットが前記パケット群に属する場合、前記管理データ格納部に前記同一のコネクション及び送信方向に対応付けて格納されている削除情報が、同一メッセージについてパケットの破棄が行われたことを表しているか否かを判断するステップと、
    前記削除情報が前記同一メッセージについてパケットの破棄が行われたことを表している場合には、前記次に受信したパケットを破棄するステップと、
    をさらに前記解析用コンピュータに実行させるための請求項1記載のプログラム。
  3. 取得したパケットの取得時刻と直前のパケットの取得時刻との差が所定の閾値以上であって且つ取得したパケットを格納するためのバッファ領域が存在する場合には、新たに発行されたメッセージ番号と共に前記パケットのデータを前記バッファ内のキューの最後尾に追加するステップと、
    取得したパケットの取得時刻と直前のパケットの受信時刻との差が所定の閾値未満であって且つ取得したパケットを格納するためのバッファ領域が存在する場合には、前記コネクション及び送信方向について直前に発行されたメッセージ番号と共に前記パケットのデータを前記バッファ内のキューの最後尾に追加するステップと、
    をさらに前記分析用コンピュータに実行させ、
    前記破棄ステップにおいて、前記キューを前記直前に発行されたメッセージ番号で検索して前記同一メッセージに係るパケットのデータを特定し、当該同一メッセージに係るパケットのデータの破棄後に当該データのためのバッファ領域を空きバッファプールに返却する
    請求項1又は2記載のプログラム。
  4. 解析に用いるパケットの記憶制御を実行させるバッファ管理方法であって、
    コンピュータ間で送受信されるメッセージに係るパケットを取得するステップと、
    取得したパケットを記憶部に格納するステップと、
    取得したパケットのコネクション及び送信方向が、既に取得しているパケットのコネクション及び送信方向と一致するか否かを判定し、コネクション及び送信方向が一致し且つ取得間隔が所定の時間幅より短い関係を有するパケット群の少なくとも一部のパケットについて前記記憶部における記憶領域が不足する場合に、前記パケット群のうち前記記憶部に記憶されたパケットを破棄する破棄ステップと、
    を含み、解析用コンピュータにより実行されるバッファ管理方法。
  5. 解析に用いるパケットの記憶制御を実行するバッファ管理装置であって、
    コンピュータ間で送受信されるメッセージに係るパケットを取得し、取得したパケットを記憶部に格納する前処理部と、
    取得したパケットのコネクション及び送信方向が、既に取得しているパケットのコネクション及び送信方向と一致するか否かを判定し、コネクション及び送信方向が一致し且つ取得間隔が所定の時間幅より短い関係を有するパケット群の少なくとも一部のパケットについて前記記憶部における記憶領域が不足する場合に、前記パケット群のうち前記記憶部に記憶されたパケットを破棄するバッファ削除処理部と、
    を有するバッファ管理装置。
JP2010045010A 2010-03-02 2010-03-02 バッファ管理プログラム及び方法、並びにメッセージ分析装置 Expired - Fee Related JP5630033B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010045010A JP5630033B2 (ja) 2010-03-02 2010-03-02 バッファ管理プログラム及び方法、並びにメッセージ分析装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010045010A JP5630033B2 (ja) 2010-03-02 2010-03-02 バッファ管理プログラム及び方法、並びにメッセージ分析装置

Publications (2)

Publication Number Publication Date
JP2011182211A JP2011182211A (ja) 2011-09-15
JP5630033B2 true JP5630033B2 (ja) 2014-11-26

Family

ID=44693252

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010045010A Expired - Fee Related JP5630033B2 (ja) 2010-03-02 2010-03-02 バッファ管理プログラム及び方法、並びにメッセージ分析装置

Country Status (1)

Country Link
JP (1) JP5630033B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013111343A1 (ja) 2012-01-27 2013-08-01 富士通株式会社 情報処理装置、情報処理システム、通信データ出力方法、及び通信データ出力プログラム
JP7000808B2 (ja) 2017-11-14 2022-01-19 富士通株式会社 情報処理装置、情報処理方法およびプログラム

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0349339A (ja) * 1989-07-17 1991-03-04 Nec Corp データ伝送方式
JPH03135248A (ja) * 1989-10-20 1991-06-10 Fujitsu Ltd パケット交換網での選択式パケット廃棄方式
JPH08195752A (ja) * 1995-01-17 1996-07-30 Toshiba Corp 非同期転送モード伝送装置
JP2008524965A (ja) * 2004-12-21 2008-07-10 ミスルトウ テクノロジーズ, インコーポレイテッド ネットワークインターフェイスおよびファイヤーウォールデバイス
US8325599B2 (en) * 2007-03-23 2012-12-04 Panasonic Corporation Communication system and communication method

Also Published As

Publication number Publication date
JP2011182211A (ja) 2011-09-15

Similar Documents

Publication Publication Date Title
US7742414B1 (en) Lightweight indexing for fast retrieval of data from a flow-level compressed packet trace
JP5768683B2 (ja) 受信データ処理方法、通信装置、及びプログラム
WO2019024623A1 (zh) 一种流量测量方法、设备及系统
US6804692B2 (en) Method and apparatus for reassembly of data blocks within a network processor
CN106921665B (zh) 一种报文处理方法及网络设备
US11502967B2 (en) Methods and apparatuses for packet scheduling for software-defined networking in edge computing environment
CN113783800B (zh) 数据包处理方法、装置、计算机设备及可读存储介质
CN108206787A (zh) 一种拥塞避免方法和装置
JP5039292B2 (ja) ネットワークアダプタ、通信システムおよび通信方法
JP5900352B2 (ja) パケット処理装置、パケット処理方法およびプログラム
JP5094482B2 (ja) 処理装置及びその処理方法
JP5630033B2 (ja) バッファ管理プログラム及び方法、並びにメッセージ分析装置
JP5957318B2 (ja) ネットワークシステム、情報中継装置、及びパケット配信方法
CN113364862B (zh) 一种拼包解码系统及方法
CN106294477B (zh) 一种数据处理方法和装置
CN113973091A (zh) 一种报文处理方法、网络设备以及相关设备
US20120163398A1 (en) Communication apparatus, relay apparatus, and network system
US9553795B2 (en) Port switching method, analysis device, and recording medium
CN115118678A (zh) 一种fc设备端的多分区网络通信系统及其通信方法
CN112565821B (zh) 数据处理方法、装置、安全网关及存储设备
JP2005321910A (ja) ログデータ管理システム、方法、及びプログラム
JP5974937B2 (ja) 品質指標処理システム
US10305754B2 (en) Apparatus and method to collect packets related to abnormal connection
JP5359357B2 (ja) パケット処理装置、該処理装置に用いられるパケット処理順序制御方法及びパケット処理順序制御プログラム
JP2008148181A (ja) 通信装置及び通信制御方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20130108

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130924

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20131022

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140507

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140702

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140909

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140922

R150 Certificate of patent or registration of utility model

Ref document number: 5630033

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees