JP6279970B2 - プロセッサ、通信装置、通信システム、通信方法およびコンピュータプログラム - Google Patents

Description

本発明の実施形態は、プロセッサ、通信装置、通信システム、通信方法およびコンピュータプログラムに関する。

従来の通信装置において、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）の処理を、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）ではなく、専用のハードウェアで行うＴＯＥ（ＴＣＰ／ＩＰ Ｏｆｆｌｏａｄ Ｅｎｇｉｎｅ）が知られている。このＴＯＥを複数組み合わせ、通信の耐障害性、負荷分散、速度の向上を実現する方法がある。しかしながら、この方法では、それぞれのＴＯＥでセッション情報を管理するため、第１のＴＯＥで、あるセッションのフレームを送信している場合に、異なる第２のＴＯＥから、同じセッションのフレームを送信させるためには、第１のＴＯＥから第２のＴＯＥへ、セッション情報をＣＰＵで移行する処理が必要になる。このため、ＴＯＥ間の切り替えを迅速に行うことができなかった。また、この方法では、ＴＯＥごとにＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌｅｒ）を設ける必要があり、複数のＭＡＣを用いるためには、ＭＡＣと同数のＴＯＥが必要であった。このため、回路規模が増大になり、コスト高になる問題があった。

特開２０１１−１８１０６号公報

本発明の実施形態は、通信部であるＭＡＣを切り換えて送信することを、低回路規模または低コストで、実現しようとするものである。

本発明の実施形態としてのプロセッサは、ネットワークに接続される複数の通信部を備えた通信装置に対するプロセッサであって、管理部と、選択部とを備える。前記管理部は、通信装置における前記複数の通信部の状態を管理する。前記選択部は、前記通信部の状態に基づき、前記通信装置が前記ネットワークを介して通信する相手装置に対して生成されたソケット情報に関連するフレームを送信する通信部を選択する。前記プロセッサは、選択した通信部で前記ソケット情報に関連するフレームの送信を前記通信装置が行うように制御する。

第１の実施形態に係わる通信システムを示すブロック図。 ＨＴＴＰを用いた通信の動作シーケンスを示す図。 通信カードとＣＰＵの詳細な構成を示す図。 ソケット情報を説明する図。 送信キューと送信リクエストを説明する図。 第１の送信フレーム処理部の動作例のフローチャート。 第２の実施形態に係わる通信システムのブロック図。 ４つの通信部を含む仮想通信部でラウンドロビモードを行う場合の動作例を示す図。 ４つの通信部を含む仮想通信部でラウンドロビモードを行う場合の通信できない通信部がある場合の動作例を示す図。 ある仮想通信部をラウンドロビンモードで、別の仮想通信部をＸＯＲ負荷分散モードで動作させる例を示す図。 出力先切替えテーブルを説明する図。

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

（第１の実施形態）
図１は、本発明の第１の実施形態に係わる通信システムを示すブロック図である。

本実施形態の通信システムは、視聴端末３０１に映像を配信する映像配信サーバ１０１である。映像配信サーバ１０１と各視聴端末３０１はＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を用いて通信を行う。映像配信サーバ１０１は各視聴端末３０１からのＴＣＰのコネクション要求を受けて、ＴＣＰコネクションを確立する。映像配信サーバ１０１は、確立したＴＣＰコネクションに基づき、各視聴端末３０１からＨＴＴＰによる映像コンテンツのリクエストを受け、映像コンテンツを配信する。視聴端末３０１は、映像配信サーバ１０１から送信されたコンテンツを受信して、画面に映像を表示する。

映像配信サーバ１０１は、システムメモリ１１１、ＣＰＵ１２１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、チップセット１５１、ストレージ１４１、通信カード１３１を備え、これらがバスに接続されている。

ＣＰＵ１２１は、プロセッサの一形態であり、ストレージ１４１に格納されたプログラムをメモリに読み出し、それを実行する。ＣＰＵ１２１は、バスにより通信カード１３１と接続される。通信カード１３１は、通信装置の一形態であり、ＴＯＥ（ＴＣＰ／ＩＰ Ｏｆｆｌｏａｄ Ｅｎｇｉｎｅ）機能を搭載したカードである。一例として、ＰＣＩ Ｅｘｐｒｅｓｓバスで接続されるカード（ＰＣＩ Ｅｘｐｒｅｓｓカード）を用いることができる。

通信カード１３１は、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、メモリ、ＣＰＵ１２１と接続するためのコネクタ、および、ネットワーク２０１と接続される複数のコネクタが搭載されている。ネットワーク２０１とのコネクタは、一例として、ＳＦＰ＋コネクタを用いることができる。通信カード１３１は、ＣＰＵ１２１に代わり、ＦＰＧＡでＴＣＰ／ＩＰ処理を行うことにより、ＣＰＵ１２１の処理負荷をオフロードして、高速かつ省電力な通信を行う。

なお、通信カード１３１は、図１に示すようにＣＰＵ１２１と直接接続される形態の他、チップセット１５１を介してＣＰＵ１２１に接続されてもよい。また、図では、ＣＰＵ１２１が、チップセット１５１を介してストレージ１４１に接続されているが、ストレージ１４１を直接、通信カード１３１に接続する形態も可能である。この場合、通信カード１３１からストレージ１４１にＣＰＵ１２１を介さずに直接、アクセスできるため、高速なデータ送信および受信が可能になる。

図２は、ＨＴＴＰを用いた通信の動作シーケンスを示す。まず視聴端末３０１は、ＴＣＰのコネクションを確立するため、ＴＣＰヘッダのフラグフィールドのうち、ＳＹＮビットが１のＳＹＮセグメントを送信し、コネクションの確立を要求する。これを受けた映像配信サーバ１０１は、視聴端末３０１から送られたＳＹＮセグメントのシーケンス番号に１を加えた値をＴＣＰの確認応答番号として設定し、フラグフィールドのＳＹＮビットとＡＣＫビットが１のセグメントであるＳＹＮ／ＡＣＫセグメントを送信する。次に、これを受信した視聴端末３０１が、映像配信サーバ１０１の送信したＳＹＮ／ＡＣＫセグメントのシーケンス番号に１を加えた値を確認応答番号として、フラグフィールドのＡＣＫビットを１にしたＡＣＫセグメントを送信する。これによりＴＣＰコネクションが確立される（Ｓ１０１）。

その後、視聴端末３０１は、この確立したＴＣＰコネクションを用いて、ＨＴＴＰのＧＥＴリクエストを用いて映像コンテンツを要求し（Ｓ１０２）、映像配信サーバ１０１はそのレスポンスとして、ステータスとヘッダとコンテンツの送信を行う（Ｓ１０３）。

送信が終わるとＴＣＰのフラグフィールドのＦＩＮビットを１にしたＦＩＮセグメントを送信し、視聴端末３０１からＡＣＫセグメントとＦＩＮセグメントを受信した後、そのＦＩＮセグメントのシーケンス番号に１を加えたＡＣＫセグメントを送信する。これにより、ＴＣＰのコネクションが切断される（Ｓ１０４）。なお、ＨＴＴＰ１．１を用いると、１つのＴＣＰコネクション内で、ＨＴＴＰのリクエスト（Ｓ１０２）とレスポンス（Ｓ１０３）は、それぞれの上限回数に達するまで繰り返すことができる。

図３に通信カード１３１とＣＰＵ１２１の詳細な構成を示す。図中の点線は制御の流れ、実線はデータの流れを示す。また、図中の黒丸は、制御またはデータの信号線が接続されていることを示す。

通信カード１３１は、複数の通信部０、１、２、３と、第１の受信フレーム処理部３１と、複数の送信キュー０、１、２、３と、第１の送信フレーム処理部３３と、ソケット情報記憶部３２を備えている。各通信部は、ネットワーク２０１に接続され、ネットワーク２０１へのフレームの送信と、ネットワーク２０１からのフレームの受信を行う。第１の受信フレーム処理部３１は、各通信部で受信したフレームのプロトコルを処理する。複数の送信キューは、各通信部への送信リクエストを蓄積する。第１の送信フレーム処理部３３は、送信キューから送信リクエストを読み出し、送信リクエストに応じたフレームをプロトコル処理により生成して、送信キューに対応する通信部から送信する。ソケット情報記憶部３２は、ＴＣＰのコネクションに関するソケット情報を記憶する記憶装置である。一例として、ソケット情報記憶部３２と送信キュー０〜３は、通信カード１３１上のメモリで実現され、通信部０〜３と第１の送信フレーム処理部３３と第１の受信フレーム処理部３１はＦＰＧＡで実現される。ソケット情報記憶部３２は通信カードに設けられる他、システムメモリ１１１に設けられても良いし、ＣＰＵ１２１内に設けられても良い。

ＣＰＵ１２１は、第２の受信フレーム処理部２２と、第２の送信フレーム処理部２３と、状態管理部２６と、出力先選択部２５と、出力先設定部２１を備えている。またＣＰＵ１２１は、アプリケーションを実行する実行部２４を備えている。第２の受信フレーム処理部２２は、通信カードから渡されたフレームのプロトコルの処理を行う。第２の送信フレーム処理部２３は、送信するフレームのプロトコルの処理を行う。状態管理部２６は、各通信部が通信可能な状態かどうか（稼働の有無）、各通信部の負荷状態など、各通信部の状態を管理する。出力先選択部２５は、各通信部の状態などに基づきフレームを送信する通信部を選択する。出力先設定部２１は、出力先選択部２５で選択された通信部の識別情報（以下、出力通信部識別子と称する）を、ソケット情報記憶部３２において、該当するソケット情報に設定する。ソケット情報は、当該ソケット情報に関連するフレームを送信する通信部の識別情報（出力通信部識別子）を含んでいる。ＣＰＵ１２１は、これらの処理部を用いて、出力先選択部２５で選択した通信部で、通信カードからフレームが送信されるよう制御する。

通信部０〜３は、有線または無線の通信ネットワーク２０１と接続されている。有線ネットワークの例としては、イーサネット（Ｅｔｈｅｒｎｅｔ（登録商標））などがあり、無線ネットワークの例としては、ＩＥＥＥ規格の無線ＬＡＮネットワーク、携帯電話等のセルラーネットワークなどがある。図では、通信部０〜３が同じネットワークに接続されているように描かれているが、通信部０〜３の一部がそれぞれ異なるネットワークに接続されてもよい。例えば、通信部０、１が同じネットワーク、通信部２、３が同じネットワークといったように、ネットワークアドレスの異なるネットワーク（例えばそれぞれ異なるイーサネット）に接続されてもよい。通信部０〜３は、当該通信部で送信、受信または送受信されたデータ量（バイト数など）を計算するカウンタを備えていてもよい。

通信部０〜３は、ＯＳＩ（Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）参照モデルの物理層とデータリンク層にあたる機能を実行する。一例として、通信部０〜３は、ＦＰＧＡ上に実装されたＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）機能とＰＨＹ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ）機能を実行する。通信部０〜３は、ネットワーク２０１から受信した信号をＰＨＹ処理およびＭＡＣ処理してフレーム（ＭＡＣフレーム）を取得し、バスで接続された第１の受信フレーム処理部３１に、そのフレームを出力する。また、第１の送信フレーム処理部３３から入力されたフレームを、ネットワーク２０１に出力する。

ソケット情報記憶部３２は、ＴＣＰのコネクションに関するソケット情報を記憶する。ソケットは通信を行うためのインタフェースであり、ソケット情報には各通信プロトコルで通信を行うために必要な情報が含まれる。ソケット情報に記憶される情報は各通信プロトコルによって異なり、例えば、ＴＣＰのソケット情報では、図４（Ｂ）に示すように、自装置のＩＰアドレス、相手装置のＩＰアドレス、自装置のポート番号、相手装置のポート番号を記憶し、これらの組でソケットあるいは、ソケットに基づくコネクションを識別することができる。コネクションレスのプロトコルでは、例えば自装置のＩＰアドレスと自装置のポート番号などを用いてソケットを識別することもできる。また、ＴＣＰのコネクション状態、出力通信部識別子、これまで送信した最大のシーケンス番号、確認応答未受信のシーケンス番号、相手のウィンドウサイズ、次に相手が送信すると期待されるシーケンス番号（例えばこれまで受信済みのシーケンス番号の最小値＋１）、自身のウィンドウサイズ（受信ウィンドウサイズ）、相手に送信する送信データが格納されているアドレス、当該送信データの長さ、ＭＴＵ（Ｍａｘｉｍｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ）、宛先ＭＡＣアドレス、送信バイト数（これまで当該ソケット情報に関連して送信したデータの合計のバイト数）、受信バイト数（これまで当該ソケット情報に関連した受信データの合計のバイト数）などの情報を、ソケット毎に記憶する。本実施形態では、特にソケット情報に出力通信部識別子（通信部の識別情報）を含めていることを特徴の１つとしている。ソケット情報記憶部３２は、図４（Ａ）に示すように、ソケット毎のソケット情報を、メモリの容量が許す限り記憶することができ、各ソケット情報にはアドレスを付与できる。

第１の受信フレーム処理部３１は、通信部から入力されたフレーム（ＭＡＣフレーム）に対し各層のプロトコルの処理を行う。例えば、第１の受信フレーム処理部３１は、イーサネットプロトコルとＩＰｖ４とＴＣＰの処理を行うことができる。具体的に、第１の受信フレーム処理部３１は、受信したフレームのイーサネットヘッダのタイプ値から上位層プロトコルの番号を取り出し、ＩＰｖ４のバージョンチェックやチェックサムの検証、ＴＣＰのフラグのチェックやチェックサムの検証、シーケンス番号の検証、確認応答番号の検証、ウィンドウサイズの取得、確認応答セグメント（ＡＣＫセグメント）の送信指示、受信データの書き込みなどを行う。

第１の受信フレーム処理部３１は、受信したフレームが、上記プロトコル（ＩＰｖ４、ＴＣＰ）以外であった場合には、ＣＰＵ１２１で動作する第２の受信フレーム処理部２２に、受信フレームを渡す。ただし、第１の受信フレーム処理部３１は、上記プロトコル（ＩＰｖ４、ＴＣＰ）のすべての処理を行うことができるわけではなく、ＴＣＰのフラグフィールドのＳＹＮフラグまたはＦＩＮフラグが１のＴＣＰのセグメントを受信した場合も、ＣＰＵ１２１上のソフトウェアで動作する第２の受信フレーム処理部２２に受信フレームを渡す。これら以外の場合は、受信フレームを第２の受信フレーム処理部２２に渡すことなく、通信カード１３１内で処理する。なお、第１の受信フレーム処理部３１は、受信したＴＣＰセグメントのＳＹＮフラグが１でＡＣＫフラグが０の場合（すなわち、受信したＴＣＰセグメントがコネクション確立要求の場合）は、ソケット情報記憶部３２内にソケット情報の生成（確保）を行う。また、ＳＹＮフラグが１で、ＡＣＫフラグが０のＴＣＰセグメントを送信する場合（サーバからコネクション確立要求を送信する場合）、ソケット情報記憶部３２内にソケット情報の生成（確保）を行う。

第１の受信フレーム処理部３１は、コネクション状態がＳＹＮ＿ＳＥＮＴ状態で、ＳＹＮフラグとＡＣＫフラグが１のセグメントを受信した場合（すなわちサーバが送信したコネクション確立要求に対するＡＣＫセグメントを受信した場合）、シーケンス番号や確認応答番号のチェックを行い、ソケット情報のコネクション状態をＥＳＴＡＢＬＩＳＨＥＤ状態に遷移させることで、コネクションを確立する。なお、ソケット情報は、受信フレームのＩＰアドレスとポート番号を用いて、ソケット情報記憶部３２から合致するソケット情報を探索することで特定する。同様に、コネクション状態がＳＹＮ＿ＲＥＣＥＩＶＥＤ状態で、ＳＹＮフラグが０、ＡＣＫフラグが１のセグメントを受信した場合（すなわち、視聴端末３０１から受信したコネクション確立要求に対してＳＹＮフラグとＡＣＫフラグが１のセグメントを返し、それに対するＡＣＫセグメントを受信した場合）も、シーケンス番号や確認応答番号のチェックを行い、コネクション状態をＥＳＴＡＢＬＩＳＨＥＤ状態に遷移させ、コネクションを確立する。

第１の受信フレーム処理部３１は、コネクション確立後に、データを含むＴＣＰセグメントを受信した場合、ソケット情報記憶部３２内の該当するソケット情報から、受信データ（ＴＣＰセグメントのペイロード部）を格納するためのアドレス（ソケット情報の“受信データの格納されるアドレス”）を読み出し、そのアドレスにデータを書き込む。また、第１の受信フレーム処理部３１は、受信したＴＣＰセグメントのデータ量であるデータバイト数をカウントする手段を有し、当該手段でカウントした値を、ソケット情報に記憶する機能も備える。

また、第１の受信フレーム処理部３１は、コネクション確立後に受信したＴＣＰセグメントに対する確認応答（ＡＣＫ）セグメントを送信するように指示する。ＡＣＫセグメントの送信は、各通信部のうちの１つに対応する送信キューに、送信リクエストを入れることで行う。この時、送信リクエストのタイプに“ＡＣＫ”を指定し（送信リクエストの詳細は後述する）、送信する確認応答番号と、送信するウィンドウサイズも送信リクエスト内で指定する。送信する確認応答番号と、送信するウィンドウサイズは、該当するソケット情報と受信したＴＣＰセグメントのヘッダから特定する。また、送信リクエストを追加するキューは、該当するソケット情報内の出力通信部識別子が示す通信部に対応する送信キューである。

第２の受信フレーム処理部２２は、第１の受信フレーム処理部３１から転送されたフレームの処理を行う。一例として、第２の受信フレーム処理部２２では、ＡＲＰやＩＰｖ６、ＵＤＰなどの処理を行う。また、ＴＣＰのＳＹＮフラグまたはＦＩＮフラグが１のセグメントの処理を行う。

ここで、第１の受信フレーム処理部３１は、第２の受信フレーム処理部２２に受信フレームを伝達する際は、デスクリプタを用いる。システムメモリ１１１または他のメモリ上に例えばリングバッファなどで構成される複数のデスクリプタを格納できる領域を配置し、第１の受信フレーム処理部３１がフレーム毎にデスクリプタに、受信フレームの情報（例えば受信フレームが格納されているアドレスなど）に加えて、対応するソケット情報のアドレス（図４（Ａ）参照）などの情報を書き込み、第２の受信フレーム処理部２２がこれを読み出すことで、受信フレームおよびこれに関する情報の伝達を行っても良い。このようにしてソケット情報を用いて、第１の受信フレーム処理部３１と第２の受信フレーム処理部２２が協調して動作する。

状態管理部２６は、各通信部が通信可能かなど、各通信部の状態を管理する。状態管理部２６は、通信部の状態に変化があれば、出力先設定部２１に通知を行う。各通信部が通信可能かを判別する方法には主として２つある。それぞれ、各通信部のＰＨＹのリンク情報を監視する方法と、ＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）パケット等のパケットを送信して、その応答を監視する方法である。

リンク情報の監視は、各通信部のレジスタインタフェースに、バス経由でアクセスし、レジスタの値を確認することで行う。レジスタの値に基づき、リンクアップしているか否かを監視し、各通信部の状態を把握する。レジスタの値はＭＩＩ（Ｍｅｄｉａ Ｉｎｄｅｐｅｎｄｅｎｔ Ｉｎｔｅｒｆａｃｅ）などでＰＨＹからＭＡＣに伝達された値が反映される。

ＡＲＰパケットによる監視は、第２の送信フレーム処理部２３に、指定した通信部を用いてＡＲＰパケットを送信するように指示することで行う。その応答となるＡＲＰパケットを第２の受信フレーム処理部２２で受信し、状態管理部２６にその応答があったことを通知することで、送信した通信部が通信可能であることを把握する。ＡＲＰパケットの応答がない場合は、応答がなかったことを状態管理部２６に通知することで、その通信部が通信可能でないことを把握する。ＡＲＰパケットの送信は一例であり、ＰＩＮＧパケットなど、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）プロトコルのパケットを送信してもよい。

出力先選択部２５は、複数の通信部を仮想的に１つの通信部として扱う機能を有する。例えば通信部０、通信部１、通信部２、通信部３を１つの仮想通信部０として扱ったり、通信部０と通信部１を仮想通信部０として、通信部２と通信部３を仮想通信部１として扱ったりできる。Ｌｉｎｕｘ（登録商標）などでは、複数の通信部を１つの仮想通信部として扱うことをボンディングと呼び、仮想通信部のことをボンディングデバイスと呼ぶ。複数の通信部の一部をボンディングし、残りはボンディングしない構成も可能である。例えば、通信部０、通信部１をボンディングして１つの仮想通信部０とし、通信部２および通信部３はボンディングしないことも可能である。仮想通信部を構成する通信部をスレーブと呼ぶ。仮想通信部および（ボンディングしない）通信部にはＩＰアドレスを割り当てることができる。各スレーブにはＩＰアドレスを割り当てることができず、仮想通信部に割り当てられたＩＰアドレスが適用される。

それぞれの仮想通信部には、個別にモードを設定できる。モードの種類としては、例えば、フェイルオーバーモード、ＸＯＲ負荷分散モード、送信負荷分散モード、送受信負荷分散モードがある。

フェイルオーバーモードは、仮想通信部内の通信部のうち、優先的に送信する１つの通信部（スレーブ）を決め、その通信部が通信不可能と検出された場合には、他の通信部（他のスレーブ）に切り替えるモードである。

ＸＯＲ負荷分散モードは、送信元と宛先のＭＡＣアドレスやＩＰアドレス、ポート番号の排他的論理和を通信部の数で割った場合の剰余を用いて、仮想通信部において、送信する通信部を決定するモードである。例えば、仮想通信部内の通信部が４つあるとする。送信元と宛先のＭＡＣアドレスやＩＰアドレス、ポート番号の各ビット列のＸＯＲを計算する。求めたＸＯＲの値を通信部の数である４で割り、その剰余に対応する通信部を用いる。ここでは、送信元と宛先のＭＡＣアドレスやＩＰアドレス、ポート番号を用いたが、ＩＰアドレスとポート番号だけ用いるなど種々の変形が可能である。また、演算対象とするビットも、全ビットを用いずとも、任意の箇所の２ビットなどを利用してもよい。また、通信部を選択した後、その通信部のリンクが切断された場合には、次の値の通信部を用いるようにしてもよい。

送信負荷分散モードは、仮想通信部内の各通信部の送信負荷に応じて、送信する通信部を切り換えるモードである。例えば各通信部で送信されるデータ量の合計を、各通信部のカウンタから取得し、各通信部で送信される合計データ量の差またはばらつきを抑制する（すなわち送受信の負荷を分散させる）ように通信部を切り換えてもよい。または、ソケット情報に含まれる送信バイト数を利用して、各通信部で送信されるデータ量の合計を計算し、各通信部で送信される合計データ量の差またはばらつきを抑制するように通信部を切り換えてもよい。

送受信負荷分散モードは、仮想通信部内の各通信部の送受信の負荷に応じて、送信する通信部を切り換えるモードである。例えば各通信部で送受信されるデータ量の合計を、各通信部のカウンタから取得し、各通信部で送受信される合計データ量の差またはばらつきを抑制する（すなわち送受信の負荷を分散させる）ように通信部を切り換えてもよい。または、ソケット情報に含まれる送信バイト数と受信バイト数の合計を利用して、各通信部で送信されるデータ量の合計を計算し、各通信部で送信される合計データ量の差またはばらつきを抑制するように通信部を切り換えてもよい。

ここで述べた４つのモード以外のモードを設定してもよい。モードの設定や変更は、装置の管理者が、図示しない専用のユーティリティを用いて行うことができる。

出力先設定部２１は、ソケット情報記憶部３２内のソケット情報から第１の送信フレーム処理部３３によりフレームの出力先として決定される仮想通信部と、以下に述べる付加情報を、出力先選択部２５に通知して、当該ソケット情報に関連するフレームを、仮想通信部の通信部のうちどの通信部から送信するかを問い合わせる。付加情報は、仮想通信部のモードに応じて、適切な情報を取得して、通知する。第１の送信フレーム処理部３３がどのようにしてフレームの出力先を決定するかは後述する。

仮想通信部のモードがＸＯＲ負荷分散モードであれば、付加情報として、送信元と宛先のＭＡＣアドレス、ＩＰアドレス、ポート番号を、出力先選択部２５に通知する。そして、出力先設定部２１は、出力先選択部２５によって選択された通信部の識別情報を受け取り、ソケット情報の出力通信部識別子として、この通信部の識別情報を設定する。なお、仮想通信部のモードがフェイルオーバーモードであれば、予め出力先選択部には優先して使用される通信部が設定されているから、付加情報を伝達する必要はない。

出力先設定部２１は、第１の受信フレーム処理部３１、第２の送信フレーム処理部２３、状態管理部２６、出力先選択部２５からの指示を契機に、出力先選択部２５に問い合わせることにより、使用する通信部の識別情報を取得し、ソケット情報に出力通信部識別子を設定する。

より詳細に、第１の受信フレーム処理部３１は、ＴＣＰのコネクション状態がＥＳＴＡＢＬＩＳＨＥＤ状態になった場合に、そのソケット情報に出力通信部識別子を設定するように、出力先設定部２１に指示する。

第２の送信フレーム処理部２３は、アプリケーション２４からデータの送信指示があった場合に、そのデータを送信するソケットのソケット情報に出力通信部識別子を設定するように、出力先設定部２１に指示する。

状態管理部２６は、通信部の状態の変化（通信可から通信不可への変化など）を検知した際に、当該通信部、または当該通信部と同じ仮想通信部に属する他の通信部、またはこれらの両者を出力先としている全てのソケット情報の出力通信部識別子を再設定するように、出力先設定部２１に指示する。

出力先選択部２５は、仮想通信部のモードの変更がなされた時や、仮想通信部を構成する通信部に変更があった場合（例えば通信部が増減した場合）に、該当する全てのソケット情報（例えば、当該仮想通信部内の通信部を出力先に指定している全てのソケット情報）の出力通信部識別子を、再設定するよう出力先設定部２１に指示する。また、出力先選択部２５においてフェイルオーバーモードで優先する通信部が管理者により変更された場合や、送信負荷分散モードと送受信負荷分散モードであらかじめ設定された時間（１０秒など）が経過した場合も、同様にして、該当する全てのソケット情報の出力通信部識別子を再設定するよう出力先設定部２１に指示する。

第２の送信フレーム処理部２３は、アプリケーション２４、第２の受信フレーム処理部２２、または状態管理部２６からの指示により、フレームを送信するための処理を行う。

例えば、第２の送信フレーム処理部２３は、アプリケーション２４からは、コネクション確立などのイベントの指示が通知される。また、コネクション確立後にデータ送信の指示が通知される。

また、第２の送信フレーム処理部２３は、第２の受信フレーム処理部２２からは、第２の受信フレーム処理部２２でＩＣＭＰのエコー要求パケットを受信した場合などにＩＣＭＰのエコー応答パケットを送信する指示が通知される。また、第２の受信フレーム処理部２２でＴＣＰのＳＹＮセグメントを受信した場合に、ＳＹＮ／ＡＣＫセグメントを送信するよう指示が通知される。

また、第２の送信フレーム処理部２３は、状態管理部２６からは、各通信部の通信状態を調べるためにＡＲＰパケットの送信指示が通知される。

第２の送信フレーム処理部２３は、ソケット情報記憶部３２にアクセスできる。第２の送信フレーム処理部２３は、必要に応じて、ソケット情報の値を設定する機能を備える。例えば、シーケンス番号や、ＭＴＵ、送信データを格納するアドレス、送信データの長さ等を設定する。

第２の送信フレーム処理部２３は、指示されたフレームの送信にどの通信部を用いるべきか、すなわち、フレームの出力先を決定する。これは一般的にルーティングと呼ばれる動作で、基本的にはルーティングテーブルと呼ばれるテーブルに記載されているルールに従って、複数の通信部のうち、どの通信部を用いてフレームの送信を行うかを決定する。ここでいう複数の通信部は、仮想通信部、および仮想化されていない通信部の両方を指す。例えば通信部０と通信部１が１つの仮想通信部０として扱われ、通信部２および通信部３が仮想化されていない（どの仮想通信部にも属していない）とすると、複数の通信部とは、仮想通信部０と、通信部２および通信部３の３つである。

ルーティングテーブルは、例えば、宛先ＩＰアドレスと同じネットワークセグメントに属する通信部があれば、その通信部を用いて通信し、同じセグメントに属する通信部がなければ、予め定めた通信部を用いてデフォルトゲートウェイと通信するよう設定されている。デフォルトゲートウェイとは、送信すべき経路がわからない時に使用されるゲートウェイのことである。

ルーティングの結果、仮想通信部を用いて通信を行うと判定された場合には、出力先設定部２１に、出力先選択部２５に問い合わせて出力通信部識別子を設定するように指示する。出力先設定部２１は、出力先選択部２５に仮想通信部内のどの通信部（スレーブ）を使用するかを問い合わせ、出力先選択部２５から指定された通信部の識別情報を、ソケット情報の出力通信部識別子に設定する。あるいは、第２の送信フレーム処理部２３が、出力先選択部２５に問い合わせて出力通信部識別子を取得し、出力先設定部２１に、当該取得した出力通信部識別子をソケット情報に設定するよう指示してもよい。仮想通信部を用いる場合は、このように出力先選択部２５を用いて、出力する通信部を決定する。

なお、第２の送信フレーム処理部２３または出力先設定部２１は、出力先選択部２５に問い合わせる際には、仮想通信部の識別情報、および当該仮想通信部のモードに応じて必要な情報を、出力先選択部２５に通知する。必要な情報として、例えば、送信元と宛先のＭＡＣアドレス、送信元と宛先のＩＰアドレス、送信元と宛先のＴＣＰポート番号の全部または一部などがある。

一方、第２の送信フレーム処理部２３は、ルーティングの結果、仮想通信部ではない通信部を用いて通信を行うと判定した場合には、その通信部を、出力する通信部として決定する。

第２の送信フレーム処理部２３は、こうして決定した通信部（仮想通信部を用いて通信を行うと判定した場合は、出力先選択部２５に問い合わせて得た通信部、仮想通信部ではない通信部を用いて通信を行うと判定した場合には、その通信部）に対応した送信キューに、フレームの送信リクエストを追加する。

送信キュー０〜３は、それぞれ通信部１〜３に対応している。送信キュー０〜３は、第１の受信フレーム処理部３１、第２の送信フレーム処理部２３、または第１の送信フレーム処理部３３からの送信リクエストを受付け、受け付けた送信リクエストを内部で保持する。送信キューは、内部で保持している送信リクエストを、ＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ）で第１の送信フレーム処理部３３に出力する。

図５（Ａ）に、送信キューの構成、図５（Ｂ）に送信リクエストの構成を示す。

送信リクエストは、タイプフィールドとその他のフィールドとを含み、タイプフィールドの値（タイプ値）に応じて、その他のフィールドが異なる。その他のフィールドとしては、ソケット情報のアドレス、送信する確認応答番号、送信するウィンドウサイズ、フレームのアドレス、フレームの長さがあり、タイプ値に応じて、これらのうち１つもしくは複数のフィールドを用いる。図では、便宜上、これらのすべてのフィールドを示している。

タイプには“ＤＡＴＡ”、“ＦＲＡＭＥ”、“ＡＣＫ”がある。“ＤＡＴＡ”は、ＴＣＰセグメントでデータの送信を指示するタイプであり、“ＦＲＡＭＥ”は第２の送信フレーム処理部２３で生成されたフレームの送信を指示するタイプであり、“ＡＣＫ”は、ＡＣＫセグメントの送信を指示するタイプである。“ＤＡＴＡ”、“ＡＣＫ”の場合、送信するフレームは、第１の送信フレーム処理部３３でソケット情報を利用して生成されるが、“ＦＲＡＭＥ”の場合は、第２の送信フレーム処理部２３でソケット情報を利用してフレームが生成される。

上述したように、タイプ値ごとに、使用する送信リクエストのフィールドが異なる。タイプがＤＡＴＡの場合には、ソケット情報のアドレスのみが使用される。タイプがＦＲＡＭＥの場合には、フレームのアドレスと、フレームの長さのみが使用される。タイプがＡＣＫの場合には、ソケット情報のアドレスと、送信する確認応答番号と、送信するウィンドウサイズのみが使用される。

第１の受信フレーム処理部３１からは、タイプがＡＣＫの送信リクエストが入力される。この際、第１の受信フレーム処理部３１は、送信リクエストに、ＡＣＫセグメントを送信するソケット情報のアドレス（図４（Ａ）参照）と、送信する確認応答番号と、送信するウィンドウサイズを設定する。第１の受信フレーム処理部３１は、ソケット情報の出力通信部識別子が指す通信部に対応する送信キューに、この送信リクエストを出力する。第１の受信フレーム処理部３１は、ＴＣＰのデータの受信処理を行った場合などに、この送信リクエストを生成する。

また、第２の送信フレーム処理部２３からは、タイプがＦＲＡＭＥの送信リクエストが入力される。この際、第２の送信フレーム処理部２３は、送信リクエストに、送信するフレームが格納されているアドレスとフレームの長さを設定する。第２の送信フレーム処理部２３は、アプリケーション２４、第２の受信フレーム処理部２２、または状態管理部２６からの指示で、例えばＡＲＰパケットやＩＣＭＰパケット、ＴＣＰのＳＹＮセグメントや、ＳＹＮ／ＡＣＫセグメントなどのフレームを生成し、このフレームの送信リクエストを生成する。

さらに、第２の送信フレーム処理部２３からは、タイプがＤＡＴＡの送信リクエストが入力される。この際、第２の送信フレーム処理部２３は、ソケット情報に、アプリケーションから指定された送信データのアドレスと長さを設定し、さらにソケット情報の出力通信部識別子を設定するよう出力先設定部２１に指示し、そして送信リクエストのソケット情報のアドレスフィールドに、そのソケット情報のアドレスを設定する。第２の送信フレーム処理部２３は、アプリケーション２４からのデータ送信指示で、アプリケーション２４の指定したデータの送信リクエストを生成する。

第１の送信フレーム処理部３３は、各送信キューを、所定の順序で順番に選択し、選択した送信キューから送信リクエストを取り出す。そして、取り出した送信リクエストに含まれるタイプに応じたフレームを、当該送信キューに対応する通信部に出力する。第１の送信フレーム処理部３３は、最後まで選択したら、また最初から上記所定の順序で選択することを繰り返す。このような循環的な選択方法を、ラウンドロビンと呼ぶ。

図６に第１の送信フレーム処理部３３の動作例のフローチャートを示す。第１の送信フレーム処理部３３は、各送信キューからラウンドロビンで送信リクエストを取り出す（Ｓ１０１）。

第１の送信フレーム処理部３３は、取り出した送信リクエストのタイプが“ＤＡＴＡ”の場合、送信リクエストからソケット情報のアドレスを読み出し、ソケット情報記憶部３２から該当するソケット情報を読み出す（Ｓ１３１）。ソケット情報には、送信データの格納されたアドレスと送信データの長さが設定されており、長さが０でなければ、データの送信を行うことを決定する（Ｓ１３２、Ｓ１３３のＹＥＳ）。

第１の送信フレーム処理部３３は、ソケット情報から、相手のウィンドウサイズやＭＴＵ、輻輳ウィンドウサイズ（図４において図示せず）などを読み出し、送信可能なバイトを算出して、その分のデータをペイロードにのせ、ＴＣＰのデータセグメントを生成し、さらにＩＰ、イーサネットプロトコルのヘッダ生成やチェックサムなどの処理を行うことでフレームを生成する（Ｓ１３４）。

第１の送信フレーム処理部３３は、データを送信した分、送信した最大のシーケンス番号を加算したり、送信データの格納されたアドレスを進めたり、送信データの長さを減算するなどソケット情報を更新する（Ｓ１３５）。また、第１の送信フレーム処理部３３は、送信したＴＣＰセグメントのデータ量であるデータバイト数をカウントし、ソケット情報に記憶する機能も備える。第１の送信フレーム処理部３３は、送信キューに対応する通信部に、生成したフレームを出力する（Ｓ１３６）。ソケット情報の更新ステップとフレームの出力ステップの順序は逆でもよいし、並行して行ってもよい。

第１の送信フレーム処理部３３は、フレームを出力すると、当該ソケット情報と同じアドレスを、ソケット情報のアドレスフィールドに設定した、タイプがＤＡＴＡの送信リクエストを生成する。この際、送信リクエストには、ステップＳ１３５で更新されたソケット情報に基づき、送信データのアドレスと長さを設定する。第１の送信フレーム処理部３３は、生成した送信リクエストを、当該ソケット情報の出力通信部識別子が指す通信部に対応する送信キューに出力する（Ｓ１３７）。ステップＳ１３３〜Ｓ１３７までの処理を、送信データがなくなるまで繰り返す。

ステップＳ１３３〜Ｓ１３７までの処理により、出力通信部識別子が更新されない限り、同じ送信キューおよび通信部が繰り返し使用されて、データ送信が行われる。ただし、通信部の通信不可、仮想通信部のモード変更などの理由で、ソケット情報の出力通信部識別子が、出力先設定部２１により途中で、更新された場合は、使用される送信キューおよび通信部が変更される可能性がある。このように、同じソケットを使いつつも、使用する通信部を切り換えることができる。

一方、第１の送信フレーム処理部３３は、ステップＳ１０１で取り出した送信リクエストのタイプが“ＡＣＫ”の場合、送信リクエストから、ソケット情報のアドレスと、送信する確認応答番号、送信するウィンドウサイズを読み出す。ソケット情報のアドレスから該当するソケット情報を読み出し（Ｓ１２１）、読み出したソケット情報に含まれる送信した最大のシーケンス番号と、送信リクエストから読み出した、送信する確認応答番号、送信するウィンドウサイズを使って、ＴＣＰのＡＣＫセグメントを生成し、さらにＩＰ、イーサネットプロトコルのヘッダ生成やチェックサム計算を行ってフレームを生成する（Ｓ１２２）。第１の送信フレーム処理部３３は、生成したフレームを、送信リクエストを取り出した送信キューに対応する通信部に出力する（Ｓ１２３）。

また、第１の送信フレーム処理部３３は、ステップＳ１０１で取り出した送信リクエストのタイプが“ＦＲＡＭＥ”の場合、送信リクエストからフレーム情報として、フレームのアドレスと、フレームの長さを取り出す（Ｓ１１１）。フレーム情報に従ってフレームを読み出し、読み出したフレームを、送信リクエストを取り出した送信キューに対応する通信部に出力する（Ｓ１１２）。

以上、本実施形態によれば、ＣＰＵ１２１の出力先設定部２１によりソケット情報の出力通信部識別子を設定し、それを参照して、通信カード１３１（ハードウェア）の第１の送信処理部と第１の受信フレーム処理部３１が送信リクエストを出力する送信キューを決定する。ソケット情報の出力通信部識別子を変更することで、同じソケットでも使用する通信部を容易に切り換えることができる。つまり、使用する通信部の選択（出力通信部識別子の設定）などの処理をＣＰＵ１２１上で動作するソフトウェアで動作させ、通信カード１３１（ハードウェア）は、ＣＰＵ１２１で選択された通信部からフレームが出力されるように、送信リクエストを入力する送信キューを切り替えるよう動作する。これにより、ハードウェアの回路規模増大を抑えながら、耐障害性の向上や負荷分散と通信速度の向上を実現できる。

（第２の実施形態）
図７は、第２の実施形態に係わる通信システムのブロック図である。

本実施形態では、第１の実施形態に加えて、通信カード１３１側に、通信部の使用順序を定義した出力先切替えテーブル（出力先切替え情報）３４を備える。第１の送信フレーム処理部３３が、送信リクエストを送信キューから取り出して処理した後、この出力先切替えテーブル３４に従って、ソケット情報の出力通信部識別子を書き換える。書き換え後のソケット情報の出力通信部識別子で指定された通信部に対応する送信キューに、当該ソケットで送信する次のフレームを送信するための送信リクエストを生成して出力する。このように同じソケットで次に送信するフレームの送信リクエストを再び送信キューに出力することを、送信リクエストを書き戻す、と表現することがある。

この出力先切替えテーブル３４は、一例として、図１１に示すように定義されるＦＰＧＡで実現されるレジスタとして構成することができる。通信部の個数と同じ数のレジスタが存在し、各レジスタにはアドレスが設定されており、それぞれ図示のレジスタ名が付与されている。レジスタは３２ビット幅のデータを指定可能であり、それぞれ読み出しおよび書き込みの両方が可能である。ここでは、“ｎｅｘｔ＿ｔｏ＿ｅｎｑｕｅｕｅ０”、“ｎｅｘｔ＿ｔｏ＿ｅｎｑｕｅｕｅ１”、“ｎｅｘｔ＿ｔｏ＿ｅｎｑｕｅｕｅ２”、“ｎｅｘｔ＿ｔｏ＿ｅｎｑｕｅｕｅ３”の４つのレジスタ名が示される。

“ｎｅｘｔ＿ｔｏ＿ｅｎｑｕｅｕｅ０”のレジスタは、読み出したソケット情報の出力通信部識別子が０であった場合に、送信リクエストを書き戻す先の送信キューの識別子（通信部の識別子）を格納する。
“ｎｅｘｔ＿ｔｏ＿ｅｎｑｕｅｕｅ１”のレジスタは、読み出したソケット情報の出力通信部識別子が１であった場合に、送信リクエストを書き戻す先の送信キューの識別子（通信部の識別子）を格納する。
“ｎｅｘｔ＿ｔｏ＿ｅｎｑｕｅｕｅ２”のレジスタは、読み出したソケット情報の出力通信部識別子が２であった場合に、送信リクエストを書き戻す先の送信キューの識別子（通信部の識別子）を格納する。
“ｎｅｘｔ＿ｔｏ＿ｅｎｑｕｅｕｅ３”のレジスタは、読み出したソケット情報の出力通信部識別子が３であった場合に、送信リクエストを書き戻す先の送信キューの識別子（通信部の識別子）を格納する。

上記のレジスタ定義に基づき、仮想通信部でラウンドロビンモードを行う場合の動作を説明する。ラウンドロビンモードは、仮想通信部内の通信部間で、フレームを送信するたびに、通信部を順番に切り替えるモードである。

図８に、通信部０、通信部１、通信部２、通信部３の４つの通信部を含む仮想通信部でラウンドロビモードを行う場合の動作例を示す。図の左には、各レジスタの値の例が示されている。出力先切替えテーブルに従ってレジスタの値を参照することで、次に使用する通信部（送信キュー）が特定できる。ｎｅｘｔ＿ｔｏ＿ｅｎｑｕｅｕｅ０に１、ｎｅｘｔ＿ｔｏ＿ｅｎｑｕｅｕｅ１に２、ｎｅｘｔ＿ｔｏ＿ｅｎｑｕｅｕｅ２に３、ｎｅｘｔ＿ｔｏ＿ｅｎｑｕｅｕｅ３に０が指定されている。この場合、例えば、ある１つのソケットについて着目すると、送信リクエストが最初に送信キュー０に格納された場合、出力先切替えテーブルに従って、通信部０、通信部１、通信部２、通信部３、通信部０、通信部１…といったように、順次、使用する通信部が切り換えられて、ＴＣＰセグメントを含むフレームが送信される。

より詳細な第１の送信フレーム処理部３３の動作として、送信リクエストを各送信キューからラウンドロビンで取り出し、そのタイプが“ＤＡＴＡ”の場合、取り出した送信キューに対応する通信部に、データセグメントを含むフレームを出力する。この後、ソケット情報のシーケンス番号、送信データのアドレスと長さ等を更新するとともに、出力先切替えテーブル３４に従って、次に使用する通信部を特定し、ソケット情報の出力通信部識別子を書き換える。そして、書き換えた出力通信部識別子が指す通信部に対応する送信キューに、次にフレームを送信するためのタイプが“ＤＡＴＡ”でソケット情報のアドレスフィールドには同じソケット情報のアドレスを指定した送信リクエストを追加する。この際、送信リクエストにおける送信データのアドレスと長さを、更新後のソケット情報に基づき再設定する。タイプが“ＡＣＫ”の送信リクエストを取り出した場合は、取り出した送信キューに対応する通信部に、ＡＣＫセグメントを含むフレームを出力した後、ソケット情報のシーケンス番号を更新するとともに、出力先切替えテーブル３４に従って、ソケット情報の出力通信部識別子を書き換える。これによりＴＣＰのセグメントを送信するたびに、通信部を切り替えて送信を行うことができる。

具体的な動作例として、図８に示すように、送信キュー０からタイプが“ＤＡＴＡ”送信リクエストを取り出した場合（Ｓ２０１）、フレームを出力し（Ｓ２０２）、ソケット情報の出力通信部識別子を出力先切替えテーブル３４に従って１に書き換えた後、送信データの格納されたアドレスや送信データの長さなどの、ソケット情報の他のフィールドを更新し、同じソケットの次に送信するデータフレームの送信リクエストを送信キュー１に追加する（Ｓ２０３）。この送信リクエストは、ラウンドロビンに従って、後に送信キュー１から取り出されることになる（Ｓ２０４）。この送信リクエストに基づき、フレームを出力し（Ｓ２０５）、ソケット情報の出力通信部識別子を出力先切替えテーブル３４に従って２に書き換え、ソケット情報の他のフィールドを更新し、次のフレームの送信のため、同じソケットの、タイプが“ＤＡＴＡ”の送信リクエストを送信キュー２に追加する（Ｓ２０６）。この際、送信リクエストの送信データのアドレスと長さを、更新後のソケット情報に基づき再設定する。以降、同様にして、使用する送信キューおよび通信部が順次、循環的に切り換えられていく（Ｓ２０７、Ｓ２０８、Ｓ２０９、Ｓ２１０、Ｓ２１１、Ｓ２１２）。

ここで、例えば、データ送信中に通信部２が、リンク切断により通信できなくなったとする。この場合には、状態管理部２６がそのことを検知し、出力先選択部２５によりｎｅｘｔ＿ｔｏ＿ｅｎｑｕｅｕｅ１に３を指定するように、出力先切替えテーブル３４を更新する。この後、出力先設定部２１により、ソケット情報の出力通信部識別子を、通信部２以外の通信部を指すように書き換える。更新後の出力先切替えテーブル３４を用いて、第１の送信フレーム処理部３３が処理を行うと、図９に示すような動作となる。すなわち、送信キュー１から送信リクエストが取り出された場合（Ｓ２３１）、これまでと同様に、この送信リクエストに基づき、フレームを出力する（Ｓ２３２）。次に、ソケット情報の出力通信部識別子を出力先切替えテーブル３４に従って、（２ではなく）３に書き換え、ソケット情報の他のフィールドを更新し、同じソケットの次に送信するデータフレームの送信リクエストを（送信キュー２ではなく）送信キュー３に追加する（Ｓ２３３）。この動作により、通信部０、通信部１、通信部３、通信部０、・・・といったように、通信ができない通信部２を除いて、ラウンドロビンで送信が行われる。通信部２が、再び通信可能な状態に戻った場合は、状態管理部２６がそのことを検知し、出力先選択部２５により、ｎｅｘｔ＿ｔｏ＿ｅｎｑｕｅｕｅ１を２に指定する。これにより、再度、通信部２も使用してラウンドロビンで送信ができる。

図８および図９では、通信部０〜３を１つの仮想通信部としてラウンドロビンモードで動作させる場合を示した。図１０に、通信部０と通信部１を仮想通信部０としてラウンドロビンモードで、通信部２と通信部３を仮想通信部１としてＸＯＲ負荷分散モードで動作させる例を示す。

この場合は、図１０の左に示すように、出力先切替えテーブル３４を、ｎｅｘｔ＿ｔｏ＿ｅｎｑｕｅｕｅ０は１、ｎｅｘｔ＿ｔｏ＿ｅｎｑｕｅｕｅ１は０、ｎｅｘｔ＿ｔｏ＿ｅｎｑｕｅｕｅ２は２、ｎｅｘｔ＿ｔｏ＿ｅｎｑｕｅｕｅ３は３と設定すればよい。仮想通信部０を使った通信では、通信部０と通信部１が交互に切り換えられるが、仮想通信部１を使った通信では、通信部の切り替えは行われない。

より詳細に、仮想通信部０を使った通信では、送信キュー０から送信リクエストを取り出し（Ｓ２４１）、通信部０からフレームを送信した後（Ｓ２４２）、同じソケットの次に送信するデータフレームの送信リクエストが送信キュー１に追加される（Ｓ２４３）。後に、ラウンドロビンでこの送信リクエストが送信キュー１から取り出され（Ｓ２４４）、通信部１からフレームが送信され（Ｓ２４５）、同じソケットの次の送信するフレームの送信リクエストが送信キュー０に追加される（Ｓ２４６）。このように、通信部０、通信部１、通信部０、通信部１・・・といったように、ラウンドロビンで負荷分散しながら、フレームの送信を行うことができる。なお、ここでは説明を省略したが、これらの処理でも、前述と同様に、出力先切替えテーブル３４に従って、ソケット情報が更新される。

また、仮想通信部１を用いた通信では、出力先設定部２１によって設定されたキューに、同じソケットの次の送信するフレームの送信リクエストが書き戻される。よって、出力先選択部２５が設定したルール通りに負荷分散させることができる。

以上、本実施形態によれば、出力先選択部２５で出力先切替えテーブル３４に出力通信部識別子の書き換えのルールを設定し、第１の送信フレーム処理部３３でフレーム送信毎に、出力先切替えテーブル３４に従って、該当するソケット情報の出力通信部識別子を書き換える。そして、書き換え後の出力通信部識別子が示す通信部に対応する送信キューに、同じソケットの次に送信するフレームの送信リクエストを追加する。これにより、ＦＰＧＡの実装回路規模の増大を抑えながら、仮想通信部にラウンドロビンモードを適用できる。また、耐障害性の向上や負荷分散と通信速度の向上を実現できる。

（変形例１）
第１および第２の実施形態の通信カード１３１に搭載されるＦＰＧＡの代わりに、マイクロプロセッサやＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）を用いてもよい。また、ソケット情報記憶部３２は、通信カード１３１に搭載されるメモリの代わりに、システムメモリ１１１に設けてもよい。

（変形例２）
また、第１および第２の実施形態において、各通信部は、各々異なるデータリンク層プロトコルを用いることが可能である。例えば、全ての通信部がイーサネットプロトコルを用いてもよいし、３つの通信部がイーサネットプロトコルで、１つの通信部はＩＥＥＥ８０２．１１ａｃなどの無線ＬＡＮ規格のプロトコルを用いてもよい。

（変形例３）
また、第１および第２の実施形態では、送信負荷分散モードや送受信負荷分散モードで動作する場合に、ソケット情報に送信バイト数と受信バイト数を格納する例を示した。送信負荷分散モードや送受信負荷分散モードを実現する別の例として、以下の方法も可能である。通信カード１３１上のメモリを用いて、宛先ＩＰアドレスごとのハッシュテーブルを作成し、第２の送信フレーム処理部２３または第１の送信フレーム処理部３３で、宛先ＩＰアドレスごとに送信バイト数または受信バイト数またはこれらの両方をカウントしてハッシュテーブルに格納する。状態管理部２６および出力先選択部２５は、この情報を用いて負荷分散を行ってもよい。

（変形例４）
また、第１および第２の実施形態では、ＴＣＰを用いる例を示したが、ＵＤＰなどの別のプロトコルを用いることも可能である。ＵＤＰでは、コネクションの形成を行わず、ＡＣＫパケットの送信もないため、ソケット情報の出力通信部識別子を用いなくとも、ラウンドロビンモードで動作させることができる。

ソケット情報の出力通信部識別子を用いない場合、出力通信部識別子の代わりに送信キューの識別子を用いて動作させる。最初は、例えば、あるソケット情報に対して決定された仮想通信部に対し、出力先選択部２５が選択した通信部、あるいは任意に決めた通信部に対応する送信キューに送信リクエストを追加する。第１の送信フレーム処理部３３は、各送信キューから送信リクエストを取り出し、ＵＤＰ、ＩＰおよびイーサネットプロトコルの処理を行って、取り出した送信キューに対応する通信部にフレームを出力する。この時、送信するべきＵＤＰデータグラムが複数のＩＰフラグメントパケットに分割されて送信される場合には（ＵＤＰソケットにＭＴＵよりも大きなデータを書き込んだ場合など）、出力先切替えテーブル３４に従って（第２の実施形態の場合）定まる送信キューに、同じソケットの次にフレームを送信するための送信リクエストを追加する（ソケット情報の出力通信部識別子は用いない）。このようにすることで、ＵＤＰデータグラムが複数のＩＰのフラグメントパケットに分割されて送信される場合にも、ＩＰのフラグメントパケットの送信ごとに、通信部を切り替えて送信できる。第１の実施形態の場合で、ＵＤＰの送信を行い、使用する通信部を変える場合は、次の送信リクエストを生成する前に送信リクエストの出力先を変更後の送信キューに切り換えればよい。

なお、例えばソケット情報における送信データのアドレスと長さを、配列やリストで保持できるようにしておき、アプリケーション２４からＵＤＰデータグラムの送信要求を受けると、当該配列やリストに追加していき、第１の送信フレーム処理部３３が当該配列やリストの要素を先頭側から順に、送信処理を行うようにしてもよい（ＴＣＰでも同様にすることも可能である）。

（変形例５）
第１および第２の実施形態では、送信キューの個数は通信部の個数と同一であったが、通信部の個数と送信キューの個数は異なってもよい。例えば、１つの送信キューと４つの通信部などの構成をとり、ソケット情報の出力通信部識別子を用いて制御してもよい。

（変形例６）
また、第１および第２の実施形態では、第１の送信フレーム処理部３３が１個である例を示したが、例えば、通信部４個に対して、第１の送信フレーム処理部３３を２個にし、それぞれが、異なる２つの通信部に対してフレームを出力する構成にしてもよい。

（変形例７）
また、第２の実施形態では、出力先切替えテーブルをＦＰＧＡのレジスタで実現する例を示したが、これはシステムメモリ１１１や通信カードのメモリで実現してもよい。これらレジスタ、システムメモリ１１１、通信カードのメモリは、出力先切替えテーブル（出力先切替え情報）を記憶する記憶装置の一例である。

なお、この通信装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、通信装置の各処理ブロックを、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現できる。このとき、通信装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、ＣＤ−ＲＯＭなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、通信装置およびＣＰＵ内の記憶部および送信キューは、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現できる。

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

１０１：映像配信サーバ
１１１：システムメモリ
１２１：ＣＰＵ
１３１：通信カード
１４１：ストレージ
１５１：チップセット
２０１：ネットワーク
３０１：視聴端末
２１：出力先設定部
２２：第２の受信フレーム処理部
２３：第２の送信フレーム処理部
２４：アプリケーション
２５：出力先選択部
２６：状態管理部
３１：第１の受信フレーム処理部
３２：ソケット情報記憶部
３３：第１の送信フレーム処理部

Claims (19)

1. ネットワークに接続される複数の通信部を備えた通信装置に対するプロセッサであって、
   前記通信装置における前記複数の通信部の状態を管理する管理部と、
   前記通信部の状態に基づき、前記通信装置が前記ネットワークを介して通信する相手装置に対して生成されたソケット情報に対する通信部を前記複数の通信部から選択し、選択した通信部の識別情報を、前記ソケット情報と対応づけて、第１記憶装置に格納し、前記第１記憶装置における前記ソケット情報に対応する前記識別情報を、前記複数の通信部の状態に基づき更新する選択部を備え、
   前記ソケット情報に関連するフレームの送信リクエストに基づく前記フレームの送信処理を前記第１記憶装置において前記ソケット情報に対応する前記識別情報が示す前記通信部を用いて行うように前記通信装置を制御する、プロセッサ。
2. 前記プロセッサは、前記フレームの送信リクエスト毎に前記ソケット情報に対応する前記識別情報が示す前記通信部を用いて前記フレームの送信処理を行うように前記通信装置を制御する
   請求項１に記載のプロセッサ。
3. 前記選択部は、２つ以上の通信部を、前記通信装置が予め定めた使用順序で用いるように前記識別情報を更新する
   請求項１ないし２のいずれか一項に記載のプロセッサ。
4. 前記ソケット情報に関連するフレームにより送信または送受信されるデータ量を計算する手段を備え、
   前記選択部は、前記手段により計算されるデータ量に基づき、前記複数の通信部間で送信または送受信の負荷が分散するように、前記識別情報を更新する
   請求項１ないし３のいずれか一項に記載のプロセッサ。
5. 前記管理部は、前記複数の通信部のそれぞれで送信または送受信されるデータ量を管理し、
   前記選択部は、前記管理部で管理される各通信部の送信または送受信のデータ量に基づき、前記通信部間で送信または送受信の負荷が分散されるように、前記識別情報を更新する
   請求項１ないし４のいずれか一項に記載のプロセッサ。
6. 前記管理部は、前記複数の通信部の通信可否をそれぞれ監視し、
   前記選択部は、各通信部の通信可否に応じて、前記識別情報を更新する
   請求項１ないし５のいずれか一項に記載のプロセッサ。
7. 前記識別情報が示す通信部で前記フレームの送信を行うように前記通信装置を設定する
   請求項６に記載のプロセッサ。
8. 前記ソケット情報は、前記通信装置のＩＰアドレス、前記相手装置のＩＰアドレス、前記通信装置のポート番号、前記相手装置のポート番号の組を含む
   請求項１ないし７のいずれか一項に記載のプロセッサ。
9. ネットワークを介して相手装置と通信する通信装置であって、
   前記ネットワークに接続される複数の通信部と、
   前記相手装置に対して生成されたソケット情報と、前記複数の通信部からプロセッサにより選択された通信部の識別情報とを対応づけて格納し、前記識別情報は、前記プロセッサにより前記複数の通信部の状態に基づき更新される第１記憶装置にアクセスする手段と、
   前記ソケット情報に関連するフレームの送信リクエストに基づき、前記フレームを送信する通信部を、前記第１記憶装置に格納されている前記ソケット情報に対応する前記識別情報に基づき決定し、決定した通信部から前記フレームの送信処理を行う送信フレーム処理部と
   を備えた通信装置。
10. 前記送信フレーム処理部は、前記フレームの送信リクエスト毎に、前記フレームを送信する通信部を、前記ソケット情報に対応する前記識別情報に基づき決定する
    請求項９に記載の通信装置。
11. 前記プロセッサにより選択された通信部は、前記プロセッサが前記複数の通信部の通信可否をそれぞれ監視し、各通信部の通信可否に応じて選択した通信部である
    請求項９または１０に記載の通信装置。
12. 前記複数の通信部に対応し、前記ソケット情報に関連するフレームの送信リクエストを格納する複数の送信キューを備え、
    前記ソケット情報に関連するフレームの送信リクエストを、前記識別情報が示す前記通信部に対応する送信キューに格納し、
    前記送信フレーム処理部は、各送信キューから取り出した送信リクエストにしたがって、各送信キューに対応する通信部を用いて、前記ソケット情報に関連するフレームの送信を行う
    請求項９に記載の通信装置。
13. 前記複数の通信部に対応し、前記ソケット情報に関連するフレームの送信リクエストを格納する複数の送信キューを備え、
    前記ソケット情報に関連するフレームの送信リクエストを、前記識別情報が示す前記通信部に対応する送信キューに格納し、
    前記送信フレーム処理部は、各送信キューから取り出した送信リクエストにしたがって、各送信キューに対応する通信部を用いて、前記ソケット情報に関連するフレームの送信を行い、前記送信リクエストの処理後、前記第１記憶装置にアクセスして、前記ソケット情報に関連する前記識別情報を取得し、前記識別情報に示される前記通信部に対応する送信キューに、前記ソケット情報に関連する次のフレームの送信リクエストを出力する
    請求項９に記載の通信装置。
14. 前記第１記憶装置は、前記通信装置内に設けられた
    請求項９ないし１３のいずれか一項に記載の通信装置。
15. 通信カードとして構成された
    請求項９ないし１４のいずれか一項に記載の通信装置。
16. 前記ソケット情報は、前記通信装置のＩＰアドレス、前記相手装置のＩＰアドレス、前記通信装置のポート番号、前記相手装置のポート番号の組を含む
    請求項９ないし１５のいずれか一項に記載の通信装置。
17. ネットワークを介して相手装置と通信を行う通信システムであって、
    前記ネットワークに接続される複数の通信部を有する通信装置と、
    前記通信装置における前記複数の通信部の状態を管理する管理部と、前記相手装置に対して生成されたソケット情報に対して、前記複数の通信部から通信部を選択し、選択した通信部の識別情報を、前記ソケット情報と対応づけて、第１記憶装置に格納し、前記第１記憶装置における前記ソケット情報に対応する前記識別情報を、前記複数の通信部の状態に基づき更新する選択部と、含むプロセッサと、を備え、
    前記通信装置は、前記ソケット情報に関連するフレームの送信リクエストに基づき、前記フレームを送信する通信部を、前記第１記憶装置に格納されている前記ソケット情報に対応する前記識別情報に基づき決定し、決定した通信部から前記フレームの送信処理を行う送信フレーム処理部を含む
    通信システム。
18. ネットワークを介して、相手装置と通信を行う通信方法であって、
    前記ネットワークに接続される複数の通信部を備えた通信装置における前記複数の通信部の状態を管理するステップと、
    前記相手装置に対して生成されたソケット情報に対して、前記複数の通信部から通信部を選択するステップと、
    選択した通信部の識別情報を、前記ソケット情報と対応づけて、第１記憶装置に格納するステップと、
    前記第１記憶装置における前記ソケット情報に対応する前記識別情報を、前記複数の通信部の状態に基づき更新するステップと、
    前記ソケット情報に関連するフレームの送信リクエストに基づき、前記フレームを送信する通信部を、前記第１記憶装置に格納されている前記ソケット情報に対応する前記識別情報に基づき決定し、決定した通信部から前記フレームの送信処理を行うステップと、
    を備えた通信方法。
19. ネットワークに接続される複数の通信部を備えた通信装置における前記複数の通信部の状態を管理する管理ステップと、
    前記通信装置が前記ネットワークを介して通信する相手装置に対して生成されたソケット情報に対して、前記複数の通信部から通信部を選択するステップと、
    選択した通信部の識別情報を、前記ソケット情報と対応づけて、第１記憶装置に格納するステップと、
    前記第１記憶装置における前記ソケット情報に対応する前記識別情報を、前記複数の通信部の状態に基づき更新するステップと、
    前記ソケット情報に関連するフレームの送信リクエストに基づき、前記フレームを送信する通信部を、前記第１記憶装置に格納されている前記ソケット情報に対応する前記識別情報に基づき決定し、決定した通信部から前記フレームの送信処理を行うステップと、
    をコンピュータに実行させるためのプログラム。

Images