JP2015204466A - データ転送装置、データ転送方法および通信装置 - Google Patents

Abstract

【課題】各セッションに対してネットワークの帯域をできるだけ均等に割り当てることを目的とする。
【解決手段】本発明の実施形態としてのデータ転送装置は、複数の対向機器と、ネットワークを介して通信するデータ転送装置であって、セッション管理部と通信処理部とを備える。前記セッション管理部は、前記複数の対向機器に対して生成された複数のセッションを順次、循環的に選択する。前記通信処理部は、前記セッション間で各回の送信処理で送信するデータ量のばらつきを抑制するように、前記セッション管理部で選択されたセッションに関連する対向機器に対してデータの送信処理を行う。
【選択図】図１

Description

本発明の実施形態は、データ転送装置、データ転送方法および通信装置に関する。

サーバ装置および端末装置に搭載される通信装置では、一般的に、ＭＡＣ層および物理層のプロトコルとして、イーサネット（登録商標）やＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃなどが使用される。より上位層のプロトコルには、ＴＣＰ／ＩＰやＵＤＰ／ＩＰなどが使われるのが一般的である。ＴＣＰ／ＩＰやＵＤＰ／ＩＰは、インターネット等で広く使われている。イーサネットは現在１Ｇｂｐｓが主流であり、データセンター等では１０Ｇｂｐｓが使われ始めている。また、次世代の４０Ｇｂｐｓ／１００Ｇｂｐｓイーサネットの仕様策定も完了している。ＩＥＥＥ ８０２．１１においても、数１００Ｍｂｐｓ〜数Ｇｂｐｓの利用が、今後着実に普及していくと思われる。

このような高速ネットワークの普及に伴い、それを制御するホストＣＰＵの処理負荷も増大していく。ホストＣＰＵの処理負荷を低減するため、ＴＣＰ／ＩＰオフロードエンジン（以下、ＴＯＥ）などの専用ハードウェアが用いられてきた。ＴＯＥは、ホストＣＰＵに代行して、前述のＴＣＰ／ＩＰの処理を行う専用プロセッサまたは専用回路を備えた装置であり、ホストＣＰＵからＴＣＰ／ＩＰ処理の負荷をオフロードするものである。このＴＯＥを用いることによって、従来のソフトウェアによるプロトコル処理よりも、高速にＴＣＰ／ＩＰ処理を行う事が可能となる。

一般的なＴＯＥを用いた送信処理では、ホストＣＰＵなどが、送信するデータを送信キューに書き込み、ＴＯＥが送信キューからデータを読み出してヘッダ生成等の処理を行い、ネットワークへ送信を行う。この時、ＴＯＥは送信キューへ書き込まれた順にデータを処理する事になる。

このようなＴＯＥを搭載したサーバ装置では、数万規模のＴＣＰのセッションが同時に接続される事が想定され、各セッションを均等に処理する能力が求められる。しかし、従来技術ではホスト側のタスクスケジューリングの結果によっては、同一セッションのデータが送信キューに連続して書き込まれ、同一セッションでフレームがバースト的に送信されてしまう可能性がある。

特開２０１３−４６１７３号公報

本発明の実施形態は、各セッションに対してネットワークの帯域をできるだけ均等に割り当てることを目的とする。

本発明の実施形態としてのデータ転送装置は、複数の対向機器と、ネットワークを介して通信するデータ転送装置であって、セッション管理部と通信処理部とを備える。

前記セッション管理部は、前記複数の対向機器に対して生成された複数のセッションを順次、循環的に選択する。

前記通信処理部は、前記セッション間で各回の送信処理で送信するデータ量のばらつきを抑制するように、前記セッション管理部で選択されたセッションに関連する対向機器に対してデータの送信処理を行う。

第１の実施形態に係るデータ転送装置を備えた通信装置を示すブロック図。 第１の実施形態に係るセッションの状態遷移図。 第１の実施形態の動作を示すフローチャート。 第２の実施形態に係るデータ転送装置を備えた通信装置を示すブロック図。 第２の実施形態に係るセッションの状態遷移図。 第２の実施形態の動作を示すフローチャート。 第３の実施形態に係るデータ転送装置を備えた通信装置を示すブロック図。 第３の実施形態に係るセッションの状態遷移図。 第３の実施形態の動作を示すフローチャート。

以下、図面を参照しながら、本発明の実施形態について説明する。

（第１の実施形態）
図１は、第１の実施形態に係るデータ転送装置を備えた通信装置を示すブロック図である。図における矢印付きの実線は、ネットワークへ送信するデータの流れを示し、矢印付きの破線は制御、またはネットワークへ送信するデータ以外の情報の流れを示す。

図１に示す通信装置１００は、ネットワーク２０１を介して、１つまたは複数の対向機器３０１と接続される。ネットワーク２０１は、無線ネットワーク、有線ネットワーク、またはこれらのハイブリッドのネットワークであり、一例として、インターネットである。

通信装置１００は、各対向機器３０１に対し、ＴＣＰ等の通信プロトコルに従ってセッションを生成し、生成したセッションに基づき通信する。この通信装置は、一例として、対向機器３０１の要求に応じて画像、音声、動画、テキストなどのデータを供給するサーバ装置である。通信装置の形態は、これに限定されず、対向機器３０１に対しセッションを生成して通信を行う装置であれば、スマートフォン、ＰＣ、タブレット、携帯端末などのユーザ端末でもよい。具体的な製品形態としては、これらのサーバ装置やＰＣ等の他、専用ＬＳＩ、またはＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）等の形態も可能であるが、これらに限定されるものではない。

各対向機器３０１は、スマートフォン、ＰＣ、タブレット、携帯端末、などのユーザ端末でもよいし、家庭内の家電装置などでもよい。通信装置１００とセッションを生成して、通信装置からデータの供給を受ける装置であれば、どのような装置でもかまわない。

図１の通信装置は、データ転送装置１０１と、ホストＣＰＵ（プロセッサ）１０２と、記憶装置１０３と、送信バッファ１０４を備えている。ホストＣＰＵ１０２は、セッション毎に、送信するデータを記憶装置１０３から読み出して送信バッファ１０４へ書き込むよう制御する。また、ホストＣＰＵ１０２は、各セッションについて、対向機器とのコネクションの確立・切断を制御する。データ転送装置１０１は、ホストＣＰＵ１０２でコネクションが確立されている各セッションについて、各セッションを循環的に選択し、選択したセッションに対して送信処理を行うことを繰り返す。送信処理では、セッションを生成した対向機器に対してデータを送信する。データ転送装置１０１は、セッション間で、各回の送信処理で送信するデータ量のばらつきを抑制するようにデータを送信する。これにより、各セッションに均等に送信の機会を与え、ネットワークの帯域をできるだけ均等に使用させる。

記憶装置１０３には、送信用のデータを格納している。記憶装置１０３の具体的な実装形態は、例えばＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）やＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＤカード、ＳＤＲＡＭ等が想定されるがその限りではない。

送信バッファ１０４は、一時的にデータを保持するための記憶領域である。送信バッファ１０４には、セッション毎に使用する領域が予め割り当てられていてもよい。送信バッファ１０４は、記憶装置１０３上に配置されてもよいし、メインメモリなど別の装置上に配置されてもよい。また、後述のデータ転送装置１０１内に配置してもよい。

ホストＣＰＵ１０２は、通信装置１００全体の制御を行う。ホストＣＰＵ１０２は、ソフトウェアで実現される主な処理部として、アプリケーション部２１と、コネクション処理部２２と、書き込み制御部２３とを備える。アプリケーション部２１は、データ送信アプリケーションを実行する処理部である。

コネクション処理部２２は、使用する通信プロトコル（ここではＴＣＰ／ＩＰを想定）に応じて、対向機器３０１とのセッションを生成し、当該セッションで対向機器３０１と通信を行うためのコネクションを確立・切断する処理を行う。コネクション処理部２２は、生成したセッションに固有のＩＤを割り振る。このＩＤをセッションＩＤと呼ぶ。コネクション処理部２２は、コネクションを確立または切断するための制御パケットを、データ転送装置１０１の通信処理部１４を介して、対向機器３０１と送受信する。制御パケットの例として、ＳＹＮパケットやＦＩＮパケット、これらのパケットに付随して送受信するパケット等がある。

コネクション処理部２２は、コネクションを確立または切断すると、コネクションの確立または切断の通知を、データ転送装置１０１のセッション管理部１１に行う。この際、確立または切断の対象となったセッションＩＤを通知する。コネクションの確立の通知は、当該コネクションで最初に送信するデータが発生した時、または当該データを後述のデータ書込制御部２３の制御で送信バッファ１０４に書き込んだ時などに行うことがあり得る。

ここでＴＣＰ／ＩＰにおけるセッションとは、宛先ＩＰアドレス／発信元ＩＰアドレス／宛先ポート番号／発信元ポート番号の４つの情報で管理するコネクションを指す。セッションを生成するとは、これら４つの情報の組を生成することに相当する。ある１つのセッションは、コネクションが確立された状態、または確立されていない（切断された）状態を有する。ＴＣＰ／ＩＰは、セッション毎に、セッションに関連する対向機器と、送信処理および受信処理を行うものである。本実施形態に係るデータ転送装置１０１も、セッション毎に、セッションに関連する対向機器３０１と、送信処理および受信処理を行う。

書き込み制御部２３は、記憶装置１０３に格納されているデータを、送信バッファ１０４に書き込むための制御を行う。書き込み制御の方法は、装置構成に応じて、任意の方法を用いればよい。例えば、記憶装置１０３が内部にＤＭＡＣ（ダイレクトメモリアクセスコントローラ）（図示せず）を内蔵し、書き込み制御部２３が、ＤＭＡＣに指示信号を出力することで、ＤＭＡＣが送信バッファ１０４にデータ書き込みを行ってもよい。この場合、書き込み制御部２３が、ＤＭＡＣに、送信バッファ１０４における書き込みアドレスを指示すればよい。または、ホストＣＰＵ１０２自身が、記憶装置１０３からデータを読み出して、送信バッファ１０４に書き込んでもよい。あるいは、専用のハードウェアを用いて書き込み処理を行ってもよい。

なお、ホストＣＰＵ１０２は、上述した処理外にも、種々の処理を行う事が可能である。

データ転送装置１０１は、ホストＣＰＵ１０２に代行し、ＴＣＰ／ＩＰに従って、データの送信処理、および受信処理を行う。データ転送装置１０１は、セッション毎に、送信バッファ１０４に書き込まれたデータを読み出して、ＴＣＰ／ＩＰ等のプロトコル処理を行う。これにより、フレームを生成する。そして、生成したフレームをネットワーク２０１へ送出する。このようなデータ転送装置１０１は、セッション管理部１１、セッション情報記憶部１２、データ読み出し部１３、通信処理部１４を備える。データ転送装置１０１は、ハードウェアとソフトウェア（プログラム）のどちらで構成しても良く、これらの両方で構成されてもよい。

セッション管理部１１は、コネクション処理部２２からコネクション確立の通知を受けると、コネクション確立されたセッションのＩＤを登録する。また、コネクション切断の通知を受けると、コネクション切断されたセッションのＩＤを削除する。これにより、セッション管理部１１は、コネクション確立状態にあるセッションを内部で把握する。以下では、セッションＩＤを登録または削除することを、セッションを登録または削除と表現ンすることがある。

セッション管理部１１は、登録されているセッションＩＤに基づき、各セッションを循環的に順次選択し、選択したセッションについて、通信処理部１４に送信処理を行うことを指示する指示情報を出力する。循環的にセッションを選択する方法として、例えば、登録されているセッションＩＤをキューに保持しておき、先頭から順次セッションＩＤを読み出し、読み出したセッションＩＤを再度、キューの末尾に格納する方式を用いてもよい。キューは、データ転送装置１０１の内部または外部のバッファに格納しておく。

または、コネクション処理部２２で確立された各セッションのＩＤとコネクション状態（確立または切断）を保持したテーブルを、データ転送装置１０１の内部または外部のバッファに保持しておく。当該テーブルの各エントリを順次、循環的に確認して、コネクション確立状態にあるセッションを選択する方法などでもよい。この場合、セッション管理部１１にセッションが登録されているとは、テーブルにおいてセッションＩＤが登録され、コネクション状態が「確立」の状態を意味する。なお、ここで述べた方法以外で、セッションを選択する方法でもかまわない。

セッション情報記憶部１２は、セッション管理部１１で登録されている各セッションのセッション情報を記憶する。セッション情報は、前述したセッション（宛先ＩＰアドレス／発信元ＩＰアドレス／宛先ポート番号／発信元ポート番号）の値、および、ＴＣＰ／ＩＰヘッダを生成するために必要なその他の情報（シーケンス番号、確認応答番号（ＡＣＫシーケンス番号）等）を含む。また、ＭＳＳ（Ｍａｘｉｍｕｍ Ｓｅｇｍｅｎｔ Ｓｉｚｅ）をセッション情報に含めてもよい。ＭＳＳがすべてのセッションで共通であれば、別に管理してもよい。

また、セッション情報は、送信バッファ１０４のどの位置に、当該セッション用のデータが書き込まれているかを特定するためのバッファ情報も含む。バッファ情報は、送信バッファ１０４において、まだ送信されていないデータを格納しているアドレスを特定する情報を含む。例えば、バッファ情報は、送信バッファ１０４において読み出し済みのデータの末尾のアドレス（またはまだ読み出されていないデータの先頭アドレス）を指す読み出しポインタ、書き込みが完了したデータの末尾のアドレスを指す書き込みポインタとの組でもよい。これ以外の表現方法でバッファ情報を構成してもよい。

セッション情報記憶部１２は、データ転送装置１０１内に配置されてもよいし、データ転送装置１０１外（例えばメインメモリ等）に配置されてもよい。セッション情報は、セッション管理部１１へのセッションの登録（すなわちセッションＩＤの登録）時に、セッション情報記憶部１２に登録され、セッション管理部１１からセッションが削除される時に削除されてもよい。また、セッション情報記憶部１２内のセッション情報は、セッションに対応する送信処理が行われたとき、また、送信バッファ１０４にセッションに対応するデータが書き込まれたときになどに更新されてもよい。ここで述べたセッション情報の登録および削除、更新は、ホストＣＰＵ１０２またはデータ転送装置１０１が行い、どちらが行うように構成しても構わない。

例えばデータ転送装置１０１のセッション管理部１１が、セッションＩＤの登録時にセッション情報を生成して、セッション情報記憶部１２内にセッション情報を格納してもよい。セッション情報の生成に必要な情報は、ホストＣＰＵ１０２から取得すればよい。または、セッション管理部１１へのセッションの登録時に、ホストＣＰＵ１０２のコネクション処理部２２または別の処理部がセッション情報を生成して、セッション情報記憶部１２に格納してもよい。

また、データ転送装置１０１のセッション管理部１１が、セッションＩＤの削除時に、該当するセッション情報をセッション情報記憶部１２内から削除してもよい。または、セッション管理部１１からのセッションＩＤの削除時に、ホストＣＰＵ１０２のコネクション処理部２２または別の処理部が、セッション情報記憶部１２からセッション情報を削除してもよい。

また、ホストＣＰＵ１０２の書き込み制御部２３の制御により、送信バッファ１０４にデータを書き込んだときに、ホストＣＰＵ１０２またはデータ転送装置１０１が、該当するセッション情報（例えばセッション情報内のバッファ情報等）を更新してもよい。また、データ転送装置１０１の通信処理部１４が、送信処理を実行したときに、該当するセッション情報（バッファ情報、シーケンス番号等）を更新してもよい。

データ読み出し部１３は、通信処理部１４からデータの読み出し指示を受けて、送信バッファ１０４からデータを読み出す。データ読み出し部１３は、読み出したデータを通信処理部１４に送る。送信バッファ１０４における読み出しアドレスは、通信処理部１４が、セッション情報内のバッファ情報から算出して、通信処理部１４に通知する構成でもよいし、データ読み出し部１３が、当該バッファ情報から算出してもよい。または、バッファ情報は、セッション情報から分離して、データ読み出し部１３が管理するように構成してもよい。

通信処理部１４は、セッション管理部１１から循環的に指示される各セッションに対して、データの送信処理を行う。通信処理部１４は、当該セッションに対応するバッファ情報を確認することで、送信バッファ１０４における未送信のデータの位置およびサイズ等の情報を知る事ができる。よって、バッファ情報を元に、送信バッファ１０４からデータを読み出して、送信を実行できる。

具体的には、通信処理部１４は、セッション管理部１１から次に送信処理を行うセッションを指定されると、該当するセッション情報を取得して、セッション情報に含まれるシーケンス番号や確認応答番号、ポート番号等からＴＣＰ／ＩＰのヘッダを生成する。また、データ読み出し部１３に、当該セッションに対応するデータの読み出しを指示する。この際、セッション情報内のバッファ情報から読み出しアドレスを算出して、データ読み出し部１３へ通知してもよい。通信処理部１４は、データ読み出し部１３により読み出されたデータを取得し、取得したデータに、上述のヘッダや、別途計算したチェックサム等を結合してフレームを生成する。通信処理部１４は、生成したフレームをネットワーク２０１へ送出する。

また、通信処理部１４は、ここで述べたデータ送信以外にも、対向機器３０１からのデータ受信処理や、ＡＣＫパケット、ＦＩＮパケット、ＲＳＴパケット等の送受信処理を行う。なお、通信処理部１４は、前述した制御パケットをネットワーク２０１から受信した場合は、当該制御パケットの情報をホストＣＰＵ１０２に、メインメモリ等のメモリを介して渡す。また、通信処理部１４は、ホストＣＰＵ１０２から渡された情報に基づき、制御パケットを生成してネットワーク２０１に送信してもよい。制御パケットの生成をホストＣＰＵ１０１が行ってもよい。

図２は、データ転送装置１０１におけるある１つのセッションの状態遷移図を表している。セッションの状態として、非オフロード処理状態Ａ１０１とオフロード処理状態Ａ１０２が存在する。

ある１つのセッションは、セッションがコネクション処理部２２により生成された時点では、初期状態として、非オフロード処理状態Ａ１０１にある。セッションに対しコネクションが確立され、セッションがセッション管理部１１に登録されると、セッションの状態は、オフロード処理状態Ａ１０２に遷移する（Ｔ１０１）。またセッションが、セッション管理部１１から削除されると、非オフロード処理状態Ａ１０１に遷移する（Ｔ１０２）。

オフロード処理状態Ａ１０２では、当該セッションは、オフロード処理状態Ａ１０２にある他のセッション群とともに、セッション管理部１１により循環的に（均等に）、順次選択され、通信処理部１４により、当該セッションに関する送信処理が行われる。すなわち、オフロード処理状態Ａ１０２にある各セッションは、それぞれ均等に送信の機会を割り当てられ、データを送信できる。一方、非オフロード処理状態Ａ１０１にある当該セッションは、セッション管理部１１に登録されておらず、送信の機会は与えられない。

つまり、ホストＣＰＵ１０２は、セッション管理部１１にセッションＩＤを登録する事で、任意のセッションの送信処理を、データ転送装置１０１に代行依頼する。データ転送装置１０１は、セッション管理部１１に登録されたセッションに対して、均等に順番に送信処理を実施する。また、ホストＣＰＵ１０２は、コネクションの切断を通知することで、セッション管理部１１に登録されているセッションＩＤを除外し、これにより、当該セッションについて、データ転送装置１０１による送信処理を停止できる。

図３は、データ転送装置１０１における送信処理のフローチャートである。

（ステップＳ１０１）まず、セッション管理部１１は、自身が管理しているセッションから、１つのセッションを選択し、そのセッションに対して送信処理を開始するように通信処理部１４に通知する。

（ステップＳ１０２）通信処理部１４は、セッション管理部１１から通知されたセッションに対応するセッション情報を、セッション情報記憶部１２から読み出す。通信処理部１４は、読み出したセッション情報から、データの読み出しに必要な情報を特定し、特定した情報を、読み出し指示とともに、データ読み出し部１３に送る。データの読み出しに必要な情報は、例えば、送信バッファ１０４における読み出しアドレス（バッファ情報）や、ＭＳＳ（Ｍａｘｉｍｕｍ Ｓｅｇｍｅｎｔ Ｓｉｚｅ）などを含んでもよい。これらの情報をデータ読み出し部１３が内部で管理している場合は、通信処理部１４は読み出し指示のみを送る構成でもよい。

（ステップＳ１０３）データ読み出し部１３は、通信処理部１４の読み出し指示に従って、送信バッファ１０４からデータを読み出す。例えば、１フレームに格納する分のデータを読み出す。

例えば、ＭＳＳが１４６０Ｂｙｔｅに設定されており、送信バッファ１０４には４ＫＢのデータが存在した場合は、４ＫＢのうち１４６０Ｂｙｔｅだけデータを読み出す。または、ＭＳＳが１４６０Ｂｙｔｅに設定されており、送信バッファ１０４に５１２Ｂｙｔｅのデータが存在する場合は、５１２Ｂｙｔｅのデータを読み出す。本実施形態では、各セッションについて、１回の送信処理で、１フレームの送信を想定しているが、所定の複数のフレームを送信する形態でもよい。この場合は、フレームの個数分、各フレームに格納するデータをそれぞれ読み出すことになる。当然ながら、フレームに格納するデータが存在しない場合は、送信するフレーム数は、上記所定の複数よりも小さくなる。つまり、各セッションおよび各回の送信処理で送信されるフレーム数の上限値は共通である。

（ステップＳ１０４）通信処理部１４は、データ読み出し部１３からデータを受け取ると、セッション情報を元にヘッダを生成し、ヘッダをデータと結合する。また、ヘッダとデータからチェックサムを計算し、その計算結果をデータにさらに付加することで、フレームを生成する。通信処理部１４は、生成したフレームを、ネットワーク２０１に出力する。

（ステップＳ１０５）通信処理部１４は、フレームを送信したセッションに対応するセッション情報を更新する。例えば、今回送信したデータのサイズに基づき、セッション情報におけるシーケンス番号（送信済みシーケンス番号）を更新する。また、今回、送信バッファ１０４から読み出しを行ったアドレス、または、今回送信したデータのサイズ等から、セッション情報におけるバッファ情報を更新する。その他、必要に応じて、セッション情報内の他の項目の値を更新する。ただし、バッファ情報の更新は、再送処理を考慮して、送信したデータに該当するＡＣＫパケットを受信したタイミングで行う構成でも良い。

（変形例）
第１の実施形態では、通信プロトコルとしてＴＣＰを想定し、コネクションを確立しているセッションをセッション管理部で選択の対象としたが、ＵＤＰのようなコネクションレス型のプロトコルを使用する場合は、単純に、確立している各セッションを選択の対象にすることも可能である。このことは、後述する第２および第３の実施形態についても同様に適用される。

以上、第１の実施形態に係る通信装置によれば、各セッションに対して、それぞれ順番に（循環的に）送信処理を実行し、セッション間で各回の送信処理で送信するデータ量のばらつきを抑制する。例えば、各セッションおよび各送信処理で、それぞれ上限値以下の個数のフレームを送信する。これにより、各セッションに、それぞれ均等にネットワーク帯域を割り当てることができ、特定のセッションでバースト的にフレームが送信されることを防止できる。

（第２の実施形態）
本実施形態では、セッション管理部１１で管理するセッションのうち、送信バッファ１０４にデータが存在するセッションのみを、送信処理を実行する対象として選択する。第１の実施形態では、セッション管理部１１に登録されている限り、送信するデータが存在しないセッションも選択される。このため、当該セッションに対して送信処理の動作がとられると、結局、送信するデータは存在しないことから、データの送信は行われず、それまで行われたセッション情報の読み出し動作、およびその解析等の動作が無駄になる（空振り動作）。これは、データ転送装置にとって余分な負荷になるとともに、その動作の時間分、ネットワーク帯域の利用効率が低下する。そこで、本実施形態では、送信するデータがないセッションに対しては、送信処理に対するセッションの選択対象から除外することで、この問題を解決する。

図４は、第２の実施形態に係るデータ転送装置を備えた通信装置を示すブロック図である。図１と同一の名称の要素には同一の符号を付して、変更または拡張された処理を除き、重複する説明を省略する。

本実施形態の通信装置２００におけるデータ転送装置１０１は、第１の実施形態の各処理部に加え、バッファ状態管理部１７を備える。バッファ状態管理部１７は、セッション管理部１１に登録されている各セッションについて、送信バッファ１０４でのデータ格納状況に応じて、その状態の設定を管理する。

図５は、データ転送装置１０１におけるある１つのセッションの状態遷移図を表している。

第１の実施形態における非オフロード処理状態Ａ１０１・オフロード処理状態Ａ１０２に加え、オフロード処理状態（データ待ち）Ａ１０３が設けられている。ここでは、第１の実施形態で説明したオフロード処理状態Ａ１０２を、オフロード処理状態（送信可能）Ａ１０２と表現して、オフロード処理状態（データ待ち）Ａ１０３と区別している。オフロード処理状態（送信可能）Ａ１０２は、セッションの第１の状態、オフロード処理状態（データ待ち）Ａ１０３は、セッションの第２の状態に相当する。

オフロード処理状態（データ待ち）Ａ１０３は、あるセッションについて、コネクションが確立していてセッション管理部１１に登録されているが、送信用のデータが送信バッファ１０４に存在しない状態である。この状態では、セッション管理部１１は、当該セッションを、送信処理に対する選択対象から除外する。

バッファ状態管理部１７は、オフロード処理状態（送信可能）Ａ１０２とオフロード処理状態（データ待ち）Ａ１０３の設定を、セッション管理部１１で管理されている各セッションに対して管理する。

例えば、オフロード処理状態（送信可能）Ａ１０２において、送信バッファ１０４にデータが存在しないことが検知された場合は、通信処理部１４が、その旨をバッファ状態管理部１７に通知する。通知を受けたバッファ状態管理部１７は、セッション管理部１１における当該セッションの状態を、オフロード処理状態（データ待ち）Ａ１０３に設定する（Ｔ１０３）。

ここで、非オフロード処理状態Ａ１０１ではなく、オフロード処理状態（データ待ち）Ａ１０３に設定するのは、データ転送装置１０１は、送信バッファ１０４からのデータ転送は行わないが、データ受信処理や、ＡＣＫパケットやＦＩＮパケット、ＲＳＴパケット等の制御関連の送受信処理を、対向機器３０１と行う必要があるためである。つまり、セッション管理部１１でセッションが登録されている限り、データの送信処理は行わなくとも、上記制御関連の送受信処理は行われるよう、データ転送装置は動作する。

また、書き込み制御部２３が、その制御により、送信バッファ１０４にデータを書き込んだ時に、その旨をバッファ状態管理部１７に通知する。通知を受けたバッファ状態管理部１７は、セッション管理部１１における当該セッションの状態を、オフロード処理状態（データ待ち）Ａ１０３から、オフロード処理状態（送信可能）Ａ１０２に変える（Ｔ１０４）。なお、当該セッションが、元々オフロード処理状態（送信可能）Ａ１０２であれば、その状態を維持する。

また、オフロード処理状態（データ待ち）Ａ１０３において、コネクション処理部２２からコネクションの切断の通知を受けると、セッション管理部１１は、当該セッションの登録を削除する。すなわち、当該セッションのセッションＩＤを削除する。これにより、当該セッションは、非オフロード処理状態Ａ１０１に遷移する（Ｔ１０５）。

セッション管理部１１は、オフロード処理状態（送信可能）Ａ１０２にあるセッションのみを循環的に選択して、通信処理部１４に送信処理を実行させる。これにより、コネクションは確立しているが、送信バッファ１０４にデータが存在しないセッションに対しては、送信処理の動作を開始させずに済む。

図６は、本実施形態に係るデータ転送装置１０１における送信処理のフローチャートである。より詳細には、このフローチャートは、セッション管理部１１に登録されている、オフロード処理状態（送信可能）Ａ１０２にあるセッションに対して行う処理の流れを示している。

（ステップＳ２０１）セッション管理部１１は、自身が管理しているセッションから、オフロード処理状態（送信可能）Ａ１０２にあるセッションを１つ選択し、そのセッションに対して送信処理を開始するように、通信処理部１４に通知する。

（ステップＳ２０２）通信処理部１４は、通知されたセッションに該当するセッション情報をセッション情報記憶部１２から読み出す。通信処理部１４は、セッション情報から、送信バッファ１０４からのデータの読み出しに必要な情報（例えばバッファ情報、ＭＳＳなど）を特定する。

（ステップＳ２０３）通信処理部１４は、特定した情報から、送信バッファ１０４に送信用のデータが存在するかを判断する。例えば、バッファ情報が、読み出すべきアドレスが存在しないことを示す場合（例えば読み出しポインタと書き込みポインタが一致している場合）は、送信バッファ１０４にデータが存在しないと判断する。それ以外の場合は、データが存在すると判断できる。

（ステップＳ２０７）通信処理部１４は、送信バッファ１０４にデータが存在しないと判断したときは、その旨をバッファ状態管理部１７に通知する。バッファ状態管理部１７は、そのセッションの状態を、オフロード処理状態（データ待ち）Ａ１０３に設定する。この後、ステップＳ２０１に戻る。

（ステップＳ２０４）一方、通信処理部１４は、送信バッファ１０４にデータが存在すると判断したときは、通信処理部１４は、データ読み出し部１３に、読み出し指示、および、必要に応じてバッファ情報等を送る。データ読み出し部１３は、読み出し指示に従って、例えば１フレームに格納する分だけのデータを、送信バッファ１０４から読み出す。第１の実施形態と同様、各セッションについて、１回の送信処理毎に、１フレーム分の送信を想定しているが、１回の送信処理で、複数のフレームを送信する形態でもよい。

（ステップＳ２０５）通信処理部１４は、データ読み出し部１３からデータを受け取ると、セッション情報を元にヘッダを生成し、生成したヘッダをデータと結合する。また、ヘッダとデータからチェックサムを計算し、その計算結果を、データにさらに付加することで、フレームを生成する。通信処理部１４は、生成したフレームをネットワーク２０１に出力する。

（ステップＳ２０６）通信処理部１４は、フレームの送信後、セッション情報記憶部１２における当該セッションのセッション情報を更新する。例えば今回送信したデータのサイズに応じて、セッション情報におけるシーケンス番号（送信済みシーケンス番号）を更新する。また、今回送信したデータを読み出したアドレスに応じて、セッション情報におけるバッファ情報を更新する。バッファ情報の更新は、再送処理を考慮して、送信したフレームに該当するＡＣＫパケットを受信したタイミングで行う構成でも良い。

上述した処理では、通信処理部１４は、送信バッファ１０４にデータが存在するかの判断を、送信処理の開始時に行ったが、送信処理の完了後に、送信バッファ１０４にデータが存在するかの判断を行ってもよい。つまり、図６のステップＳ２０３、Ｓ２０６の処理を、ステップＳ２０５またはＳ２０６の後に行ってもよい。

また、上述した実施形態では、送信バッファ１０４にデータが存在するかの判断を通信処理部１４が行ったが、この判断をバッファ状態管理部１７が行うようにしてもよい。この場合、バッファ状態管理部１７は、書き込み制御部２３から、セッション毎に、新たに送信バッファ１０４に書き込まれたデータのアドレスの通知を受け、また通信処理部１４からは、送信バッファ１０４から読み出したデータのアドレス（あるいは、送信済みでＡＣＫパケットを受信したデータのアドレス）の通知を受ける。バッファ状態管理部１７は、例えば書き込まれたデータの末尾のアドレスを書き込みポインタ、読み出し済みのデータの末尾のアドレスを読み出しポインタとし、データ転送装置１０１の内部または外部のバッファ（メモリ）で管理する。バッファ状態管理部１７は、これらのポインタを比較することで、まだ読み出されていないデータが存在するか判断できる。まだ読み出されていないデータが存在することを検知した場合は、当該セッションの状態を、オフロード状態（データ待ち）Ａ１０３に遷移させる。

以上、第２の実施形態に係る通信装置によれば、コネクションを確立していて、かつ、送信バッファ１０４にデータが存在するセッションに対してのみ、順次、フレーム送信処理を実行する。これにより、セッション間で均等に帯域を利用しつつ、効率よく転送をすることが可能となる。

（第３の実施形態）
ＴＣＰでは、受信側の通信装置は、現在、自身が受信可能なデータサイズをウィンドウサイズ（受信ウィンドウサイズ）として、送信側の通信装置に通知している。このウィンドウサイズは、データパケットやＡＣＫパケットのヘッダに含められる。一般的に、この受信ウィンドウサイズは、自身の受信バッファの空き領域のサイズなどが、設定される。送信側の通信装置は、この受信側の通信装置の受信ウィンドウサイズを、自身の送信ウィンドウサイズとして用い、この送信ウィンドウサイズ以上のデータ送信を行わないように、送信を制御（フロー制御）する。これは、受信側の通信装置でのバッファのオーバーフローを防ぐためである。もし受信側の通信装置の受信バッファにオーバーフローが発生すると、ＴＣＰ／ＩＰの再送処理が発生して、通常より多くのパケットを、ネットワークに送信してしまう。

また、ネットワークの通信経路上の通信機器（例えばルータ等の中継機器）内にもバッファが存在し、これらのバッファがオーバーフローを起こす可能性も考えられる。このため、ＴＣＰでは、送信側は輻輳制御によって、送信するデータサイズを制限しながら、輻輳を起こさないように送信処理を行う。このとき、送信するデータサイズは、送信側の輻輳ウィンドウによって定められる。ＴＣＰの輻輳制御では、はじめは輻輳ウィンドウサイズを小さな値から開始し、受信側からＡＣＫパケットを受ける（受信側へデータが到達する）度に、輻輳ウィンドウサイズを増やしていく。輻輳ウィンドウサイズを増やしていき、重複ＡＣＫや再送タイムアウト等が発生した場合には、通信経路上でバッファオーバーフロー等の理由により、パケットロス（輻輳）が発生したと判断して、輻輳ウィンドウサイズを減少させる。このようにＴＣＰでは、送信するデータサイズを制限しながら送信処理を行う事で、ネットワークの輻輳を、なるべく発生させないようにしている。輻輳制御アルゴリズムには、様々なものがあるが、本実施形態は、輻輳制御のアルゴリズムの種類によらないため、これ以上の説明は割愛する。

送信側の通信装置は、送信ウィンドウサイズ（対向装置の受信ウィンドウサイズ）と輻輳ウィンドウサイズのどちらかが、ある閾値以下になった場合は、送信処理を中断する。つまり、少なくともどちらかのウィンドウサイズが、閾値以下になった場合は、そのセッションについては、送信が中断される。この閾値には、例えばＭＳＳなどの値が使われる。この送信が中断されたセッションは、対向機器からのＡＣＫパケットを受信して、送信ウィンドウサイズ（対向の受信ウィンドウサイズ）と輻輳ウィンドウサイズが更新され、いずれのウィドウサイズも閾値を上回れば、送信が再開される。

上記のようにＴＣＰでは、送信ウィンドウおよび輻輳ウィンドウを用いてフロー制御および輻輳制御を行っているため、コネクション確立状態にあり、かつ、送信バッファにデータが存在する場合においても、送信を行わない場合がある。仮に、フロー制御および輻輳制御を無視して、送信処理を行うと、転送効率が低下する可能性が存在する。例えば、受信側（対向機器側）の受信バッファ等が極端に小さな状況で、送信ウィンドウの上記閾値以下のサイズのデータを送信すると、転送効率が低下し、最大速度での転送ができなくなる可能性がある。また、セッションの通信経路が輻輳を起こしているに場合に、輻輳ウィンドウの上記閾値以下のサイズのデータを送信しても、同様に、転送効率が低下し、最大速度での転送ができなくなる可能性が存在する。また、フロー制御及び輻輳制御を行っている状態で、仮に第１または第２の実施形態のフローチャートで示した送信処理を行うと、フロー制御および輻輳制御によって送信が制限されているセッションに対して送信処理の動作がとられると、結局、データの送信は行われず、それまで行われたセッション情報の読み出し動作、およびその解析等の動作が無駄になる（空振り動作）。これは、データ転送装置にとって余分な負荷になるとともに、その動作の時間分、ネットワーク帯域の利用効率が低下する。そこで、第３の実施形態では、フロー制御および輻輳制御の状態も考慮して、送信処理を行うセッションを決定する。

図７は、第３の実施形態に係るデータ転送装置を備えた通信装置を示すブロック図である。図１と同一の名称の要素には同一の符号を付して、変更または拡張された処理を除き、重複する説明を省略する。

通信装置３００の通信処理部１４は、送信処理を行う送信処理部１６と、受信処理を行う受信処理部１５を備える。通信処理部１４は、ＴＣＰの輻輳制御アルゴリズムを実行する機能を備えている。なお、第１および第２の実施形態でも、通信処理部１４は、送信処理を行う処理部と受信処理を行う部を備えているが、本実施形態では、これらを明示的に記載している。

本実施形態のデータ転送装置１０１は、第１の実施形態の各処理部に加え、ウィンドウ状態管理部１８を備える。ウィンドウ状態管理部１８は、送信ウィンドウ及び輻輳ウィンドウの状態（すなわち、フロー制御および輻輳制御の状態）に応じて、セッション管理部１１で管理しているセッションの状態の設定を制御する。

図８は、データ転送装置１０１におけるある１つのセッションの状態遷移図を表している。

第１の実施形態における非オフロード処理状態Ａ１０１・オフロード処理状態Ａ１０２に加え、オフロード処理状態（ウィンドウ更新待ち）１０４が設けられている。第１の実施形態で説明したオフロード処理状態を、オフロード処理状態（ウィンドウ更新待ち）１０４と区別するため、オフロード状態（送信可能）Ａ１０２と表現している。オフロード処理状態（送信可能）Ａ１０２は、セッションの第１の状態、オフロード処理状態（ウィンドウ更新待ち）Ａ１０４は、セッションの第２の状態に相当する。

オフロード処理状態（ウィンドウ更新待ち）１０４は、コネクションが確立していてセッション管理部１１に登録はされているが、送信ウィンドウおよび輻輳ウィンドウの各ウィンドウサイズの少なくとも一方が閾値以下の状態である。送信ウィンドウのウィンドウサイズが閾値以下の状態を“送信ウィンドウが閉じている”、閾値より大きい状態を“送信ウィンドウが開いている”と表現することがある。輻輳ウィンドウのウィンドウサイズが閾値以下の状態を“輻輳ウィンドウが閉じている”、閾値より大きい状態を“輻輳ウィンドウが開いている”と表現することがある。送信ウィンドウの閾値と輻輳ウィンドウの閾値は同じであっても、異なってもよい。例えば両閾値ともＭＳＳを用いてもよい。ウィンドウが閉じた状態にあるセッションは、セッション管理部１１の選択対象から除外され、送信処理は行われない。

ウィンドウ状態管理部１８は、オフロード処理状態（送信可能）Ａ１０２とオフロード処理状態（ウィンドウ更新待ち）Ａ１０４の設定を、セッション管理部１１に登録されている各セッションに対して管理する。

例えば、オフロード処理状態（送信可能）Ａ１０２にあるセッションについて、送信処理部１６が、送信処理の開始時にウィンドウが閉じている事を検知した場合は、ウィンドウ状態管理部１８にこの旨を通知する。通知を受けたウィンドウ状態管理部１８が、当該セッションの状態を、オフロード処理状態（ウィンドウ更新待ち）Ａ１０４に遷移させる（Ｔ１０６）。非オフロード処理状態Ａ１０１ではなく、オフロード処理状態（ウィンドウ更新待ち）Ａ１０４にするのは、送信バッファ１０４からのデータ送信は行わないが、対向機器３０１からのデータ受信処理やＡＣＫパケットやＦＩＮパケット、ＲＳＴパケットの送受信処理は行う必要があるためである。つまり、セッション管理部１１でセッションが登録されている限り、データの送信処理は行わなくとも、上記制御関連の送受信処理は行われるよう、データ転送装置は動作する。

一方、オフロード処理状態（ウィンドウ更新待ち）Ａ１０４において、受信処理部１５が、対向機器３０１からのＡＣＫパケットを受け、ＴＣＰパケット内のウィンドウサイズおよびＴＣＰの輻輳アルゴリズムに従って、送信および輻輳の各ウィンドウサイズが更新（同じ値に維持される場合もあり得る）されると、各ウィンドウサイズを、各々閾値と比較する。両方とも閾値よりも大きくなった場合は、受信処理部１５が、ウィンドウ状態管理部１８にこの旨を通知する。通知を受けたウィンドウ状態管理部１８は、当該セッションの状態を、オフロード処理状態（送信可能）Ａ１０２に遷移させる（Ｔ１０７）。あるいは、各ウィンドウサイズが閾値よりも大きくなったかを確認せずに、ＡＣＫパケットを受信したら、即座に、オフロード処理状態（送信可能）Ａ１０２へ遷移させるように構成してもよい。これは、ＡＣＫパケットの受信時には、各ウィンドウサイズが更新される可能性が高いと考える事ができるためであり、仮にいずれか一方のウィンドウサイズが閾値以下のまま、オフロード処理状態（送信可能）Ａ１０２に遷移させたとしても、次の送信処理時に再度、オフロード処理状態（ウィンドウ更新待ち）Ａ１０４に遷移させることができるためである。

また、オフロード処理状態（ウィンドウ更新待ち）Ａ１０４において、コネクション処理部２２からコネクションの切断の通知を受けると、セッション管理部１１は、当該セッションの登録を削除する。すなわち、当該セッションのセッションＩＤを削除する。これにより、当該セッションは、非オフロード処理状態Ａ１０１に遷移する（Ｔ１０８）。

送信ウィンドウサイズおよび輻輳ウィンドウサイズの値は、各セッションのセッション情報に含めて管理してもよい。例えば受信処理部１５におけるＡＣＫパケットの受信等により、送信ウィンドウサイズおよび輻輳ウィンドウサイズの新たな値が取得されると、該当するセッションのセッション情報に、更新後の値を書き込んで（上書きして）もよい。また、ウィンドウ状態管理部１８が、定期的または任意のイベント発生時に、セッション情報内の各ウィンドウサイズと、各々の閾値とを比較し、上述した判断方法に従って、セッションの状態の設定を制御してもよい。任意のイベントとしては、例えばセッション情報における各ウィンドウサイズの少なくとも一方が更新されたときに、通信処理部がウィンドウ状態管理部１８にその旨を通知し、これをトリガーとすることが考えられるが、これに限定されない。

図９は、本実施形態に係るデータ転送装置１０１における送信処理のフローチャートである。より詳細には、このフローチャートは、セッション管理部１１に登録されている、オフロード処理状態（送信可能）Ａ１０２にあるセッションに対して行う処理の流れを示している。

（ステップＳ３０１）セッション管理部１１は、自身が管理しているセッションから、オフロード処理状態（送信可能）Ａ１０２にあるセッションを１つ選択し、そのセッションに対して送信処理を開始するように、通信処理部１４に通知する。

（ステップＳ３０２）通信処理部１４の送信処理部１６は、通知されたセッションに該当するセッション情報をセッション情報記憶部１２から読み出す。

（ステップＳ３０３）送信処理部１６は、セッション情報に含まれる送信ウィンドウおよび輻輳ウィンドウの各ウィンドウサイズの値から、送信ウィンドウおよび輻輳ウィンドウが開いているかを判断する。すなわち、各ウィンドウサイズの値が両方とも閾値より大きいかを判断する。

（ステップＳ３０７）送信処理部１６は、少なくともいずれか一方のウィンドウが閉じていれば、すなわち、少なくとも一方のウィンドウサイズの値が閾値以下であれば、その旨をウィンドウ状態管理部１８に通知する。ウィンドウ状態管理部１８は、当該セッションの状態を、オフロード処理状態（ウィンドウ更新待ち）Ａ１０４に設定する。この後、ステップＳ３０１に戻る。

（ステップＳ３０４）一方、送信処理部１６は、両ウィンドウとも開いていれば、データ読み出し部１３に、読み出し指示、および必要に応じてバッファ情報等を送る。データ読み出し部１３は、読み出し指示に従って、例えば１フレームに格納する分のデータを、送信バッファ１０４から読み出す。第１の実施形態と同様、１回の送信処理で、複数のフレームを送信する形態でもよい。ただし、読み出すデータサイズの上限値は、送信ウィンドウサイズまたは輻輳ウィンドウサイズの最小値となる。

（ステップＳ３０５）送信処理部１６は、データ読み出し部１３からデータを受け取ると、セッション情報を元にヘッダを生成し、生成したヘッダをデータに結合する。また、ヘッダとデータからチェックサムを計算し、その計算結果を、データにさらに結合することで、フレームを生成する。送信処理部１６は、生成したフレームをネットワーク２０１に出力する。

（ステップＳ３０６）送信処理部１６は、フレームの送信後、セッション情報記憶部１２における当該セッションのセッション情報を更新する。例えば今回送信したデータのサイズに応じて、セッション情報におけるシーケンス番号（送信済みシーケンス番号）を更新する。また、今回送信したデータの読み出しアドレス等から、セッション情報におけるバッファ情報を更新する。

なお、受信処理部１５は、対向機器からＡＣＫパケット等を受信した場合は、セッション情報における送信ウィンドウサイズおよび輻輳ウィンドウサイズを更新する。更新により両ウィンドウサイズの値が閾値以下の状態から閾値を上回った場合は、ウィンドウ状態管理部１８にその旨を通知する。ウィンドウ状態管理部１８は、当該通知を受けて、該当するセッションの状態を、オフロード処理状態（送信可能）に更新する。

上述した実施形態では、送信ウィンドウと輻輳ウィンドウの両方のウィンドウを用いて送信処理を制御したが、いずれか一方のウィンドウのみを用いて制御を行ってもよい。例えば、送信ウィンドウの方を用いる場合、送信ウィンドウサイズが閾値より大きければ、そのセッションの状態をオフロード処理状態（送信可能）として、そのセッションを送信処理の対象とする。閾値以下であれば、オフロード処理状態（ウィンドウ更新待ち）として、そのセッションを送信処理の対象としない。同様に、輻輳ウィンドウの方を用いる場合も、輻輳ウィンドウサイズが閾値より大きければ、そのセッションの状態をオフロード処理状態（送信可能）として、そのセッションを送信処理の対象とする。閾値以下であれば、オフロード処理状態（ウィンドウ更新待ち）として、そのセッションを送信処理の対象としない。

以上、第３の実施形態に係る通信装置によれば、コネクションを確立しているセッションの内、ウィンドウが開いているセッションに対してのみ、順次、循環的に送信処理を実行するため、セッション間で均等に帯域を利用しつつ、効率よく転送をすることが可能となる。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

１１：セッション管理部
１２：セッション情報記憶部
１３：データ読み出し部
１４：通信処理部
１５：受信処理部
１６：送信処理部
１７：バッファ状態管理部
１８：ウィンドウ状態管理部
２１：アプリケーション部
２２：コネクション処理部
２３：書き込み制御部
１０１：データ転送装置
１０２：ホストＣＰＵ
１０３：記憶装置
１０４：送信バッファ
２０１：ネットワーク
３０１：対向機器

Claims (16)

1. 複数の対向機器と、ネットワークを介して通信するデータ転送装置であって、
   前記複数の対向機器に対して生成された複数のセッションを順次、循環的に選択するセッション管理部と、
   前記セッション間で各回の送信処理で送信するデータ量のばらつきを抑制するように、前記セッション管理部で選択されたセッションに関連する対向機器に対してデータの送信処理を行う通信処理部と
   を備えたデータ転送装置。
2. 前記通信処理部は、前記データを含むフレームを前記対向機器に送信し、前記セッション間で前記各回の送信処理で送信するフレーム数の上限値は同じである
   請求項１に記載のデータ転送装置。
3. 前記セッション管理部は、前記セッションに関連する送信用のデータを格納する送信バッファに、前記セッションに関連するデータが存在しない場合には、前記セッションを、選択の対象から除外する
   請求項１または２に記載のデータ転送装置。
4. 前記セッションに関連する送信用のデータを格納する送信バッファに、前記セッションに関連するデータが存在する場合に、前記セッションに第１の状態、存在しない場合に第２の状態を設定するバッファ状態管理部と、をさらに備え、
   前記セッション管理部は、前記第１の状態が設定されたセッションを選択の対象とし、前記第２の状態が設定されたセッションを、選択の対象から除外する
   請求項３に記載のデータ転送装置。
5. 前記通信処理部は、前記セッションの送信ウィンドウサイズの値が閾値以下のときは、前記セッションを、選択の対象から除外する
   請求項１または２に記載のデータ転送装置。
6. 前記セッションの送信ウィンドウサイズの値が閾値より大きいときは、前記セッションに第１の状態、前記閾値以下のときは、第２の状態を設定するウィンドウ状態管理部をさらに備え、
   前記セッション管理部は、前記第１の状態が設定されたセッションを選択の対象とし、前記第２の状態が設定されたセッションを、選択の対象から除外する
   請求項５に記載のデータ転送装置。
7. 前記通信処理部は、前記セッションに関連する確認応答パケットを前記対向機器から受信し、
   前記セッション管理部は、前記通信処理部で前記確認応答パケットが受信された場合は、前記送信ウィンドウサイズの値に拘わらず、前記セッションの状態を前記第１の状態に設定する
   請求項６に記載のデータ転送装置。
8. 前記通信処理部は、前記セッションの輻輳ウィンドウサイズの値が閾値以下のときは、前記セッションを、選択の対象から除外する
   請求項１ないし７のいずれか一項に記載のデータ転送装置。
9. 前記セッションの輻輳ウィンドウサイズの値が閾値より大きいときは、前記セッションに第１の状態、前記閾値以下のときは、第２の状態を設定するウィンドウ状態管理部をさらに備え、
   前記セッション管理部は、前記第１の状態が設定されたセッションを選択の対象とし、前記第２の状態が設定されたセッションを、選択の対象から除外する
   請求項８に記載のデータ転送装置。
10. 前記通信処理部は、前記セッションに関連する確認応答パケットを前記対向機器から受信し、
    前記セッション管理部は、前記通信処理部で前記確認応答パケットが受信された場合は、前記輻輳ウィンドウサイズの値に拘わらず、前記セッションの状態を前記第１の状態に設定する
    請求項９に記載のデータ転送装置。
11. 前記セッション毎に送信用のデータを格納する送信バッファと、
    前記送信バッファからデータを読み出すデータ読み出し部とを備え、
    前記通信処理部が、前記セッション毎に前記データ読み出し部にデータの読み出し指示を出力し、前記データ読み出し部によって読み出されたデータを前記対向機器に送信する
    請求項１ないし１０のいずれか一項に記載のデータ転送装置。
12. 前記複数のセッションは、前記複数の対向機器とそれぞれコネクションが確立されたセッションである
    請求項１ないし１１のいずれか一項に記載のデータ転送装置。
13. 前記通信処理部は、前記対向機器とＴＣＰ／ＩＰに従って通信する
    請求項１ないし１２のいずれか一項に記載のデータ転送装置。
14. 複数の対向機器と、ネットワークを介して通信するデータ転送方法であって、
    前記複数の対向機器に対して生成された複数のセッションを順次、循環的に選択するセッション管理ステップと、
    前記セッション間で各回の送信処理で送信するデータ量のばらつきを抑制するように、前記選択されたセッションに関連する対向機器に対してデータの送信処理を行う通信処理ステップと
    を備えたデータ転送方法。
15. 前記複数の対向機器に対して前記セッションを生成するホストＣＰＵと、
    請求項１ないし１３のいずれか一項に記載のデータ転送装置と、
    を備えた通信装置。
16. 前記ホストＣＰＵは、前記セッションについて前記対向機器とコネクションの確立および切断を制御するコネクション処理部を備え、
    前記コネクション処理部は、前記コネクションを確立すると、前記コネクションを確立したセッションの識別子を前記データ転送装置に通知し、
    前記データ転送装置の前記セッション管理部は、前記ホストＣＰＵから通知された識別子に基づき前記セッションを選択する
    請求項１５に記載の通信装置。

Images