JP4872952B2 - Ｔｃｐバッファコピー分散並列処理装置、方法及びプログラム - Google Patents

Description

本発明は、ＴＣＰバッファコピー分散並列処理装置、方法及びプログラムに関し、特に、マルチコア、マルチプロセッサ環境等の分散並列処理が可能な環境におけるＴＣＰバッファコピー分散並列処理装置、方法及びプログラムに関する。

特許文献１において、高データレートのステートフルプロトコル処理が記載されている。特許文献１に記載の技術は、ＴＣＰ等のステートフルなプロトコルにおいてメッセージを処理する方法である。本技術は、単一のフローに属するメッセージを異なる時間に複数のプロトコル処理コア間に分配して処理することによって高速にデータ処理を行う。

また、非特許文献１、２において、ＴＣＰデータの転送処理におけるボトルネック要因は、ＴＣＰのステートフルなプロトコル処理の部位ではなく、バッファコピー処理であるとの報告がなされている。

非特許文献１では、ＴＣＰ処理のバイト転送当りの処理量のコストについて記載されている（ｐ．２７、Ｔａｂｌｅ１）。ユーザー空間からシステム空間へのメモリコピーは２００マイクロ秒、ＴＣＰチェックサム処理は１８５マイクロ秒、ネットワークメモリコピーは３８６マイクロ秒となっている。このうち、ＴＣＰチェックサム処理及びネットワークメモリコピーは、ネットワークインタフェースカードによってハードウェアにオフロード処理されるのが一般的であるため、ボトルネックの要因から除外することができる。しかし、ユーザー空間とシステム空間の間のメモリコピーは、未だに大きなボトルネックとして残されている。

一方、非特許文献２においては、プロファイラによって、Ｌｉｎｕｘカーネルの処理の負荷が計測されている。ソケットからの６４ＫＢｙｔｅの送信処理要求において、バッファコピー及びチェックサムの処理割合は３４％であり、ソケットからの６４ＫＢｙｔｅの受信処理要求において、バッファコピー及びチェックサムの処理割合は４１％となっている。すなわち、プロトコル処理の割合と比較して、バッファコピー処理の割合が高くなっている。

特表２００５−５３５２２６号公報 Ｄ．Ｃｌａｒｋ、Ｖ．Ｊａｃｏｂｓｏｎ、Ｊ．Ｒｏｍｋｅｙ、ａｎｄ Ｈ．Ｓａｌｗｅｎ． Ａｎ Ａｎａｌｙｓｉｓ ｏｆ ＴＣＰ ｐｒｏｃｅｓｓｉｎｇ ｏｖｅｒｈｅａｄ． ＩＥＥＥ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ、 Ｊｕｎｅ １９８９． Ａ．Ｆｏｏｎｇ ｅｔ ａｌ．、 "ＴＣＰ Ｐｅｒｆｏｒｍａｎｃｅ Ｒｅ−ｖｉｓｉｔｅｄ"、 ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｉｏｎａｌ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｐｅｒｆｏｒｍａｎｃｅ Ａｎａｌｙｓｉｓ ｏｆ Ｓｏｆｔｗａｒｅ ａｎｄ Ｓｙｓｔｅｍｓ、 Ｍａｒｃｈ ２００３． Ｊｏｎ Ｐｏｓｔｅｌ、"Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ"、 ＲＦＣ７９３ ｈｔｔｐ：／／ｗｗｗ．ｆａｑｓ．ｏｒｇ／ｒｆｃｓ／ｒｆｃ７９３．ｈｔｍｌ

以下の分析は、本発明者によってなされたものである。特許文献１に記載の技術は、ステートフルなプロトコル処理のパケットプロセッシングのみの高速化に特化したものである。すなわち、特許文献１に記載の技術は、プロトコル処理後のパケットデータをアプリケーションストリームの形に再構築し、再構築したデータをアプリケーションバッファにコピーする場合を想定していない。

上記の非特許文献１、２の報告によると、プロトコル処理自体を特許文献１に記載の従来技術によって高速化したとしても、ＴＣＰ受信パケットを受信し、再構築したデータをアプリケーションバッファにコピーするような系においては、アプリケーションバッファへのバッファコピー処理を高速化しない限り、システム全体としてのパフォーマンスを向上させることができない。したがって、プロトコル処理後のパケットデータをアプリケーションバッファにバッファコピーする処理の高速化が必要となる。このとき、以下に掲げる問題点を指摘することができる。

第１の問題点は、ＴＣＰの受信プロトコル処理後、再構築したＴＣＰデータをアプリケーションバッファにコピーするような系では、ＴＣＰプロトコル処理のみをマルチコアで高速化してもシステムレベルでは性能が向上しない点である。その理由は、ＴＣＰ受信処理のうち一番のボトルネック要因になる処理はＴＣＰプロトコル処理ではなく、受信パケットのアプリケーションストリームへのバッファコピー処理だからである。

第２の問題点は、次の通りである。すなわち、従来のＴＣＰ処理では、到着順が対向ホストの送信順とは異なるアウトオブオーダーデータは、再構築可能となるまで受信パケットバッファに保留される。その後、再構築可能になったタイミングでバッファコピーを実施する際、再構築可能となった瞬間にバッファコピー処理が過負荷となり、システムの性能が低下する点である。その理由は、アウトオブオーダーデータの間を埋めるインオーダーデータの到着によって、アウトオブオーダーデータが再構築可能となったとき、すなわち、パケット到着のタイムスロットにおいて、アウトオブオーダーデータのコピー処理に加えて、データの間を埋めるインオーダーデータのバッファコピー処理も実施されるからである。

第３の問題点は、バッファコピー処理を複数ブロックに分散することにより高速化したとしても、アプリケーションストリームが揃った判定を正しく行うことが困難であるという点である。その理由は、例えば、バッファコピーが完了した値を積算してアプリケーションストリームが揃ったことを判定するだけでは、アウトオブオーダーデータの重なりが発生した場合には正しくバッファストリームが揃ったことを判定することができないからである。

第４の問題点は、バッファコピー処理を複数ブロックに分散して高速化した場合、アプリケーションストリームの最後に相当するバッファコピー処理が完了したとしても、アプリケーションストリームが揃ったことを判定することができない点である。その理由は、特定のＴＣＰバッファコピー部の処理が過負荷となって処理時間が長くなることもあるため、必ずしもバッファコピーを要求した順にバッファコピー完了通知が送られてくるとは限らないからである。

そこで、ＴＣＰプロトコル処理後のパケットデータをアプリケーションストリームにバッファコピーする処理を高速化することが課題となる。

また、ＴＣＰプロトコル処理後のアウトオブオーダーデータが再構築可能となるのを待たずにバッファコピーをすることで、バッファコピー要求が過負荷にならないように均一化し、トータルの処理時間を削減することが課題となる。

さらに、ＴＣＰプロトコル処理後のバッファコピー処理を分散並列処理した場合に、受信アウトオブオーダーデータに重なりが発生したとしてもアプリケーションバッファの全ての領域に対してバッファコピー要求が発行されたことを検知可能とすることが課題となる。

また、ＴＣＰプロトコル処理後のバッファコピー処理を分散並列処理した場合において、動的に振り分け先を決定したときでも、全ての振り分け先のブロックのバッファコピー処理が完了したことを検知できるようにすることが課題となる。

本発明の第１の視点に係るＴＣＰバッファコピー分散並列処理装置は、
ＴＣＰ受信処理部と、
１又は２以上のＴＣＰバッファコピー部と、
ソケット処理部と、
受信パケットバッファと、
アプリケーションバッファと、を備えるＴＣＰバッファコピー分散並列処理装置であって、
前記受信パケットバッファ及びアプリケーションバッファが、前記ＴＣＰ受信処理部、ＴＣＰバッファコピー部及びソケット処理部からアクセス可能な記憶領域として構成され、
前記ＴＣＰ受信処理部が、パケットの受信処理とＴＣＰプロトコル処理とを実施し、受信パケットが対向ホストによって送信された順序と同一の順序で到着した（インオーダー、Ｉｎ−Ｏｒｄｅｒ）と判定した場合には、該受信パケットを前記受信パケットバッファに設けたインオーダーキューに格納し、該受信パケットのＴＣＰシーケンス番号に基づいて前記アプリケーションバッファにおけるコピー先の領域を決定し、該受信パケットを前記受信パケットバッファから前記アプリケーションバッファにコピーするバッファコピー要求を生成し、前記ＴＣＰバッファコピー部のいずれかを選択して該バッファコピー要求を通知することによって受信パケットのバッファコピーを分散並列処理させるように構成され、受信パケットが対向ホストによって送信された順序と異なる順序で到着した（アウトオブオーダー、Ｏｕｔ−ｏｆ−Ｏｒｄｅｒ）と判定した場合には、該受信パケットを前記受信パケットバッファに設けたアウトオブオーダーキューに格納するように構成されたことを特徴とする。

第１の展開形態のＴＣＰバッファコピー分散並列処理装置は、
前記ＴＣＰ受信処理部が、アウトオブオーダーと判定した受信パケットの前記アプリケーションバッファにおけるコピー先が前記アプリケーションバッファに設けたコピー先領域に含まれる場合に限って、前記バッファコピー要求を生成し、前記ＴＣＰバッファコピー部のいずれかを選択して前記バッファコピー要求を通知することによって受信パケットのバッファコピーを分散並列処理させるように構成されることが好ましい。

第２の展開形態のＴＣＰバッファコピー分散並列処理装置は、
前記ＴＣＰ受信処理部、ＴＣＰバッファコピー部及びソケット処理部がいずれもイベントキューを備え、
要求送出側が要求受信側に設けたイベントキューに要求を追加することで要求を通知するように構成され、
要求受信側が自身に設けたイベントキューをポーリングしてイベントキューに要求が追加されている場合にはその要求を取り出して処理を行うように構成され、
前記ＴＣＰ受信処理部、ＴＣＰバッファコピー部及びソケット処理部が、それぞれ非同期動作を行うように構成されることが好ましい。

第３の展開形態のＴＣＰバッファコピー分散並列処理装置は、
前記ＴＣＰ受信処理部が、前記バッファコピー要求の通知先を前記ＴＣＰバッファコピー部の中からラウンドロビン（Ｒｏｕｎｄ Ｒｏｂｉｎ）によって選択するように構成されることが好ましい。

第４の展開形態のＴＣＰバッファコピー分散並列処理装置は、
前記ＴＣＰバッファコピー部が、バッファコピー処理を完了した場合には、コピーを実施したデータ長を含むバッファコピー完了通知を前記ソケット処理部に通知するように構成され、
前記アプリケーションバッファが、アドレスｂａｄｄｒから始まる長さｂｌｅｎの領域をコピー先領域として備え、
前記ソケット処理部が、前記バッファコピー完了通知に含まれるコピーを実施したデータ長を積算し、積算された値が前記アプリケーションバッファにおけるコピー先領域の長さｂｌｅｎに達したか否かに基づいて前記アプリケーションバッファの全ての領域に対するコピー要求が通知されたか否かを判定するように構成されることが好ましい。

第５の展開形態のＴＣＰバッファコピー分散並列処理装置は、
前記ＴＣＰバッファコピー部が、バッファコピー処理を完了した場合には、コピーを実施したデータ長とＴＣＰ受信処理部から通知された受信パケットのＴＣＰプロトコル処理後のＴＣＰパラメータｒｃｖ＿ｎｘｔとを含むバッファコピー完了通知を前記ソケット処理部に通知するように構成され、
前記アプリケーションバッファが、アドレスｂａｄｄｒから始まる長さｂｌｅｎの領域をコピー先領域として備え、
前記ソケット処理部が、前記バッファコピー完了通知に含まれるＴＣＰパラメータｒｃｖ＿ｎｘｔを参照し、その値に基づいて前記アプリケーションバッファの全ての領域に対するコピー要求が通知されたか否かを判定するように構成されることが好ましい。

第６の展開形態のＴＣＰバッファコピー分散並列処理装置は、
前記ＴＣＰバッファコピー部のうちＩ番目（１≦Ｉ≦Ｎ）のものから前記ソケット処理部に通知された前記バッファコピー完了通知が、振り分けの周回回数を示すリンクシーケンス（Ｌｉｎｋ Ｓｅｑｕｅｎｃｅ）番号Ｌｓｅｑ（Ｉ）を含み、
前記ソケット処理部が、前記アプリケーションバッファの全ての領域に対するコピー要求が通知されたと判定し、かつ、判定に用いられたバッファコピー完了通知がラウンドロビンによる振り分けのうちＩ番目である場合には、以下の２条件
（ａ）Ｌｓｅｑ（１）、・・・、Ｌｓｅｑ（Ｉ−１）＝＝Ｌｓｅｑ（Ｉ）、
（ｂ）Ｌｓｅｑ（Ｉ＋１）、・・・、Ｌｓｅｑ（Ｎ）＝＝Ｌｓｅｑ（Ｉ）−１
が満たされたとき、前記ＴＣＰバッファコピー部のすべてのバッファコピー処理が完了したものと判定するように構成されることが好ましい。

第７の展開形態のＴＣＰバッファコピー分散並列処理装置は、
前記ＴＣＰプロトコル処理部が、前記ＴＣＰバッファコピー部に備えたイベントキューの残量を参照し、前記ＴＣＰバッファコピー部の中からイベントキューの残量がより少ないものを前記バッファコピー要求の通知先として動的に選択するように構成されることが好ましい。

第８の展開形態のＴＣＰバッファコピー分散並列処理装置は、
前記ＴＣＰバッファコピー部が、バッファコピー処理を完了した場合には、コピーを実施したデータ長を含むバッファコピー完了通知を前記ソケット処理部に通知し、
前記アプリケーションバッファが、アドレスｂａｄｄｒから始まる長さｂｌｅｎの領域をコピー先領域として備え、
前記ソケット処理部が、前記バッファコピー完了通知に含まれるコピーを実施したデータ長を積算し、積算された値が前記アプリケーションバッファにおけるコピー先領域の長さｂｌｅｎに達したか否かに基づいて前記アプリケーションバッファの全ての領域に対するコピー要求が通知されたか否かを判定するように構成されることが好ましい。

第９展開形態のＴＣＰバッファコピー分散並列処理装置は、
前記ＴＣＰバッファコピー部が、バッファコピー処理を完了した場合には、コピーを実施したデータ長とＴＣＰ受信処理部から通知された受信パケットのＴＣＰプロトコル処理後のＴＣＰパラメータｒｃｖ＿ｎｘｔとを含むバッファコピー完了通知を前記ソケット処理部に通知するように構成され、
前記アプリケーションバッファが、アドレスｂａｄｄｒから始まる長さｂｌｅｎの領域をコピー領域として備え、
前記ソケット処理部が、前記バッファコピー完了通知に含まれるＴＣＰパラメータｒｃｖ＿ｎｘｔを参照し、その値に基づいて前記アプリケーションバッファの全ての領域に対するコピー要求が通知されたか否かを判定するように構成されることが好ましい。

第１０の展開形態のＴＣＰバッファコピー分散並列処理装置は、
前記ＴＣＰ受信処理部が、送出するバッファコピー要求が前記アプリケーションバッファのデータを埋める最後のデータを含むか否かをＴＣＰパラメータｒｃｖ＿ｎｘｔに基づいて判定し、前記アプリケーションバッファのデータを埋める最後のデータを含むものと判定した場合には、該バッファコピー要求の通知後、同一の振り分け周回においてまだ要求を通知していない全てのＴＣＰバッファコピー部に対してその周回のリンクシーケンス番号を含むダミーのバッファコピー要求を送出するように構成され、
前記ＴＣＰバッファコピー部が、それぞれバッファコピー完了通知を前記ソケット処理部に通知し、
前記ＴＣＰバッファコピー部のうちＩ番目（１≦Ｉ≦Ｎ）のものから前記ソケット処理部に通知された前記バッファコピー完了通知が、振り分けの周回回数を示すリンクシーケンス番号Ｌｓｅｑ（Ｉ）（１≦Ｉ≦Ｎ）を含み、
前記ソケット処理部が、前記バッファコピー完了通知に基づいて前記アプリケーションバッファの全ての領域へパケットデータコピーされたか否かを判定し、前記アプリケーションバッファの全ての領域に対するコピー要求が通知されたと判定し、かつ、前記ＴＣＰバッファコピー部から通知されたバッファコピー完了通知のリンクシーケンス番号がいずれも等しい場合には、前記ＴＣＰバッファコピー部のバッファコピー処理が完了したと判定するように構成されることが好ましい。

本発明の第２の視点に係るＴＣＰバッファコピー分散並列処理方法は、
ＴＣＰバッファコピー分散並列処理装置によって、受信パケットに対するＴＣＰプロトコル処理を実施する工程と、
前記受信パケットが対向ホストによって送信された順序と同一の順序で到着した（インオーダー、Ｉｎ−Ｏｒｄｅｒ）か否かを判定する工程と、を含むＴＣＰバッファコピー分散並列処理方法であって、
インオーダーと判定された場合には、前記受信パケットを受信パケットバッファに設けたインオーダーキューに格納する工程と、
前記受信パケットのＴＣＰシーケンス番号に基づいてアプリケーションバッファにおけるコピー先の領域を決定する工程と、
前記受信パケットを前記受信パケットバッファから前記アプリケーションバッファにコピーするバッファコピー要求を生成する工程と、
１又は２以上のＴＣＰバッファコピー部のいずれかを選択して前記バッファコピー要求を通知することによって前記受信パケットのバッファコピーを分散並列処理させる工程と、を含み、
前記受信パケットが対向ホストによって送信された順序と異なる順序で到着した（アウトオブオーダー、Ｏｕｔ−ｏｆ−Ｏｒｄｅｒ）と判定された場合には、前記受信パケットを前記受信パケットバッファに設けたアウトオブオーダーキューに格納する工程を含むことを特徴とする。

本発明の第３の視点に係るＴＣＰバッファコピー分散並列処理プログラムは、
コンピュータによって、受信パケットに対するＴＣＰプロトコル処理と、
前記受信パケットが対向ホストによって送信された順序と同一の順序で到着した（インオーダー、Ｉｎ−Ｏｒｄｅｒ）か否かを判定する処理と、を実行させるＴＣＰバッファコピー分散並列処理プログラムであって、
インオーダーと判定された場合には、前記受信パケットを受信パケットバッファに設けたインオーダーキューに格納する処理と、
前記受信パケットのＴＣＰシーケンス番号に基づいてアプリケーションバッファにおけるコピー先の領域を決定する処理と、
前記受信パケットを前記受信パケットバッファから前記アプリケーションバッファにコピーするバッファコピー要求を生成する処理と、
１又は２以上のＴＣＰバッファコピー部のいずれかを選択して前記バッファコピー要求を通知することによって前記受信パケットのバッファコピーを分散並列処理させる処理と、をコンピュータに実行させ、
前記受信パケットが対向ホストによって送信された順序と異なる順序で到着した（アウトオブオーダー、Ｏｕｔ−ｏｆ−Ｏｒｄｅｒ）と判定された場合には、前記受信パケットを前記受信パケットバッファに設けたアウトオブオーダーキューに格納する処理をコンピュータに実行させることを特徴とする。

第１の効果として、ＴＣＰ受信処理後のインオーダーデータのバッファコピー処理を複数のＴＣＰバッファコピー部に分散して並列に実行させることによって、処理負荷の大きいＴＣＰバッファコピー処理の処理時間を短縮することができる。また、ＴＣＰ受信処理部、ＴＣＰバッファコピー部及びソケット処理部がイベントキューを介して非同期に動作することによって、ＴＣＰ受信処理、バッファコピー処理及びソケット処理の間でパイプライン実行がなされるため、全体を一つのプロセスにおいて実行する場合と比較して高速なパケット処理が可能となる。

従来技術においては、アウトオブオーダーデータは、受信後に再構築可能となるまでアプリケーションバッファにコピーせずに待機させていた。したがって、インオーダーデータの再送によって格納されていたアウトオブオーダーデータが再構築可能になったときに、インオーダーデータとともに再構築可能になったアウトオブオーダーデータのバッファコピー要求も発行されることによってバッファコピー処理が過負荷になるという問題があった。本発明の第２の効果として、アウトオブオーダーデータの受信後、対応するコピー先がアプリケーションバッファの範囲内であるならばアウトオブオーダーデータが再構築可能となるのを待たずにバッファコピーを行うことによって、アウトオブオーダーデータのバッファコピー時における負荷の集中を回避することができる。

従来技術においては、バッファコピー処理が完了したデータ長を積算することによってアプリケーションバッファが埋められたか否かの判定を行っていた。本発明の第３の効果として、ＴＣＰパラメータであるｒｃｖ＿ｎｘｔによってアプリケーションバッファが埋められたことを判定することで、受信アウトオブオーダーデータに重なりが発生した場合であっても、従来とは異なり、アプリケーションバッファの全ての領域に対してバッファコピー要求が発行されたことを判定することができる。

本発明の第４の効果として、ＴＣＰプロトコル処理後のバッファコピー処理を分散並列処理した場合において、動的に振り分け先を決定したときでも、全ての振り分け先のブロックのバッファコピー処理が完了したことを検知することができる。その理由は、ＴＣＰプロトコル処理部でアプリケーションバッファの最後のデータのコピー要求後、全てのＴＣＰバッファコピー要求ブロックに対してバッファコピー要求が通知されていることが保証されているため、そのバッファコピー処理に対する完了通知の情報から全てのバッファコピー処理が完了したことを検知することが可能となるためである。

本発明の実施形態に係るＴＣＰバッファコピー分散並列処理装置、方法及びプログラムは、ＴＣＰプロトコル処理後、インオーダーと判定されたパケットの有効データをアプリケーションバッファへコピー要求する際に、バッファコピー要求先を複数のＴＣＰバッファコピー部のうちからラウンドロビンで選択してバッファコピー要求を送出することで、ＴＣＰプロトコル処理後のパケットデータのアプリケーションバッファへのバッファコピーを分散並列処理して性能向上を実現することが好ましい。

また、本発明の実施形態に係るＴＣＰバッファコピー分散並列処理装置、方法及びプログラムは、ＴＣＰプロトコル処理後、アウトオブオーダーと判定されたパケットの有効データのコピー先がアプリケーションバッファの領域内であるなら、アウトオブオーダーデータが再構築可能になるのを待たずにアウトオブオーダーデータのバッファコピーを行うことによって、コピー処理の均一化を実現し処理時間の短縮を行うことが好ましい。

さらに、本発明の実施形態に係るＴＣＰバッファコピー分散並列処理装置、方法及びプログラムは、アプリケーションバッファのデータが揃ったことを検知するため、ＴＣＰプロトコル処理部が管理しているＴＣＰパラメータｒｃｖ＿ｎｘｔ及びバッファコピーの要求回数を管理するリンクシーケンス番号を、ＴＣＰバッファコピー部を経由してバッファコピー完了通知に付与して送付することによりアウトオブオーダーデータの重なりが発生している状態でもアプリケーションバッファが揃ったことを正しく検知することが好ましい。

また、本発明の実施形態に係るＴＣＰバッファコピー分散並列処理装置、方法及びプログラムは、ＴＣＰプロトコル処理部がアプリケーションバッファの最後の領域に該当するデータのバッファコピー要求を送付した後、振り分けの周回でまだバッファコピー要求を送付していない全てのブロックに対してダミーのバッファコピー要求を通知することで、バッファコピーの分散先を動的に選択するような場合でも全てのブロックでのバッファコピー処理が完了したことを検知できることが好ましい。

（実施形態１）
次に、本発明の実施形態について図面を参照して詳細に説明する。図１を参照すると、本発明の実施形態に係るＴＣＰバッファコピー分散並列処理装置１０は、ＴＣＰパケットを受信してプロトコル処理を行うＴＣＰ受信処理部１と、受信パケットを受信パケットバッファからアプリケーションバッファにコピーするＮ個（Ｎ≧１）のＴＣＰバッファコピー部２１〜２Ｎと、ソケット処理を行うソケット処理部３と、アプリケーションが動作するアプリケーション部４と、受信パケットを格納する受信パケットバッファ５と、アプリケーションに渡すストリームデータを格納するアプリケーションバッファ６と、ネットワークインタフェース部１、ＴＣＰバッファコピー部２１〜２Ｎ及びソケット処理部３の間でコマンド情報を交換するためのイベントキュー７１、７２１〜７２Ｎ、７３を含む。

受信パケットバッファ５は、ＴＣＰのインオーダーデータを格納するインオーダーキュー５１と、ＴＣＰのアウトオブオーダーデータを格納するアウトオブオーダーキュー５２を備える。

ＴＣＰのインオーダーデータとは、受信したＴＣＰパケットが対向ホストの送出順と同じ順番で受信されたと判断されたデータであり、ストリームに再構築可能なデータである。一方、ＴＣＰのアウトオブオーダーデータとは、中間経路で前のパケットが欠落したために、送出順とは異なる順で到着したデータであり、欠落した部分に相当するＴＣＰデータを受信するまではストリームに再構築することができない。インオーダーキュー５１は受信したＴＣＰシーケンス番号からインオーダーデータと判断されたＭ個（Ｍ≧１）のパケットデータ５１１〜５１Ｍを連結リスト構造で格納する。

アウトオブオーダーキュー５２は、受信したＴＣＰシーケンス番号からアウトオブオーダーデータと判断されたパケットデータ５２１、５２２をインオーダーキューと同様連結リスト構造で格納する。

インオーダーキュー５１とアウトオブオーダーキュー５２の構造を図５に示す。インオーダーキューのエントリのうち、バッファコピー要求を行っていない先頭のエントリは有効エントリのアドレスＧ１として管理される。また、インオーダーキューのエントリＧ２は要素として、次エントリの開始アドレスＧ２１、ヘッダアドレスＧ２２、データアドレスＧ２３、有効データのアドレスＧ２４、有効データ長Ｇ２５、受信パケットのヘッダＧ２６及びデータＧ２７を有する。

次エントリの開始アドレスＧ２１は、キューの次のエントリの先頭位置のアドレスを指し示す。ヘッダアドレスＧ２２は、エントリＧ２に該当する受信パケットのヘッダ情報が格納されているアドレスを指し示す。データアドレスＧ２３はエントリＧ２に該当する受信パケットのペイロード情報が格納されているアドレスを指し示す。有効データのアドレスＧ２４は受信パケットのペイロードのうち、アプリケーションバッファ６にコピー可能な領域の先頭アドレスを指し示す。有効データ長Ｇ２５は受信パケットのペイロードのうち、アプリケーションバッファ６にコピー可能な領域の長さを指し示す。ヘッダＧ２６は受信パケットのヘッダ情報を格納する。データＧ２７は受信パケットのペイロード情報を格納する。データＧ２７はアプリケーションバッファ６へコピー可能な領域とコピー可能ではない領域を含む。コピー可能な領域は有効データのアドレスＧ２４及び有効データ長Ｇ２４によって指定される。

アウトオブオーダーキュー５２のエントリＧ３は要素としてＧ３１〜Ｇ３７を含む。これらはインオーダーキュー５１のエントリＧ２のＧ２１〜Ｇ２７と機能が同一であるため、説明を省略する。

アプリケーションバッファ６は、ソケット処理部３からアプリケーション部４へ渡すストリームデータを格納する。受信パケットバッファ５に格納されていた受信パケット５１１〜５１Ｍは、ＴＣＰ処理後、アプリケーションバッファ６のバッファ開始アドレスから始まる連続した領域６１〜６Ｍにそれぞれコピーされる。コピーされたデータは、開始アドレスからバッファ長分の連続領域にストリームデータが揃った時点で、アプリケーション部４に渡される。

ＴＣＰ受信処理部１は、ネットワークインタフェース部１１と、パケット処理部１２と、ＴＣＰプロトコル処理部１３と、を備える。

ネットワークインタフェース部１１は、対向ホストからパケットを受信し、受信パケットバッファにパケットデータを格納する。また、ネットワークインタフェース部１１は、対向ホストにパケットを送出する。

パケット処理部１２は、受信したパケットの整合性をチェックし、受信したパケットのセッション解決を行い、パケットのヘッダ情報を抽出する。また、パケット処理部１２は送出パケットデータを生成する。

ＴＣＰプロトコル処理部１３は、受信したパケットのＴＣＰプロトコル処理を行うとともに、ＡＣＫパケットの生成処理を行う。ＴＣＰプロトコル処理においては、受信ＴＣＰパケットのシーケンス番号を参照し、受信パケットがインオーダーデータかアウトオブオーダーデータかの判定がなされる。インオーダーデータと判定された場合には、受信パケットの情報はインオーダーキュー５１に追加され、アウトオブオーダーデータと判定された場合にはアウトオブオーダーキュー４２に追加される。さらに、ＴＣＰプロトコル処理部１３は、ＴＣＰバッファコピー部２１〜２Ｎに対してＴＣＰバッファコピー要求を生成する。

ＴＣＰバッファコピー部２１〜２Ｎは、ＴＣＰ受信処理部１からのバッファコピー要求を受信し、受信した情報に従って、受信パケットバッファ５からアプリケーションバッファ６へのコピー処理を実施する。また、ＴＣＰバッファコピー部２１〜２Ｎは、コピー完了後に、ソケット処理部３に対してバッファコピー完了通知を行う。

ソケット処理部３は、アプリケーション部４からの要求を受信する以外に、ＴＣＰバッファコピー部２１〜２Ｎからバッファコピー完了通知を受信してアプリケーションバッファ６のストリームデータが揃ったか否かを検知する。バッファ開始アドレスからバッファ長までのストリームデータが揃った時点で、ソケット処理部３はアプリケーション４に処理の完了を通知する。

アプリケーション部４は、ソケット処理部３に対してストリームの受信要求を生成する。その際、受信したいストリームデータの先頭アドレスとデータ長をソケット処理部３に通知する。ソケット処理部３からの完了通知受信を受信後、アプリケーション部４はストリームデータを操作することができるようになる。

次に、図１〜図４を参照して本実施形態の動作について詳細に説明する。まず、図１及び図２を参照して受信処理の動作について説明する。

アプリケーション部４は、対向ホストからのデータストリームを受信して処理を実行するプログラムである。アプリケーション部４は、データストリームを取得するため、ソケット処理部３に対して受信要求を発行する（ステップＡ１）。受信要求の例として、ＴＣＰソケットのｒｅｃｖシステムコールが挙げられる。なお、ｒｅｃｖシステムコールは、ストリームデータが揃うまでアプリケーション部が待機する同期式の通知方法であるが、ストリームデータが揃うまでの間にアプリケーション部４が他の処理を実行することができる非同期式の通知であっても良い。受信要求には、引数として、アプリケーションバッファ６のバッファ開始アドレスｂａｄｄｒとバッファ長ｂｌｅｎが含まれる。

ＴＣＰ受信処理部１、ＴＣＰバッファコピー部２１〜２Ｎ及びソケット処理部３はアプリケーション部４の受信要求を受け、対向ホストパケット受信時にＴＣＰ受信プロトコル処理（ステップＡ２）及び並列バッファコピーの処理（ステップＡ３）を行う。ＴＣＰ受信プロトコル処理及び並列バッファコピーの詳細については後述する。並列バッファコピー処理によって、アプリケーション部４が要求していたストリームデータが揃った場合には、ソケット処理部３はアプリケーション部４に受信処理完了通知を通知し、受信処理が完了する（ステップＡ４）。

次に、図１及び図３を参照して、ＴＣＰ受信プロトコル処理の動作について詳細に説明する。

ネットワークインタフェース部１１において対向ホストからＴＣＰパケットを受信後（ステップＢ１）、パケット処理部１２は、受信パケットのヘッダからＴＣＰ及びＩＰのパラメータ情報を抽出し、受信パケットがいずれのＴＣＰセッションに所属しているかを解析する（ステップＢ２）。

続いて、ＴＣＰプロトコル処理部１３は、ＴＣＰの受信プロトコル処理を行う（ステップＢ３）。受信プロトコル処理の例として、ｒｃｖ＿ｎｘｔ等のＴＣＰパラメータの更新、ＴＣＰシーケンス番号から受信したパケットがインオーダーデータかアウトオブオーダーデータかの判定、受信パケットからデータストリームを再構築するために受信パケットのどこからどこまでの範囲が有効データなのかを示すパケットデータの有効アドレスと有効パケット長の決定、対向ホストに受信が完了したデータのシーケンス番号を伝えるＡＣＫパケットの生成等が挙げられる。

受信プロトコル処理後、その処理結果に基づいて、受信パケットがインオーダーデータかアウトオブオーダーデータかの判断処理を行う（ステップＢ４）。インオーダーデータである場合（ステップＢ４のＹｅｓ）にはインオーダーキュー５１に受信パケット情報を追加し（ステップＢ５）、アウトオブオーダーデータである場合（ステップＢ４のＮｏ）にはアウトオブオーダーキュー５２に受信パケット情報を追加する（ステップＢ６）。

また、インオーダーデータが再送パケットである場合には、受信したインオーダーデータによってアウトオブオーダーであったデータの欠落したデータが埋められ、再構築可能となるアウトオブオーダーデータが存在する場合がある。このようなアウトオブデータが存在する場合には、再構築可能となったアウトオブオーダーデータをアウトオブオーダーキューから削除してインオーダーキューに追加する（ステップＢ７）。

次に、図１及び図４を参照して、並列バッファコピー処理の動作について詳細に説明する。ソケット処理部３は、アプリケーション部４の処理開始要求を受けてＴＣＰプロトコル処理部１３に対して処理開始通知を発行する。ＴＣＰプロトコル処理部１３は、ＴＣＰバッファコピー部に対してバッファコピー処理要求を発行する。ＴＣＰバッファコピー部２１〜２Ｎは、バッファコピー処理要求を受けてバッファコピー処理を実行する。ソケット処理部３は、バッファコピー結果の確認を行い、データが揃った時点でアプリケーション部４に通知する。また、バッファコピー前の領域はＴＣＰプロトコル処理部１３によって解放処理を行う。

初めにソケット処理部３の動作について説明する。ソケット処理部３は、アプリケーション処理部１からの受信処理要求を受けるまで待機する（ステップＣ１）。ソケット処理部３は、アプリケーション部４からの受信要求を受けて、ＴＣＰ受信処理部１に処理開始要求を発行する（ステップＣ２）。発行した処理要求は、イベントキュー７１に格納される。処理開始要求発行後、ソケット処理部３は、ＴＣＰバッファコピー部２１〜２Ｎからの通知が来るまで待機する（ステップＣ３）。ＴＣＰバッファコピー部２１〜２Ｎの要求はイベントキュー７３に格納される。イベントキュー７３からバッファコピー完了通知を取得後（ステップＣ４）、バッファコピー前のパケットデータを解放するために、ＴＣＰ受信処理部１へパケットバッファ解放要求を送出する（ステップＣ５）。また、バッファコピーにより、アプリケーション部４から受信要求のあったアプリケーションバッファ６の開始アドレスｂａｄｄｒからバッファ長ｂｌｅｎまでの領域が全て埋められたか否かを判定する（ステップＣ６）。アプリケーションバッファが埋められた場合（ステップＣ６のＹｅｓ）にはアプリケーション部４に受信処理の完了を通知する（ステップＣ７）。それ以外の場合（ステップＣ６のＮｏ）には、ＴＣＰバッファコピー部２１〜２Ｎからの通知待ち（ステップＣ３）に戻る。アプリケーション部４への受信処理完了の通知方法は、例えばｒｅｃｖシステムコールであれば関数を終了させることによって通知する方法が用いられる。非同期関数の場合には、アプリケーション部４に処理結果を取得する手段を用意しておき、アプリケーション部４が取得結果を定期的に要求し、受信処理完了時はその要求に対して完了した旨を通知するという方法が用いられる。

次に、ＴＣＰプロトコル処理部１３のバッファコピー並列要求処理の動作について説明する。ＴＣＰプロトコル処理部１３は、ソケット処理部３からの通知を格納するイベントキュー７１を参照し、ソケット処理部３からの受信処理要求を受信する（ステップＤ１）。ＴＣＰプロトコル処理部１３は、インオーダーと判定されたパケットが格納されているインオーダーキュー５１の各有効エントリを順次処理する（ステップＤ２〜Ｄ７）。バッファコピー要求を送出していない状態ではインオーダーキュー５１の全てのエントリが有効エントリである。一方、エントリ中の全データ領域のバッファコピー要求を送出したエントリは無効エントリとなる。無効エントリは、バッファコピーが完了してソケット処理部３からバッファコピー完了通知を取得した場合、インオーダーキューから削除される。ＴＣＰプロトコル処理部１３は、有効エントリのアドレス情報を保持する。

ＴＣＰプロトコル処理部１３はインオーダーキューの有効エントリの情報取得後、バッファコピー要求を生成する（ステップＤ３）。この時の要求フィールドは、コピー元アドレスとコピー先アドレス及びコピー長である。コピー元アドレスはインオーダーキューの有効エントリのパケットデータの有効アドレスであり、コピー先アドレスはアプリケーションバッファ６中の対応するアドレスである。また、コピー長はインオーダーキューの有効エントリのパケットデータの有効長である。

ここで、図１を参照してコピー先のアドレスについての具体例を挙げる。セッション開始後、最初のデータ群としてインオーダーキューにＭ個のパケット５１１〜５１Ｍが到着したものとする。これらはリスト構造に基づいて、インオーダーキューに格納される。これらは、アプリケーションバッファ６において、バッファ開始アドレスｂａｄｄｒから順に詰められてコピーされる。すなわち、次のようにコピーされる。
パケット５１１→コピー元：ｐａｄｄｒ（１）、コピー先：ｂａｄｄｒ（１）＝ｂａｄｄｒ、コピー長：ｐｌｅｎ（１）
パケット５１２→コピー元：ｐａｄｄｒ（２）、コピー先：ｂａｄｄｒ（２）＝ｂａｄｄｒ（１）＋ｐｌｅｎ（１）、コピー長：ｐｌｅｎ（２）
・・・・
パケット５１Ｎ→コピー元：ｐａｄｄｒ（Ｍ）、コピー先：ｂａｄｄｒ（Ｍ）＝ｂａｄｄｒ（Ｍ−１）＋ｐｌｅｎ（Ｍ−１）、コピー長：ｐｌｅｎ（Ｍ−１）

図１、図４のバッファコピー並列要求処理の動作の説明に戻る。ＴＣＰプロトコル処理部１３は、バッファコピー要求のフィールドを決定してバッファコピー要求を生成後、要求先をＴＣＰバッファコピー部２１〜２Ｎの中から決定する（ステップＤ４）。バッファコピー要求先は、例えば、ラウンドロビンによって決定する。つまり、ＴＣＰバッファコピー部の要求先を２１、２２、…、２Ｎの順に決定する。ＴＣＰバッファコピー部２Ｎまで要求した後、再度、要求先をＴＣＰバッファコピー部２１から順に選択していく。

バッファコピー要求先決定後はイベントキュー７２１〜７２Ｎのうち要求先に対応するキューに要求を追加する（ステップＤ５）。イベントキューに要求を追加後、インオーダーキュー５１の次の有効エントリの情報を取得し（ステップＤ６）。インオーダーキューのエントリが残っているのであればアプリケーションバッファ６への全ての領域に対してバッファコピー要求を行うまでステップＤ３〜Ｄ６の処理を繰り返す（ステップＤ７）。

続いてＴＣＰバッファコピー部２１〜２Ｎの動作について説明する。ＴＣＰバッファコピー部２１〜２Ｎは、それぞれ対応するイベントキュー７２１〜７２Ｎを監視し、ＴＣＰ受信処理部１からバッファコピー要求を受信し（ステップＥ１）、バッファコピー要求のコピー元、コピー先、そしてコピー長情報に従ってバッファコピー処理を実施する（ステップＥ２）。バッファコピー処理完了後、バッファコピー完了通知をソケット処理部３に通知する（ステップＥ３）。バッファコピー完了通知はバッファコピー要求と同じフィールドを含む。

次に、ＴＣＰプロトコル処理部１３の受信バッファ解放処理の動作について説明する。本動作はバッファコピー後のコピー元の領域を解放するために必要とされる。ＴＣＰプロトコル処理部１３は、イベントキュー７１を監視し、ＴＣＰソケット処理部３からパケットバッファ解放要求を受信後（ステップＦ１）、パケットバッファ解放要求に対応するインオーダーキュー５１のパケットデータを解放する（ステップＦ２）。

本実施形態の効果について説明する。本実施形態では、ＴＣＰ受信処理後、バッファコピー処理要求を複数のＴＣＰバッファコピー部２１〜２Ｎに振り分けて通知することによりバッファコピー処理を並列に実行する。これにより処理負荷の大きいＴＣＰバッファコピー処理の処理時間を並列度に応じて短縮することができるという利点がある。

また、ＴＣＰ受信処理部１、ＴＣＰバッファコピー部２１〜２Ｎ及びソケット処理部３はイベントキューを介して処理要求を通知することにより非同期に動作するようにしてもよい。これによって、ＴＣＰ受信処理、バッファコピー処理及びソケット処理間のパイプライン実行が可能となるため、全体処理が一つのプロセスで実行される場合と比較して高速なパケット処理が可能となる。

（実施形態２）
次に、本発明の第２の実施形態について図面を参照して詳細に説明する。図６は、本実施形態に係るＴＣＰバッファコピー分散並列処理装置２０の構成を示すブロック図である。本実施形態は、アウトオブオーダーデータの対応するコピー先がアプリケーションバッファ６の範囲内であるならばアウトオブオーダーデータが再構築可能になるのを待たずにバッファコピーを実施することによりパケット廃棄が発生した場合でも再構築処理時にバッファコピー要求が過負荷になり性能劣化することを防ぐというものである。

図６を参照すると、インオーダーキュー５１にはパケット５１１〜５１ＭのＭ個のパケットが格納されている。このときのＭ個のパケットは第１の実施形態によりアプリケーションバッファ６上の領域６１〜６Ｍにコピーされる。さらに、アウトオブオーダーキューにパケット５２１が格納されており、このパケット５２１のシーケンス番号から求められたコピー先がアプリケーションバッファ６のバッファ開始アドレスｂａｄｄｒからバッファ長ｂｌｅｎまでの範囲内にあるならば、パケット５２１のデータはアプリケーションバッファ６上の領域６Ｋ（Ｋ≧１、Ｋ＞Ｍ）にコピーされる。

本実施形態の動作について図面を参照して詳細に説明する。図７は、第２の実施形態の動作フローを示す。第２の実施形態は、第１の実施形態に対してステップＤ８〜Ｄ１４の工程が追加されている。図７におけるステップＤ１〜Ｄ７、すなわち、本実施形態におけるＴＣＰプロトコル処理部１３の動作は、図４におけるステップＤ１〜Ｄ７と同一であるため、説明を省略する。第２の実施形態では、ステップＤ１〜Ｄ７までの処理によってインオーダーキューの全ての有効エントリのデータをコピー後、アウトオブオーダーキュー５２のエントリについてもバッファコピー要求処理を実施する。そこで、本実施形態においては、アウトオブオーダーキュー５２のバッファコピー要求処理を行っていないエントリのアドレスがアウトオブオーダーキューの有効エントリとして管理される。

ＴＣＰプロトコル処理部１３は、アウトオブオーダーキュー５２の有効エントリの情報を取得し（ステップＤ８）、有効エントリに該当するデータのコピー先がアプリケーションバッファ６の範囲内か否かを判定する（ステップＤ９）。

データのコピー先は、有効エントリに該当するパケットデータのＴＣＰシーケンス番号から求める。ここで、有効パケットデータのＴＣＰシーケンス番号がｓｅｑ＿ｏ、有効長がｌｅｎ＿ｏであるものとする。アプリケーションバッファの先頭に該当するＴＣＰシーケンス番号がｓｅｑ＿ｂ、アプリケーションバッファ６の先頭アドレスがｂａｄｄｒ、バッファ長がｂｌｅｎであるすると、コピー先アドレスａｄｄｒは以下の関係式から求められる。
ａｄｄｒ＝ｂａｄｄｒ＋ｓｅｑ＿ｏ−ｓｅｑ＿ｂ

また、このとき、（ｓｅｑ＿ｏ−ｓｅｑ＿ｂ）≦ｂｌｅｎの関係式を満たさなければならない。この関係式が満たされない場合には、そのエントリのデータはアプリケーションバッファの範囲外と見なされる。

判定の結果、データコピー先がアプリケーションバッファの範囲外である場合（ステップＤ９のＮｏ）にはアウトオブオーダーキュー５２の次の有効エントリに処理を進める。
一方、範囲内である場合（ステップＤ９のＹｅｓ）には、ＴＣＰバッファコピー部２に対しバッファコピー要求を生成する（ステップＤ１０）。この要求のコピー元はアウトオブオーダーキューの処理中のエントリに対応する有効データの開始アドレスである。一方、コピー先はアプリケーションバッファの対応領域のアドレスａｄｄｒ、コピー長は処理中エントリの有効データ長となる。

バッファコピー要求を生成後、要求先をＴＣＰバッファコピー部２１〜２Ｎの中から決定する（ステップＤ１１）。本実施形態では、例えば、第１の実施形態と同様バッファコピー要求先をラウンドロビンによって決定することができる。つまり、要求先のＴＣＰバッファコピー部を２１、２２、・・・、２Ｎの順に選択する。２Ｎまで要求した後、再度要求先を２１から順に選択していく。

バッファコピー要求先決定後、イベントキュー７２１〜７２Ｎのうち要求先に対応するキューに要求を追加する（ステップＤ１２）。イベントキューに要求を追加後、アウトオブオーダーキュー５１の次の有効エントリの情報を取得する（ステップＤ１３）。アウトオブオーダーキューのエントリが残っている場合には、残りのエントリに対してステップＤ９〜Ｄ１３の処理を繰り返す（ステップＤ１４）。

本実施形態の効果について説明する、従来のＴＣＰ処理では、アウトオブオーダーデータを受信後ストリームが再構築可能になるまで、パケットデータは受信パケットバッファ５に格納されていた。この場合、インオーダーデータの再送により格納されていたアウトオブオーダーデータが再構築可能になったときに、１個分のパケット受信処理のタイムスロットでインオーダーデータに加えて再構築可能になったアウトオブオーダーデータのバッファコピー要求も発行されるため、バッファコピー処理要求がそのタイムスロットだけ過負荷になるという問題があった。そこで、本実施形態では、アウトオブオーダーデータ受信後、対応するコピー先がアプリケーションバッファの範囲内であるならばアウトオブオーダーデータが再構築可能になるのを待たずにバッファコピー要求を送出することで均一の処理時間でバッファコピーを行うものとした。これによって、アウトオブオーダーデータが再構築可能になった時のバッファコピー要求の負荷が集中することが回避される。

また、本実施形態において、次の点に留意すべきである。アウトオブオーダーデータのバッファコピー後における受信パケットバッファ５の解放処理では、解放処理によってパケットデータ自体は解放しても構わない。しかし、アウトオブオーダーデータのシーケンス番号を含む制御情報は何らかの形で保持しておく必要がある。そうしないと、ＴＣＰプロトコル処理部１３にてアウトオブオーダーデータ範囲を考慮したＴＣＰパラメータ更新（例えばｒｃｖ＿ｎｘｔの更新）ができなくなるからである。

（実施形態３）
次に、本発明の第３の実施形態について説明する。図９は、本実施形態に係るＴＣＰバッファコピー分散並列処理装置３０の構成を示すブロック図である。第２の実施形態では受信したアウトオブオーダーデータを再構築可能になるのを待たずにアプリケーションバッファ６にコピーする方式であった。しかしながら、この場合、アプリケーションバッファ６のデータがいつ揃ったのかを判定することが困難となる。第１の実施形態のように、アプリケーションバッファ６にコピーされるのは常にインオーダーデータであることが保障されている場合には、バッファコピー完了通知に示されたコピー完了データ長を積算していくだけでデータが揃ったか否かを判断可能である。しかし、インオーダーデータに加えてアウトオブオーダーデータがコピーされるような条件下では、単にコピーされたデータ長を積算していくだけでは、アプリケーションバッファ６のデータが揃ったか否かを判定することができなくなる。

データがそろったか否かを判定することができないような例を図８に示す。図８はアウトオブオーダーデータがデータ再構築可能となる場合を示している。図８のＣａｓｅ１では、インオーダーのパケット１、パケット２、そしてアウトオブオーダーのパケット３が到着した状態を示す。Ｃａｓｅ２では、パケット２とパケット３との間にあたるデータ領域にインオーダーのパケット４が到着することによって、パケット３が再構築可能になった状態を示す。しかし、Ｃａｓｅ２では、パケット３とパケット４との間に重なりが生じている。この場合、ＴＣＰでは前のシーケンスから続いているデータが優先されるため、パケット３の情報はデータ重なり長ｄの分だけパケット４に上書きされる。このとき、コピー完了データ長の合計とアプリケーションバッファ６に揃ったデータ長の合計に重なり長ｄの分だけ不整合が生じる。したがって、ソケット処理部３が、バッファコピー完了通知に記載されたコピー完了データ長を積算していくことによってデータが揃ったか否かを判定する場合には、アプリケーションデータが揃ったことを検知することができなくなる。

第３の実施形態は、このような系で一般的に採用されている、バッファコピー完了通知に示されたコピー完了データ長を積算することによってアプリケーションデータが揃ったことを判定するという手段の代わりに、ＴＣＰプロトコル処理部１３において管理されるＴＣＰパラメータｒｃｖ＿ｎｘｔの値をバッファコピー完了通知に含めることにより、アウトオブオーダーデータの重なりが生じた場合にも正確にアプリケーションデータが揃ったことを判定できるようにする。

図８はＴＣＰプロトコル処理部１３において管理されるＴＣＰパラメータｒｃｖ＿ｎｘｔを示す。ＴＣＰパラメータｒｃｖ＿ｎｘｔはＲＦＣ７９３で規定されたパラメータであり、再構築可能な受信データの末尾のデータのシーケンス番号を示す。

図８を参照すると、Ｃａｓｅ１の場合には、パケット３が到着した時点でパケット２までが再構築可能となるのでｒｃｖ＿ｎｘｔの値はパケット２の末尾を示している（ｒｃｖ＿ｎｘｔ１）。一方、Ｃａｓｅ２の場合には、パケット４まで到着した時点でパケット３が再構築可能となるため、ｒｃｖ＿ｎｘｔの値はアウトオブオーダーデータであったパケット３の末尾を示している（ｒｃｖ＿ｎｘｔ３）。

続いて第３の実施形態の構成について図面を参照して詳細に説明する。図９を参照すると、本発明の第３の実施形態に係るＴＣＰバッファコピー分散並列処理装置３０は、データ再構築情報管理部８を備える。

データ再構築情報管理部８は、ＴＣＰバッファコピー部２１〜２Ｎから送付されたバッファコピー完了通知に含まれるＮ個のリンクシーケンス番号を保持する８２１〜８２Ｎ、及び、ＴＣＰパラメータのｒｃｖ＿ｎｘｔ情報を管理するｒｃｖ＿ｎｘｔ管理部８を含む。リンクシーケンス番号は、ＴＣＰバッファコピー部２１〜２Ｎへのバッファコピー要求の振り分けの周回数を管理する番号であり、ＴＣＰ受信処理部１が全てのＴＣＰバッファコピー部２１〜２Ｎにバッファコピー要求を送信する毎に１ずつ増加する。

次に、第３の実施形態の動作について示す。図１０を参照すると、第３の実施形態の動作は、ＴＣＰプロトコル処理部１３のバッファコピー要求生成処理と、ソケット処理部３のアプリケーションバッファ６の全ての領域にデータがコピーされたか否かを判定する完了（Ｃｏｍｐｌｅｔｉｏｎ）判定処理と、に分けられる。

ＴＣＰプロトコル処理部１３のバッファコピー要求生成処理の動作について説明する。バッファコピー要求生成処理は、第１及び第２の実施形態におけるステップＤ３（図４、図７）に相当する。本実施形態では、第１、第２の実施形態の動作に加えて、バッファコピー要求の生成時にリンクシーケンス番号を決定する（ステップＤ３１）。リンクシーケンス番号はＴＣＰ受信処理部１からＴＣＰバッファコピー部２１〜２Ｎに対してのバッファコピー要求が一巡する度に１ずつ増加する。リンクシーケンス番号の生成後、バッファコピー要求を生成する（ステップＤ３２）。要求フィールドは第１、第２の実施形態のフィールドに加えてリンクシーケンス番号及びＴＣＰパラメータのｒｃｖ＿ｎｘｔを含む。

バッファコピー要求生成前の処理及び要求生成後のＴＣＰプロトコル処理部１３の動作は図４、図７における動作と同一であるため、説明を省略する。

また、ＴＣＰバッファコピー部２１〜２Ｎは、バッファコピー要求に付与されていたリンクシーケンス番号及びｒｃｖ＿ｎｘｔパラメータをバッファコピー完了通知に付与してソケット処理部３に転送する。

次に、アプリケーションバッファの全ての領域に対するコピー処理の完了の判定方法について説明する。ソケット処理部３に転送されたバッファコピー完了通知のｒｃｖ＿ｎｘｔの値が、アプリケーションバッファ６の末尾に達していない場合（ステップＣ６１のＮｏ）には、アプリケーションバッファ６の全ての領域に対するバッファコピー要求は通知されていないと判定する（ステップＣ６６）。一方、末尾に達していた場合（ステップＣ６１のＹｅｓ）には、アプリケーションバッファ６の全ての領域に対するバッファコピー要求が通知されたものと判定し、そのリンクシーケンス番号を抽出する（ステップＣ６２）。抽出されたリンクシーケンス番号をＬｓｅｑ（Ｉ）とする。リンクシーケンス番号の抽出後、以下の２つの条件に対して、リンクシーケンス番号の値を比較することによって、ＴＣＰバッファコピー部２１〜２Ｎのコピー処理が完了したか否かを判定する（ステップＣ６３）。
条件１：Ｌｓｅｑ（１）、・・・、Ｌｓｅｑ（Ｉ−１）の値がＬｓｅｑ（Ｉ）に等しいこと
条件２：Ｌｓｅｑ（Ｉ＋１）、・・・、Ｌｓｅｑ（Ｎ）の値がＬｓｅｑ（Ｉ）−１に等しいこと。

上記の２条件のいずれも充足された場合（ステップＣ６４のＹｅｓ）、アプリケーションバッファの全ての領域へのコピー処理が完了したと判定される（ステップＣ６５）。一方、それ以外の場合（ステップＣ６４のＮｏ）には、バッファコピーが完了していない領域があるため、完了していない領域の通知が送られてくるまで待機する。

以上の動作により、アプリケーションバッファ６の全ての領域へのコピーが完了（Ｃｏｍｐｌｅｔｉｏｎ）したかについて判定することができる。また、本実施形態により、アウトオブオーダーデータ到着後のインオーダーデータが、アウトオブオーダーデータと重なりを生じている場合でも、正確に完了の判定を行うことができる。

（実施形態４）
次に、第４の実施形態について説明する。第３の実施形態では、ＴＣＰのバッファコピーの振り分け方式がラウンドロビンであったため、完了判定を行うための各ＴＣＰバッファコピー部２１〜２Ｎに対応するリンクシーケンス番号の期待値を予め知ることができた。しかし、バッファコピーの振り分け方式が、ラウンドロビンではなく任意である場合、又は、アプリケーションバッファ６の末尾の領域に対するバッファコピー要求が振り分けの周回の途中のブロックに対するものである場合には、従来の方式では、完了判定時の各ＴＣＰバッファコピー部に対応するリンクシーケンス番号の期待値を知ることができない。

そこで、本実施形態では、ＴＣＰプロトコル処理部１３が、アプリケーションバッファ６の末尾に当たるデータを送信した後、最後の周回において、まだ振り分けていない振り分け先に対してダミーの要求を送信する。これによって、完了判定時に全てのＴＣＰバッファコピー部に対応するリンクシーケンス番号の期待値が同一となることを保証する。したがって、ソケット処理部３は、全ての振り分け先に対応するリンクシーケンス番号が最後の周のリンクシーケンス番号に一致するのを判定するだけで、振り分け方式によらず、コピー処理が完了したか否かを判定することができる。

第４の実施形態の構成は第３の実施形態の構成（図９）と同一であるため、説明を省略する。

次に、第４の実施形態の動作について説明する。第４の実施形態のＴＣＰプロトコル処理部１３の動作は、第３の実施形態の動作のうち、バッファコピー要求先を決定する工程（ステップＤ４）及びバッファコピー要求先のイベントキューにバッファコピー要求を追加する工程（ステップＤ５）が異なる。図１１は、これらのステップＤ４、Ｄ５において変更された内容を示す。バッファコピー要求先の決定時は、第３の実施形態におけるラウンドロビンによる決定とは異なり、イベントキュー７２１〜７２Ｎの残量を取得して（ステップＤ４１）、その残量が最も少ないイベントキューに対応するＴＣＰバッファコピー部を振り分け先として決定する（ステップＤ４２）。振り分け先に対応するイベントキューにバッファコピー要求を追加する（ステップＤ５１）。ここでは、イベントキューの残量に基づいて、負荷が最も低いブロックを振り分け先として決定しているが、別の方式であってもよい。しかし、別の方式を採用する際は、振り分けの周回において、同じブロックに対して複数回振り分けてはならないという制約がある。したがって、一旦振り分けを実施した振り分け先は、他の全ての振り分け先に対して要求を出すまで、振り分け先として設定することができない。

次に、ＴＣＰプロトコル処理部１３は、バッファコピー要求を行うパケットに該当するｒｃｖ＿ｎｘｔの値がアプリケーションバッファ６の末尾に相当するか判定する（ステップＤ５２）。末尾である場合（ステップＤ５２のＹｅｓ）、該当バッファコピー要求の通知後、まだ振り分けていない全ての振り分け先に対してダミーのバッファコピー要求を作成して対応するイベントキューに追加する。このダミーのバッファコピー要求は、コピー処理を実施しない要求であって、全ての振り分け先に対して同一のリンクシーケンス番号を通知するために実施される。以上が、本実施形態におけるＴＣＰプロトコル処理部１３の動作である。

次に、ソケット処理部３のアプリケーションバッファ６が埋まったことを判定する工程について説明する。第３の実施形態と異なる点は、点線で囲まれたステップＣ６３’Ｃ６４’である。第３の実施形態と異なり、第４の実施形態では、ダミーの要求も含めて全ての振り分け先に対してバッファコピー処理要求が通知されている。したがって、ソケット処理部３は、全ての領域に対するバッファコピー処理完了の判定条件としてＮ個のＴＣＰバッファコピー部に対応する全てのリンクシーケンス番号が一致しているか否かを判定するだけでよい（ステップＣ６３’）。判定結果が真である場合（ステップＣ６４’のＹｅｓ）、アプリケーションバッファ６のデータが全て埋められたものと判定する（ステップＣ６５）。一方、それ以外の場合（ステップＣ６４’のＮｏ）には、まだ処理が終わっていないブロックがあるものと判定し、残りのブロックの通知が送られてくるまで待機する。

本実施形態によって、ラウンドロビン以外の振り分け方式であっても、アプリケーションバッファ６が埋められたか否かの判定を行うことができる。

次に、具体的な実施例を用いて、本発明の第１の実施形態の動作を説明する。図１を参照して説明する。対向ホストから送出されたＭ個のパケットが途中の通信経路において順序の入れ替えや廃棄がされることなく、ＴＣＰ受信処理部１に到着したものとする。その際、パケットデータはネットワークインタフェース部１１によって受信パケットバッファ５に書き込まれる。また、パケットデータはパケット処理部１２によってチェックサムの確認が行われるとともにセッション検索によってＭ個のパケットが同一のセッションであると認識される。さらに、ＴＣＰプロトコル処理部１３によってＭ個のパケットはインオーダーデータと認識されてインオーダーキュー５１に追加される。そして、ＴＣＰプロトコル処理部１３の処理の結果、Ｍ個のパケット５１１〜５１Ｍのコピー先は６１〜６Ｍと決定され、そのバッファコピー処理は１個目のパケットがＴＣＰバッファコピー部２１、２個目はＴＣＰバッファコピー部２２、Ｍ個目はＴＣＰバッファコピー部２Ｍ（ただし、Ｍ＞Ｎの場合）というようにラウンドロビンによって、バッファコピー先が振り分けられる。

これによって、インオーダーキュー５１に格納されたＭ個のパケット５１１〜５１Ｍが、それぞれアプリケーションバッファ６の６１〜６Ｍに並列にコピーされる。

従来であれば、１個目のパケット５１１のパケットが６１にコピーされるのを待って、５１２のパケットのコピー処理が開始されていた。しかし、本実施形態では、５１１のパケットのコピーの完了を待たずにパケット５１２のコピー処理を開始することによって、バッファコピーの際に要するメモリアクセス以外の処理時間を短縮し、トータルの処理時間を削減することができる。

次に、具体的な実施例に基づいて、第２の実施形態の動作について説明する。以下では、図６を参照しつつ説明する。対向ホストから送出されたＭ個のパケットが途中の通信経路において順序の入れ替えや廃棄がされることなく、ＴＣＰ受信処理部１に到着し、続いて通信経路でデータシーケンスが飛んだ２個のパケットが到着したとする。その際、Ｍ＋２個のパケットは、ＴＣＰプロトコル処理部１３により処理され、Ｍ個のパケットがインオーダーデータと認識されてインオーダーキュー５１にパケット５１１〜５１Ｍとして追加され、後続の２個のパケットはアウトオブオーダーデータと認識されてアウトオブオーダーキュー５２にパケット５２１、５２２として追加される。

第１の実施形態においては、アウトオブオーダーキュー５２に格納されたパケットデータ５２１、５２２はインオーダーキューに格納されたパケットデータとアウトオブオーダーデータとの間を埋めるインオーダーデータが到着するまでバッファコピーされずアウトオブオーダーキュー５２に保持される。間を埋めるインオーダーデータが到着した時点で、パケット５２１、５２２はアウトオブオーダーキュー５２からインオーダーキュー５１に追加され、ＴＣＰバッファコピー部２１〜２Ｎによりコピー処理が実施される。

一方、第２の実施形態では、アウトオブオーダーパケット５２１のデータシーケンスがアプリケーションバッファ６のコピー範囲内部であれば、アウトオブオーダーパケット５２１がインオーダーキュー５１によってＴＣＰセグメントが再構築可能となるのを待たずに、ＴＣＰバッファコピー部２１〜２Ｎによって、アウトオブオーダーキュー５２１からアプリケーションバッファ６の６Ｋの領域に対してバッファコピーされる。

これらのバッファコピー処理は、第１の実施形態と同様に複数のＴＣＰバッファコピー部２１〜２Ｎにバッファコピー要求が振り分けられることによって並列に実施される。したがって、インオーダーキュー５１に格納されているＭ個のパケット５１１〜５１Ｍ及びアウトオブオーダーキューに格納されているパケット５２１は、それぞれアプリケーションバッファ６の領域６１〜６Ｍ及び６Ｋ（Ｍ＜Ｋ）に並列にコピーされる。

従来であればアウトオブオーダーデータがインオーダーデータによりストリームとして再構築可能になった場合に、一個のパケット処理時間のタイムスロットにおいて、インオーダーデータとあわせてアウトオブオーダーデータのコピー処理も要求される。したがって、バッファコピー要求が特定の時間に集中し性能が低下するという問題があった。しかし、本実施形態ではアウトオブオーダーデータがコピー可能であれば、アプリケーションバッファ６にコピーしてしまうことによって、バッファコピー要求を均一化して性能の低下を回避することができる。

次に、具体的な実施例を用いて、本発明の第３の実施形態の動作について説明する。図９を参照して、説明する。ＴＣＰプロトコル処理部１３は、バッファコピー要求を送出する際、ラウンドロビンで振り分け先を決定する。その際ラウンドロビン振り分けの１周目はＴＣＰバッファコピー部２１〜２Ｎに対してリンクシーケンス番号を１、１、１、・・・というように同一の番号を振り分け、２周目はＴＣＰバッファコピー部２１〜２Ｎに対してリンクシーケンス番号を２、２、２、・・・というように振り分ける。また、リンクシーケンス番号と併せて該当パケット処理後のＴＣＰパラメータｒｃｖ＿ｎｘｔの値を付与する。

ＴＣＰバッファコピー部２１〜２Ｎは第１、第２の実施形態と同様に、バッファコピー処理を実施後、リンクシーケンス番号とｒｃｖ＿ｎｘｔの値を付与したバッファコピー完了通知をソケット処理部３に送付する。

ソケット処理部３は、バッファコピー完了通知に付与されたｒｃｖ＿ｎｘｔの値を参照し、該当する領域に対するｒｃｖ＿ｎｘｔの値がアプリケーションバッファ６の末尾であるか否かを判定する。ｒｃｖ＿ｎｘｔの値が末尾である場合、その完了通知に付与されたリンクシーケンス番号Ｌｓｅｑ（Ｉ）に対して以下の２条件に基づく判定を行う。
条件１：Ｌｓｅｑ（１）、・・・、Ｌｓｅｑ（Ｉ−１）＝＝Ｌｓｅｑ（Ｉ）
条件２：Ｌｓｅｑ（Ｉ＋１）、・・・、Ｌｓｅｑ（Ｎ）＝＝Ｌｓｅｑ（Ｉ）−１

ここで具体的な事例を考える。並列度Ｎ＝５、アプリケーションバッファ６の末尾に相当した時のブロック番号Ｉ＝３、Ｌｓｅｑ（Ｉ）＝１０とする。このとき、先に通知されたバッファコピー処理が全て完了済みであるとすると、ブロック番号１、２、３がラウンドロビンの最後の周であり、ブロック番号４、５が一つ前の周であると期待される。よって、以下の２条件によって、先に通知されたバッファコピー処理が完了済みであるかを判定する。
条件１：Ｌｓｅｑ（１）＝Ｌｓｅｑ（２）＝Ｌｓｅｑ（３）＝１０
条件２：Ｌｓｅｑ（４）＝Ｌｓｅｑ（５）＝９

この条件が満たされた場合、アプリケーションバッファ６が全て埋められたものと判定する。満たされていない場合には、先に要求が発行されたバッファコピー処理がまだ完了していないため、完了するまで待機する。

従来は、バッファコピー処理が完了したデータ長を積算することでアプリケーションバッファ６が埋められたかを判定していた。しかし、本実施形態では、ｒｃｖ＿ｎｘｔを参照して判定することによって、従来の実施形態では判定することができなかったアウトオブオーダーパケットの重なりが発生した場合であっても、正しくアプリケーションバッファ６が埋められたことを判定することができる。

次に、本発明の第４の実施形態の動作について説明する。第３の実施形態では、バッファコピー処理の振り分け先をラウンドロビンで決定していた。本実施形態は、振り分け先のイベントキュー７２１〜７２Ｎの深さを参照し、最もエントリが少ないキューを振り分け先として動的に決定する。また、本実施形態では、周回ごとに必ず全てのブロックに振り分ける必要がある。また、同一のブロックに同一周回で複数回振り分けるのは認められない。振り分け先の決定後、バッファコピー要求を送出する。このバッファコピー要求が、アプリケーションバッファ６の末尾に相当するデータのものである場合、まだその周回で振り分けていない全てのブロックに対してダミーのバッファコピー要求を送付する。この要求はバッファコピー処理を行わない要求であって、全てのブロックに同一のリンクシーケンス番号を送付するために行われる。

また、ソケット処理部３における、アプリケーションバッファ６のバッファコピー処理の完了の判定は、次のように行われる。すなわち、並列度Ｎ＝５、アプリケーションバッファ６の末尾に相当した時のブロック番号をＩ＝３、Ｌｓｅｑ（Ｉ）＝１０とした場合、以下の条件に基づいて判定される。
条件：Ｌｓｅｑ（１）＝Ｌｓｅｑ（２）＝・・・＝Ｌｓｅｑ（５）＝１０

この条件が充足された場合、アプリケーションバッファ６が全て埋められたものと判定する。充足されない場合、先に要求が発行されたバッファコピー処理がまだ完了していないため、完了するまで待機する。

本実施形態の動作によって、振り分け方式がラウンドロビンでない方式においても、バッファコピー処理が全て完了したか否かを判定することができる。したがって、振り分け方式が静的ではないもの、例えばイベントキューの深さが低く負荷の低いブロックに対して動的に割り当てていく方式であっても、並列にバッファコピー処理を実現することができる。

以上の記載は実施例に基づいて行ったが、本発明は、上記実施例に限定されるものではない。

本発明の第１の実施形態の構成を示すブロック図である。 本発明の第１の実施形態の全体受信処理を示す流れ図である。 本発明の第１の実施形態のＴＣＰ受信プロトコル処理を示す流れ図である。 本発明の第１の実施形態の並列バッファコピー処理を示す流れ図である。 本発明の第１の実施形態のインオーダーキュー及びアウトオブオーダーキューの構造を示すブロック図である。 本発明の第２の実施形態の構成を示すブロック図である。 本発明の第２の実施形態のバッファコピー並列要求処理を示す流れ図である。 ＴＣＰパケットの到着時のデータの状態及びＴＣＰパラメータの変化についての説明図である。 本発明の第３の実施形態の構成を示すブロック図である。 本発明の第３の実施形態のバッファコピー要求生成処理を示す流れ図である。 本発明の第４の実施形態のＥｖｅｎｔキュー処理を示す流れ図である。

符号の説明

１ ＴＣＰ受信処理部
２、２１〜２Ｎ ＴＣＰバッファコピー部
３ ソケット処理部
４ アプリケーション部
５ 受信パケットバッファ
６ アプリケーションバッファ
８ データ再構築情報管理部
１０、２０、３０ ＴＣＰバッファコピー分散並列処理装置
１１ ネットワークインタフェース部
１２ パケット処理部
１３ ＴＣＰプロトコル処理部
５１ インオーダーキュー
５２ アウトオブオーダーキュー
６１〜６Ｍ、６Ｋ アプリケーションバッファのコピー先領域
７１、７２１〜７２Ｎ、７３ Ｅｖｅｎｔキュー
８１ ｒｃｖ＿ｎｘｔ管理部
５１１〜５１Ｍ インオーダーキューに格納済みのパケットデータ
５２１、５２２ アウトオブオーダーキューに格納済みのパケットデータ
８２１〜８２Ｎ リンクシーケンス保持部
Ｇ１ インオーダーキューの有効エントリのアドレス
Ｇ２ インオーダーキューの有効エントリ
Ｇ３ アウトオブオーダーキューの有効エントリ
Ｇ２１ インオーダーキューの次エントリの開始アドレス
Ｇ２２ インオーダーキューのヘッダアドレス
Ｇ２３ インオーダーキューのデータアドレス
Ｇ２４ インオーダーキューの有効データのアドレス
Ｇ２５ インオーダーキューの有効データ長
Ｇ２６ インオーダーキューに格納されているヘッダデータ
Ｇ２７ インオーダーキューに格納されているパケットデータ
Ｇ３１ アウトオブオーダーキューの次エントリの開始アドレス
Ｇ３２ アウトオブオーダーキューのヘッダアドレス
Ｇ３３ アウトオブオーダーキューのデータアドレス
Ｇ３４ アウトオブオーダーキューの有効データのアドレス
Ｇ３５ アウトオブオーダーキューの有効データ長
Ｇ３６ アウトオブオーダーキューに格納されているヘッダデータ
Ｇ３７ アウトオブオーダーキューに格納されているパケットデータ

Claims (13)

1. ＴＣＰ受信処理部と、
   １又は２以上のＴＣＰバッファコピー部と、
   ソケット処理部と、
   受信パケットバッファと、
   アプリケーションバッファと、を備えるＴＣＰバッファコピー分散並列処理装置であって、
   前記受信パケットバッファ及びアプリケーションバッファは、前記ＴＣＰ受信処理部、ＴＣＰバッファコピー部及びソケット処理部からアクセス可能な記憶領域として構成され、
   前記ＴＣＰ受信処理部は、パケットの受信処理とＴＣＰプロトコル処理とを実施し、
   受信パケットが対向ホストによって送信された順序と同一の順序で到着した（インオーダー、Ｉｎ−Ｏｒｄｅｒ）と判定した場合には、該受信パケットを前記受信パケットバッファに設けたインオーダーキューに格納し、該受信パケットのＴＣＰシーケンス番号に基づいて前記アプリケーションバッファにおけるコピー先の領域を決定し、該受信パケットを前記受信パケットバッファから前記アプリケーションバッファにコピーするバッファコピー要求を生成し、前記ＴＣＰバッファコピー部のいずれかを選択して該バッファコピー要求を通知することによって受信パケットのバッファコピーを分散並列処理させるように構成され、
   受信パケットが対向ホストによって送信された順序と異なる順序で到着した（アウトオブオーダー、Ｏｕｔ−ｏｆ−Ｏｒｄｅｒ）と判定した場合には、該受信パケットを前記受信パケットバッファに設けたアウトオブオーダーキューに格納するように構成されたことを特徴とするＴＣＰバッファコピー分散並列処理装置。
2. 前記ＴＣＰ受信処理部は、アウトオブオーダーと判定した受信パケットの前記アプリケーションバッファにおけるコピー先が前記アプリケーションバッファに設けたコピー先領域に含まれる場合に限って、前記バッファコピー要求を生成し、前記ＴＣＰバッファコピー部のいずれかを選択して前記バッファコピー要求を通知することによって受信パケットのバッファコピーを分散並列処理させるように構成されたことを特徴とする、請求項１に記載のＴＣＰバッファコピー分散並列処理装置。
3. 前記ＴＣＰ受信処理部、ＴＣＰバッファコピー部及びソケット処理部はいずれもイベントキューを備え、
   要求送出側は要求受信側に設けたイベントキューに要求を追加することで要求を通知するように構成され、
   要求受信側は自身に設けたイベントキューをポーリングしてイベントキューに要求が追加されている場合にはその要求を取り出して処理を行うように構成され、
   前記ＴＣＰ受信処理部、ＴＣＰバッファコピー部及びソケット処理部は、それぞれ非同期動作を行うように構成されたことを特徴とする、請求項１又は２に記載のＴＣＰバッファコピー分散並列処理装置。
4. 前記ＴＣＰ受信処理部は、前記バッファコピー要求の通知先を前記ＴＣＰバッファコピー部の中からラウンドロビン（Ｒｏｕｎｄ Ｒｏｂｉｎ）によって選択するように構成されたことを特徴とする、請求項１ないし３のいずれか一に記載のＴＣＰバッファコピー分散並列処理装置。
5. 前記ＴＣＰバッファコピー部は、バッファコピー処理を完了した場合には、コピーを実施したデータ長を含むバッファコピー完了通知を前記ソケット処理部に通知するように構成され、
   前記アプリケーションバッファは、アドレスｂａｄｄｒから始まる長さｂｌｅｎの領域をコピー先領域として備え、
   前記ソケット処理部は、前記バッファコピー完了通知に含まれるコピーを実施したデータ長を積算し、積算された値が前記アプリケーションバッファにおけるコピー先領域の長さｂｌｅｎに達したか否かに基づいて前記アプリケーションバッファの全ての領域に対するコピー要求が通知されたか否かを判定するように構成されたことを特徴とする、請求項１ないし４のいずれか一に記載のＴＣＰバッファコピー分散並列処理装置。
6. 前記ＴＣＰバッファコピー部は、バッファコピー処理を完了した場合には、コピーを実施したデータ長とＴＣＰ受信処理部から通知された受信パケットのＴＣＰプロトコル処理後のＴＣＰパラメータｒｃｖ＿ｎｘｔとを含むバッファコピー完了通知を前記ソケット処理部に通知するように構成され、
   前記アプリケーションバッファは、アドレスｂａｄｄｒから始まる長さｂｌｅｎの領域をコピー先領域として備え、
   前記ソケット処理部は、前記バッファコピー完了通知に含まれるＴＣＰパラメータｒｃｖ＿ｎｘｔを参照し、その値に基づいて前記アプリケーションバッファの全ての領域に対するコピー要求が通知されたか否かを判定するように構成されたことを特徴とする、請求項１ないし４のいずれか一に記載のＴＣＰバッファコピー分散並列処理装置。
7. 前記ＴＣＰバッファコピー部のうちＩ番目（１≦Ｉ≦Ｎ）のものから前記ソケット処理部に通知された前記バッファコピー完了通知は、振り分けの周回回数を示すリンクシーケンス（Ｌｉｎｋ Ｓｅｑｕｅｎｃｅ）番号Ｌｓｅｑ（Ｉ）を含み、
   前記ソケット処理部は、前記アプリケーションバッファの全ての領域に対するコピー要求が通知されたと判定し、かつ、判定に用いられたバッファコピー完了通知がラウンドロビンによる振り分けのうちＩ番目である場合には、以下の２条件
   （ａ）Ｌｓｅｑ（１）、・・・、Ｌｓｅｑ（Ｉ−１）＝＝Ｌｓｅｑ（Ｉ）、
   （ｂ）Ｌｓｅｑ（Ｉ＋１）、・・・、Ｌｓｅｑ（Ｎ）＝＝Ｌｓｅｑ（Ｉ）−１
   が満たされたとき、前記ＴＣＰバッファコピー部のすべてのバッファコピー処理が完了したものと判定するように構成されたことを特徴とする、請求項５又は６に記載のＴＣＰバッファコピー分散並列処理装置。
8. 前記ＴＣＰプロトコル処理部は、前記ＴＣＰバッファコピー部に備えたイベントキューの残量を参照し、前記ＴＣＰバッファコピー部の中からイベントキューの残量がより少ないものを前記バッファコピー要求の通知先として動的に選択するように構成されたことを特徴とする、請求項３に記載のＴＣＰバッファコピー分散並列処理装置。
9. 前記ＴＣＰバッファコピー部は、バッファコピー処理を完了した場合には、コピーを実施したデータ長を含むバッファコピー完了通知を前記ソケット処理部に通知し、
   前記アプリケーションバッファは、アドレスｂａｄｄｒから始まる長さｂｌｅｎの領域をコピー先領域として備え、
   前記ソケット処理部は、前記バッファコピー完了通知に含まれるコピーを実施したデータ長を積算し、積算された値が前記アプリケーションバッファにおけるコピー先領域の長さｂｌｅｎに達したか否かに基づいて前記アプリケーションバッファの全ての領域に対するコピー要求が通知されたか否かを判定するように構成されたことを特徴とする、請求項８に記載のＴＣＰバッファコピー分散並列処理装置。
10. 前記ＴＣＰバッファコピー部は、バッファコピー処理を完了した場合には、コピーを実施したデータ長とＴＣＰ受信処理部から通知された受信パケットのＴＣＰプロトコル処理後のＴＣＰパラメータｒｃｖ＿ｎｘｔとを含むバッファコピー完了通知を前記ソケット処理部に通知するように構成され、
    前記アプリケーションバッファは、アドレスｂａｄｄｒから始まる長さｂｌｅｎの領域をコピー領域として備え、
    前記ソケット処理部は、前記バッファコピー完了通知に含まれるＴＣＰパラメータｒｃｖ＿ｎｘｔを参照し、その値に基づいて前記アプリケーションバッファの全ての領域に対するコピー要求が通知されたか否かを判定するように構成されたことを特徴とする、請求項８に記載のＴＣＰバッファコピー分散並列処理装置。
11. 前記ＴＣＰ受信処理部は、送出するバッファコピー要求が前記アプリケーションバッファのデータを埋める最後のデータを含むか否かをＴＣＰパラメータｒｃｖ＿ｎｘｔに基づいて判定し、前記アプリケーションバッファのデータを埋める最後のデータを含むものと判定した場合には、該バッファコピー要求の通知後、同一の振り分け周回においてまだ要求を通知していない全てのＴＣＰバッファコピー部に対してその周回のリンクシーケンス番号を含むダミーのバッファコピー要求を送出するように構成され、
    前記ＴＣＰバッファコピー部は、それぞれバッファコピー完了通知を前記ソケット処理部に通知し、
    前記ＴＣＰバッファコピー部のうちＩ番目（１≦Ｉ≦Ｎ）のものから前記ソケット処理部に通知された前記バッファコピー完了通知は、振り分けの周回回数を示すリンクシーケンス番号Ｌｓｅｑ（Ｉ）（１≦Ｉ≦Ｎ）を含み、
    前記ソケット処理部は、前記バッファコピー完了通知に基づいて前記アプリケーションバッファの全ての領域へパケットデータコピーされたか否かを判定し、前記アプリケーションバッファの全ての領域に対するコピー要求が通知されたと判定し、かつ、前記ＴＣＰバッファコピー部から通知されたバッファコピー完了通知のリンクシーケンス番号がいずれも等しい場合には、前記ＴＣＰバッファコピー部のバッファコピー処理が完了したと判定するように構成されたことを特徴とする、請求項９又は１０に記載のＴＣＰバッファコピー分散並列処理装置。
12. ＴＣＰバッファコピー分散並列処理装置によって、受信パケットに対するＴＣＰプロトコル処理を実施する工程と、
    前記受信パケットが対向ホストによって送信された順序と同一の順序で到着した（インオーダー、Ｉｎ−Ｏｒｄｅｒ）か否かを判定する工程と、を含むＴＣＰバッファコピー分散並列処理方法であって、
    インオーダーと判定された場合には、前記受信パケットを受信パケットバッファに設けたインオーダーキューに格納する工程と、
    前記受信パケットのＴＣＰシーケンス番号に基づいてアプリケーションバッファにおけるコピー先の領域を決定する工程と、
    前記受信パケットを前記受信パケットバッファから前記アプリケーションバッファにコピーするバッファコピー要求を生成する工程と、
    １又は２以上のＴＣＰバッファコピー部のいずれかを選択して前記バッファコピー要求を通知することによって前記受信パケットのバッファコピーを分散並列処理させる工程と、を含み、
    前記受信パケットが対向ホストによって送信された順序と異なる順序で到着した（アウトオブオーダー、Ｏｕｔ−ｏｆ−Ｏｒｄｅｒ）と判定された場合には、前記受信パケットを前記受信パケットバッファに設けたアウトオブオーダーキューに格納する工程を含むことを特徴とするＴＣＰバッファコピー分散並列処理方法。
13. コンピュータによって、受信パケットに対するＴＣＰプロトコル処理と、
    前記受信パケットが対向ホストによって送信された順序と同一の順序で到着した（インオーダー、Ｉｎ−Ｏｒｄｅｒ）か否かを判定する処理と、を実行させるＴＣＰバッファコピー分散並列処理プログラムであって、
    インオーダーと判定された場合には、前記受信パケットを受信パケットバッファに設けたインオーダーキューに格納する処理と、
    前記受信パケットのＴＣＰシーケンス番号に基づいてアプリケーションバッファにおけるコピー先の領域を決定する処理と、
    前記受信パケットを前記受信パケットバッファから前記アプリケーションバッファにコピーするバッファコピー要求を生成する処理と、
    １又は２以上のＴＣＰバッファコピー部のいずれかを選択して前記バッファコピー要求を通知することによって前記受信パケットのバッファコピーを分散並列処理させる処理と、をコンピュータに実行させ、
    前記受信パケットが対向ホストによって送信された順序と異なる順序で到着した（アウトオブオーダー、Ｏｕｔ−ｏｆ−Ｏｒｄｅｒ）と判定された場合には、前記受信パケットを前記受信パケットバッファに設けたアウトオブオーダーキューに格納する処理をコンピュータに実行させることを特徴とするＴＣＰバッファコピー分散並列処理プログラム。

Images