JP2008028767A - ネットワークカードおよび情報処理装置 - Google Patents

Abstract

【課題】 ストリーミングデータを効率的に送出する技術を提供する。
【解決手段】 ホストコネクタとネットワークコネクタとを備えるネットワークカードであって、ネットワークコネクタを介して送信することになるデータを、ホストコネクタを介して第１サイズよりも大きな第２サイズのブロックデータを単位として受信する受信手段と、受信したブロックデータを一時的に記憶するためのバッファメモリと、第１サイズ以下となるデータフレームを生成し、ネットワークコネクタに接続されたネットワーク上に該データフレームを送信する送信手段とを備える。
【選択図】図４

Description

本発明は、データ送出技術、特に、広帯域なストリーミングデータを効率的に送出する技術に関するものである。

近年、ビデオオンデマンド（ＶＯＤ）などストリーミングサービスが実現されている。また、近年のアクセス網の広帯域化により、配信サーバから送出されるビデオストリーミングデータ１つあたりの帯域も増大している。さらに、今後いわゆるＨＤ（高精細）映像の配信などにより、さらなる広帯域化が見込まれる。配信サーバからデータ送出レートが増大するにしたがい、当該配信サーバの内部バス（たとえばＰＣＩなど）の利用率も増大する傾向にある。

一般的にネットワークインタフェースにはそれぞれの規格に応じて転送可能な最大のデータ長（ＭＴＵ）が規定されている。たとえばＩＥＥＥ８０２．３シリーズ規格としても知られるイーサネット（登録商標）においては最大約１．５ｋバイトである。そのため、一般的にはデバイスドライバは、内部バスで伝送可能なデータ長が十分大きい場合であっても、ネットワーク上に送信するデータを上述のＭＴＵを超えないような大きさのデータに分割した後、内部バスを経由してインタフェースボードに転送する。なお、この分割のことをフラグメント処理と呼ぶ。その後、ボード上のＭＡＣ／ＰＨＹにより処理が行われネットワーク上に送出される。

一方、ストリーミングサービスでは、データ量が多いことからネットワーク上でのパケット破棄などが発生し得る。その場合に受信側から再送要求を出さなくともよいよう、配信サーバにおいて前方誤り訂正（ＦＥＣ）符号化が利用される。たとえば、特許文献１に開示されるような符号化が利用されている。
国際公開番号第ＷＯ２００５／１１２２５０号

内部バスにおいては、一般的には、ストリーミングデータの送信単位に合わせて十分大きなデータ単位（データ長）で転送することが可能である。しかしながら、上述したようにＭＴＵによる制限から結果として内部バス上を流れるデータ長は小さいものとなってしまう。そのため、ストリーミングデータの送信においては、バスの混雑が発生しやすく、フラグメント処理によるＣＰＵパワーも必要とされるという問題点がある。

また、大量のデータに対して特許文献１に開示されているような符号化処理を実行するためには更なるＣＰＵパワーを必要とする。

本発明は上述した問題点に鑑みなされたものであり、これらの問題点の少なくとも１つを解決することを目的とする。

上述した問題点の少なくとも１つを解決するため本発明のネットワークカードは以下の構成を備える。

即ち、ホスト装置に設けられたバスコネクタに接続するためのホストコネクタと、ネットワークに接続するためのネットワークコネクタとを備えるネットワークカードであって、前記ネットワークコネクタを介して送信可能なデータフレームの最大サイズを第１サイズとしたとき、前記ネットワークコネクタを介して送信することになるデータを、前記ホストコネクタを介して前記第１サイズよりも大きな第２サイズのブロックデータを単位として受信する受信手段と、前記受信手段において受信したブロックデータを一時的に記憶するためのバッファメモリと、前記バッファメモリから、送信するデータフレームに含めるためのデータを読み込み、前記第１サイズ以下となるデータフレームを生成して、前記ネットワークコネクタに接続されたネットワーク上に該データフレームを送信する送信手段とを備える。

上述した問題点の少なくとも１つを解決するため本発明の情報処理装置は以下の構成を備える。

即ち、バスにより接続されたホスト処理部とネットワーク処理部を備え、ネットワークにストリーミングデータを送出する情報処理装置であって、前記ホスト処理部は、ストリームデータを入力するデータ入力手段と、少なくとも前記ストリームデータを、前記ネットワークにおいて転送可能なデータフレームの最大サイズを第１サイズとしたとき、該第１サイズよりも大きな第２サイズのブロックデータを単位として、前記バスを介して前記ネットワーク処理部に転送するバス転送手段と備え、前記ネットワーク処理部は、前記バス転送手段から前記バスを介して送信されたブロックデータを受信する受信手段と、前記受信手段において受信したブロックデータを一時的に記憶するための記憶手段と、前記記憶手段から、送信するデータフレームに含めるためのデータを読み込み、前記第１サイズ以下となるデータフレームを生成して、前記ネットワークコネクタに接続されたネットワーク上に該データフレームを送信する送信手段とを備える。

本発明によれば、ストリーミングデータを効率的に送出する技術を提供することができる。

以下に、図面を参照して、この発明の好適な実施の形態を詳しく説明する。なお、これらの実施の形態はあくまで例示であり、この発明の範囲をそれらのみに限定する趣旨のものではない。

（第１実施形態）
本発明に係るデータ送出装置の第１実施形態として、汎用のＰＣおよびネットワークボードにより構成されたストリーミング配信装置を例に挙げて以下に説明する。

＜概要＞
第１実施形態のストリーミング配信装置においては、従来ＰＣ本体のＣＰＵがデバイスドライバプログラムを実行することにより行っていたフラグメント処理をネットワークボード上のハードウェアにより処理を行う。その結果、ＰＣ本体のＣＰＵにおける負荷低減を実現するとともに、バスを介したネットワークボードへのデータ転送をより大きなデータ長により行うことが出来、バス使用効率の向上を実現する。

＜システム構成および装置構成＞
図１は、ストリーミング配信システムの全体構成の概念図を示す。

１００はストリーミング配信サーバ、１１０ａ、１１０ｂはストリーミング受信装置である。また、１０１、１１１ａおよび１１１ｂは、それぞれ、配信サーバ１００、受信装置１１０ａ、１１０ｂが属するネットワークセグメントである。各々のネットワークセグメント１０１、１１１ａ、１１１ｂは、ルータ１０２、１１２ａ、１１２ｂおよびコアネットワーク１２０を介して接続されている。なお、以降では、各ネットワークセグメント間のデータ転送には、インターネットプロトコル（ＩＰ）が使用されるものとして説明を行う。

配信サーバ１００は、受信端末１１０ａ、１１０ｂに対してストリームデータをＲＴＰ／ＵＤＰ／ＩＰの形式でパケット化し送信する。ここ、ＲＴＰはリアルタイムトランスポートプロトコルを意味し、ＵＤＰはユーザデータグラムプロトコルを意味する。なお、配信サーバ１００は、ユニキャストで各受信端末にストリーミング配信しても良いし、マルチキャストで配信しても良い。また、いわゆるビデオオンデマンド（ＶＯＤ）サービスのように各受信端末からの配信要求に基づいて配信を開始しても良い。

図２は、第１実施形態に係る配信サーバの内部構成を示す図である。図に示されるように、配信サーバ１００は、ＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、ＨＤＤ２０４、ユーザＩ／Ｆ２０５およびネットワーク（ＮＷ）ボード２００から構成されており、各部は内部システムバス２１０により相互に接続されている。

ＣＰＵ２０１は、ＲＯＭ２０３やＨＤＤ２０４に記憶される各種プログラムを実行することにより、各部を制御、または図４で後述する各機能部を実現する。ＲＯＭ２０３は、配信サーバ１００の起動時等に実行されるプログラム等を記憶している。ＲＡＭ２０２は、ＣＰＵ２０１により実行される各種プログラムや各種データの一時記憶を行う。ＨＤＤ２０４は、大容量の記憶装置であり、各種プログラムや各種データファイルの記憶を行う。プログラムには、オペレーティングシステム（ＯＳ）プログラムやストリーミング配信プログラムが含まれる。ユーザＩ／Ｆ２０５は不図示のキーボードやマウスなどのユーザ入力装置、および、不図示のディスプレイなどの表示出力装置である。

内部システムバス２１０としては一般的なＰＣＩバスを含む汎用バスを想定するが、もちろん専用のバスであっても良い。ただし、バス２１０における転送速度はネットワーク１０１における転送速度よりも大きく、転送可能なデータ長はネットワーク１０１におけるデータ長よりも長いものとする。

なお、以降では説明を簡単にするため、配信サーバ１００において、ネットワーク（ＮＷ）ボード２００を”ＮＷボード側”、それ以外の部分を”サーバ本体側”と呼ぶ場合がある。

図３は、第１実施形態に係る配信サーバ内のネットワークボードの内部構成を示す図である。図に示されるように、ネットワークボード２００は、パケットハンドラ３０１、メモリ３０２、メモリコントローラ３０３およびバスＩ／Ｆ３１０から構成されている。

メモリ３０２は、バス２１０およびバスＩ／Ｆ３１０を介してサーバ本体側から受信したデータを、一時的に格納する部分であり、内部にパケットバッファ３０２ａを備えている。なお、詳細は後述するがパケットバッファ３０２ａはストリーム毎に領域が確保される。

パケットハンドラ３０１は、メモリ３０２に一時記憶されたデータをネットワーク１１０に適したデータ形式で送信する回路部である。具体的には、メモリ３０２に一時記憶されたデータに対し、後述するフラグメント処理やスムージング処理を行った後、ネットワーク１１０に出力する。

＜機能構成および動作＞
図４は、第１実施形態に係る配信サーバの機能構成を示す図である。

配信サーバ１００は、データ送信に関連する機能部として、入力部４０１、バス転送部４０２、フラグメント処理部４０３およびスムージング処理部４０４を備えている。なお、入力部４０１およびバス転送部４０２の各機能部は、サーバ本体側のＣＰＵ２０１が各種プログラムを実行することにより実現される。一方、フラグメント処理部４０３およびスムージング処理部４０４の各機能部は、ＮＷボード側のハードウェアにより実現される。以下、各機能部について説明を行う。

なお、以下では説明を簡単にするために各処理部のＲＴＰ／ＵＤＰ／ＩＰの形式のストリーミングデータに対しての処理についてのみ説明を行う。その他のデータについては、従来通りの処理がなされる。なお、パケットの区別はＩＰヘッダに記載されるポート番号に基づいて行っても良いし、ただ単にパケットのデータ長に基づいて行っても良い。

入力部４０１は、ネットワークボード２００を介して送信することになるストリーミングファイルを入力する機能部である。具体的には、ＣＰＵ２０１がストリーミング配信ソフトウェアを実行することにより、ＨＤＤ２０４などに格納されるストリーミングデータをＲＡＭ２０２に読み込むことにより実現される。なお、入力部４０１は、請求項における入力手段に相当する。

バス転送部４０２は、入力部４０１によりＲＡＭ２０２上に入力されたストリーミングデータを予め指定された固定長データに分割した後、ＲＴＰ／ＵＤＰ／ＩＰの形式として格納し、バス２１０を介してＮＷボード側に転送する機能部である。具体的には、ＣＰＵ２０１が、ＩＰスタックプログラムおよびＮＷボード２００のデバイスドライバプログラムを実行することにより実現される。なお、バス転送部４０２は、請求項におけるバス転送手段に相当する。

ただし、背景技術で説明した場合と異なり、転送されるストリーミングデータパケットはネットワーク１０１に送出可能なデータ長に比較し大きいものとなっている。例えば、ネットワーク１０１がイーサネット（登録商標）である場合、つまり、最大のデータ長（ＭＴＵ）（請求項における第１サイズ）が約１．５ｋバイトであっても、例えば３２ｋバイトなどの大きなデータブロック（請求項における第２サイズ）として転送する。

なお、一般にアプリケーションとＩＰスタックプログラムとの間、および、ＩＰスタックプログラムとデバイスドライバとの間のデータ形式については仕様が定められているため変更を行うには大きな設計変更を伴うことになる。しかし、上述のような、デバイスドライバとハードウェアとの間のデータ形式は比較的自由に設計が可能であることに注意されたい。

詳細は後述するが、データ（データブロック）において、ＩＰ、ＵＤＰ、ＲＴＰの各ヘッダを除いたペイロード部を、ストリームデータの最小処理単位の整数倍（あるいは２の累乗倍）に相当するデータ長とすることが好適である。

フラグメント処理部４０３は、バス２１０（バスコネクタ）を介してバス転送部４０２から転送されたデータ（データブロック）をネットワーク１０１に送出可能なデータ長に分割する機能部である。具体的には、不図示のホストコネクタを介してメモリ３０２に格納されたデータブロックを、ネットワーク１０１のＭＴＵ以下となるデータ長に分割し、分割されたデータに対応するＩＰ、ＵＤＰ、ＲＴＰの各ヘッダを再生成する。そして、ネットワーク１０１に直接送信可能なデータ長のＩＰパケットをパケットバッファ３０２ａに格納する。なお、バスＩ／Ｆ３１０は、請求項における受信手段、メモリ３０２は、請求項におけるバッファメモリまたは記憶手段に相当する。また、フラグメント処理部４０２は、請求項における送信手段の一部を構成し、パケットハンドラ３０１が送信手段に相当する。

なお、ＩＰ、ＵＤＰ、ＲＴＰの各ヘッダを再生成とは具体的には以下の処理を言う。ＩＰヘッダには当該ＩＰパケットに含まれるデータのデータ長（ペイロード長）が記載されている。また、ＵＤＰヘッダには当該ＵＤＰパケットに含まれるデータのデータ長および当該データのチェックサムが記載されている。さらに、ＲＴＰヘッダには当該ＲＴＰパケットに含まれるデータのシーケンス番号およびタイムスタンプが記載されている。そのため、フラグメント処理部４０３によるフラグメント処理の結果、ＲＴＰパケットは分割されることから、これらの各ヘッダ内に記載された情報を、分割されたパケットに合わせて算出し、ヘッダ情報を更新するのである。なお、バス転送部４０２から転送されたデータ（データブロック）において、ＩＰ、ＵＤＰ、ＲＴＰの各ヘッダを除いたペイロード部を等分割とすることによりヘッダ情報の算出が簡単になる。そのため、前述のように、データブロックのペイロード部をストリームデータの最小処理単位の整数倍（あるいは２の累乗倍）に相当するデータ長にすることが望ましいのである。

スムージング処理部４０４は、フラグメント処理部４０３によりパケットバッファ３０２ａに格納された固定長のＩＰパケットを等間隔にネットワーク１０１に送出する機能部である。具体的には、パケットバッファ３０２ａに格納された固定長のＩＰパケット内のヘッダ情報に基づいて送出間隔を算出し、格納された順番にＩＰパケットを送出する。送出間隔は、例えば、ＩＰヘッダあるいはＵＤＰヘッダのデータ長の情報とＲＴＰヘッダのタイムスタンプの情報により算出可能である。なお、バースト的なトラフック特性にならないと想定される予め設定された送出間隔となるよう順番にＩＰデータを送出しても良い。なお、スムージング処理部４０４は、請求項における送信間隔制御手段に相当する。

なお、上述の説明においては、フラグメント後のＩＰ（ＲＴＰ）パケットが時間方向に均等間隔となるよう送出制御を行った。しかし、一般的には、ＮＷボード２００からはＲＴＰパケットだけでなく、当該ＲＴＰパケットストリームの制御に利用されるＲＴＣＰパケット、あるいはその他のパケットが送出され得る。そのため、予めＲＴＰパケット以外に使用可能な時間スロットを確保しておき、当該時間スロットを除く期間において均等間隔となるよう送出制御を行うよう構成するのも好適である。

＜動作フロー＞
図５は、第１実施形態に係る配信サーバにおけるデータの処理フローチャートである。なお以下のステップは、例えば受信装置１１０ａ（あるいは１１０ｂ）からのストリーミングデータの送信要求の受付により開始される。なおここでは、ストリームデータの最小処理単位は６４バイトであると仮定する。

ステップＳ５０１では、入力部４０１は、受信装置１１０ａから要求のあったストリーミングデータをＨＤＤ２０４などから読み込みＲＡＭ２０２に格納する。

ステップＳ５０２では、バス転送部４０２は、ステップＳ５０１においてＲＡＭ２０２に格納されたデータを、例えば、１６ｋバイト（＝６４バイト×２^８）のデータ長のデータブロックに分割する。そして、当該データブロックに対するＩＰ、ＵＤＰ、ＲＴＰの各ヘッダを生成し、ＲＴＰ／ＵＤＰ／ＩＰの形式として格納し、バス２１０を介してＮＷボード側に転送する。

ステップＳ５０３では、フラグメント処理部４０３は、ステップＳ５０２においてバス２１０を介してバス転送部４０２から転送されたデータブロック内のペイロードデータを、例えば、５１２バイト（＝６４バイト×２^３）のデータ長のデータに分割する。つまり、ネットワーク１０１におけるＭＴＵ以下のデータ長となるようデータブロックを分割する。そして、分割され生成された５１２バイト長の各データに対してＩＰ、ＵＤＰ、ＲＴＰの各ヘッダを再生成し、ＲＴＰ／ＵＤＰ／ＩＰの形式として格納する。そして、再生成されたＩＰパケットをパケットバッファ３０２ａに格納する。

ステップＳ５０４では、スムージング処理部４０４は、ステップＳ５０３においてパケットバッファ３０２ａに格納されたＩＰパケットを、等間隔にネットワーク１０１に送出する。

なお、上述のフローチャートにおいては、説明を簡単にするために配信サーバ１００からは単一のストリーミングデータが送信されるように説明を行った。しかし、もちろん、上述の処理をストリーミングデータ毎に実行することも可能である。特に、ストリーミングデータ毎に上述のスムージング処理部４０４の処理を実行することにより、各受信装置１１０ａ、１１０ｂの属するネットワークセグメント１１１ａ、１１１ｂに到達するストリーミングデータは、それぞれがバースト性の抑えられたトラフィックとなるため、データのロスが発生しにくくなるという利点がある。

以上説明をしたように、第１実施形態の配信サーバによれば、フラグメント処理によるバス２１０の負荷（輻輳）、および、フラグメント処理実行によるＣＰＵ２０１の負荷を大幅に低減することが出来る。そのため、バス２１０の転送能力またはＣＰＵ２０１の処理能力に起因するボトルネックを大幅に緩和することが可能となる。その結果、ストリーミングデータをより効率的に送出することが可能となる。

（第２実施形態）
＜概要＞
第２実施形態では、第１実施形態の構成に加え、ＮＷボード上に前方誤り訂正符号（ＦＥＣ）の符号器を配置する。なお、ここで言う前方誤り訂正符号は欠損補償符号を含む。このような構成とすることにより、ＦＥＣ符号化処理に消費されるＣＰＵパワーを大幅に低減可能となる。また、バス使用率（トラフィック）を低減することが可能となる。

なお、ストリーミング配信システムの全体構成（図１）、および、配信サーバの内部構成（図２）については第１実施形態と同様であるため説明は省略する。

＜ＦＥＣ符号＞
本発明においてはＦＥＣ符号として特に欠損補償符号を用いるのが効果的である。そのため、第２実施形態において、ＦＥＣ符号としては、米国デジタルファウンテン社により開発されたＦＥＣ符号であるＲａｐｔｏｒ符号を用いると仮定する。ただし、もちろん一般的なリードソロモン（ＲＳ）ベースの符号を用いることも可能である。以下に、Ｒａｐｔｏｒ符号について簡単に説明するが、詳細については背景技術において述べた特許文献１を参照されたい。

Ｒａｐｔｏｒ符号では、ストリームファイルを特定のデータ長（ｓ×ｋバイト）の区間ごとに分け、各区間のデータを”入力シンボル”と呼ばれる同一データ長（ｓバイト）のｋ個のデータに分割する。そして、キーと呼ばれるインデックス値に基づいて、分割されたｋ個の入力シンボルから１以上の入力シンボル選択し、選択された入力シンボル同士をビット毎にＸＯＲ演算を行い、”出力シンボル”と呼ばれるｓバイトのデータ長のデータを生成する。このような出力シンボルを異なるキーに対して連続して生成する。

一方、受信側では、確率的にｋ＋α個（αはｋに比較し小さい）の出力シンボルを受信し、出力シンボル同士をＸＯＲ演算することにより入力シンボルを復元する。このとき、ｋ＋α個の出力シンボルは任意に選択可能であるため、転送中にどのパケットがロスした場合でも復元可能であるという優れた特性をもっている。

＜装置構成＞
図６は、第２実施形態に係る配信サーバ内のネットワークボードの内部構成を示す図である。図に示されるように、ネットワークボード６００は、パケットハンドラ６０１、メモリ６０２、メモリコントローラ６０３、バスＩ／Ｆ６１０に加え、符号化エンジン６０４および符号化制御部６０５を備えている。以下では、第１実施形態と異なる部分であるＦＥＣ符号化エンジン６０４および符号化制御部６０５について説明する。

ＦＥＣ符号化エンジン６０４は、ＸＯＲ演算をハードウェアで実行する回路である。ＸＯＲ演算を含む論理演算がハードウェアにより容易に構成可能であることは、当業者には良く知られている。

符号化制御部６０５は、前述のＲａｐｔｏｒ符号の符号化動作をＦＥＣ符号化エンジン６０４を制御することにより実現する機能部である。なお、符号化制御部６０５を、不図示のＣＰＵおよび制御プログラムを格納するフラッシュメモリとして構成することにより、他のＦＥＣ符号アルゴリズムに容易に変更することが可能となり好適である。なお、符号化制御部６０５およびＦＥＣ符号化エンジン６０４が、請求項における符号化手段に相当する。

具体的には、符号化制御部６０５はメモリ６０２に一時記憶されたデータ（入力シンボル）から、１以上の入力シンボルを選択しＦＥＣ符号化エンジン６０４に入力することにより順次出力シンボルを生成する。そして、生成された出力シンボルをメモリ６０２に一時記憶する。

ただし、前述のＲａｐｔｏｒ符号について説明でも述べたように、出力シンボルと入力シンボルとのデータ長は同一であるが、数は少なくともα個以上増加していることに注意する。

パケットハンドラ６０１は、メモリ６０２に一時記憶された出力シンボルにより構成されたデータをネットワーク１１０に適したデータ形式で送信する回路部である。具体的には、メモリ６０２に一時記憶されたデータに対し、フラグメント処理やスムージング処理を行った後、ネットワーク１１０に出力する。

＜機能構成および動作＞
図７は、第２実施形態に係る配信サーバの機能構成を示す図である。

配信サーバ１００は、データ送信に関連する機能部として、入力部７０１、バス転送部７０２、フラグメント処理部７０３、スムージング処理部７０４に加え、符号化処理部７０５を備えている。以下では、第１実施形態と異なる部分である符号化処理部７０５に関連する部分について説明する。

符号化処理部７０５は、バス２１０を介してバス転送部７０２から転送されたデータ（データブロック）に対しＦＥＣ符号化処理を実行する機能部である。具体的には、符号化エンジン６０４および符号化制御部６０５により実現され、メモリ３０２に格納されたデータブロックを、前述の入力シンボルと見立てて、出力シンボルを生成する。

フラグメント処理部７０３は、符号化処理部７０５により符号化された出力シンボル（データブロック）をネットワーク１０１に送出可能なデータ長に分割する機能部である。具体的には、メモリ６０２に格納されたデータブロックを、ネットワーク１０１のＭＴＵ以下となるデータ長に分割し、分割されたデータに対応するＩＰ、ＵＤＰ、ＲＴＰの各ヘッダを再生成する。そして、ネットワーク１０１に直接送信可能なデータ長のＩＰパケットをパケットバッファ６０２ａに格納する。

ただし、前述のように、符号化処理部７０５による符号化処理により、冗長データが追加されるため、結果として符号化処理部７０５の入力レートに比較し出力レートの方が大きい。具体的には、ｋ個の入力シンボルからｋ＋α個の出力シンボルを生成する場合、同じデータ長であることから、出力レートは入力レートの（ｋ＋α）／ｋ倍になる。このとき、符号化率はｋ／（ｋ＋α）と表され、例えばＲＴＰヘッダのタイムスタンプは符号化率に基づいて再設定される。つまり、非符号化時に比較し時間間隔を約ｋ／（ｋ＋α）倍だけ短く設定する。ここで、入力シンボルおよび出力シンボル１個のデータ量が請求項における第１データ量に相当する。また、入力シンボルｋ個に相当するデータ量が請求項における第２データ量に相当する。

スムージング処理部７０４は、フラグメント処理部７０３によりパケットバッファ６０２ａに格納された固定長のＩＰパケットを等間隔にネットワーク１０１に送出する機能部である。具体的には、パケットバッファ６０２ａに格納された固定長のＩＰパケット内のヘッダ情報に基づいて送出間隔を算出し、格納された順番にＩＰパケットを送出する。前述のようにＲＴＰヘッダのタイムスタンプが短く設定されるため、結果的に送出間隔も約ｋ／（ｋ＋α）倍だけ短く設定されることになる。

以上説明をしたように、第２実施形態の配信サーバによれば、第１実施形態で説明したフラグメント処理に加えＦＥＣ符号化処理をＮＷボード６００上で実行することによりＣＰＵ２０１の負荷を大幅に低減することが出来る。また、バス２１０にはＦＥＣ符号化による冗長データが流れることがないため、バス使用率（トラフィック）を低減することが可能となる。その結果、ストリーミングデータをより効率的に送出することが可能となる。

（変形例）
なお、上述の説明においては、ネットワークボードが直接接続するネットワーク（ここではイーサネット（登録商標））の最大転送サイズ（約１．５ｋバイト）より小さい固定長パケット（５１２バイト）を転送サイズとして設定した。しかし、もちろんＭＴＵとほぼ等しく設定しても良い。なお、一般的には配信サーバから受信端末までは複数の種々のネットワークが混在し得、それぞれのＭＴＵが異なる可能性がある。また、受信端末ごと経路が異なるため、受信端末ごとに”パスＭＴＵ”が異なる可能性がある。そのため、パスＭＴＵ探索（Path MTU Discovery）などを用い事前にパスＭＴＵを検出し、それぞれの端末に対応するパスＭＴＵ以下となるようパケットサイズを、ストリーム配信開始時に動的に設定しても良い。

ストリーミング配信システムの全体構成を例示的に示す図である。 第１実施形態に係る配信サーバの内部構成を示す図である。 第１実施形態に係る配信サーバ内のネットワークボードの内部構成を示す図である。 第１実施形態に係る配信サーバのデータ送信に関連する機能構成を示す図である。 第１実施形態に係る配信サーバにおけるデータの処理フローチャートである。 第２実施形態に係る配信サーバ内のネットワークボードの内部構成を示す図である。 第２実施形態に係る配信サーバのデータ送信に関連する機能構成を示す図である。

Claims (8)

1. ホスト装置に設けられたバスコネクタに接続するためのホストコネクタと、ネットワークに接続するためのネットワークコネクタとを備えるネットワークカードであって、
   前記ネットワークコネクタを介して送信可能なデータフレームの最大サイズを第１サイズとしたとき、
   前記ネットワークコネクタを介して送信することになるデータを、前記ホストコネクタを介して前記第１サイズよりも大きな第２サイズのブロックデータを単位として受信する受信手段と、
   前記受信手段において受信したブロックデータを一時的に記憶するためのバッファメモリと、
   前記バッファメモリから、送信するデータフレームに含めるためのデータを読み込み、前記第１サイズ以下となるデータフレームを生成して、前記ネットワークコネクタに接続されたネットワーク上に該データフレームを送信する送信手段と、
   を備えることを特徴とするネットワークカード。
2. 前記送信手段は、１以上の前記データフレームを時間軸方向に略均等な間隔で前記ネットワークに送出する送信間隔制御手段をさらに備えることを特徴とする請求項１に記載のネットワークカード。
3. 前記ブロックデータに含まれるデータに対して前方誤り訂正符号（ＦＥＣ）の符号化処理を行う符号化手段をさらに備えることを特徴とする請求項２に記載のネットワークカード。
4. 前記送信手段は、前記符号化手段により符号化されたデータに基づいて、前記第２サイズ以下となるデータフレームを生成し、
   前記送信間隔制御手段は、前記符号化手段が用いる符号化率に基づいて、前記データフレームを送出する前記間隔を決定することを特徴とする請求項３に記載のネットワークカード。
5. 前記符号化手段は、前記符号化処理を所定の第１データ量を単位とした論理演算を繰り返し実行することにより行っており、
   前記送信手段は、前記第１データ量の整数倍のサイズのデータを前記データフレームに含めることを特徴とする請求項４に記載のネットワークカード。
6. 前記符号化手段は、所定の第２データ量を単位として前記符号化処理を行い、
   前記受信手段は、前記第２データ量の整数倍のサイズに設定された前記ブロックデータを受信することを特徴とする請求項４または請求項５に記載のネットワークカード。
7. バスにより接続されたホスト処理部とネットワーク処理部を備え、ネットワークにストリーミングデータを送出する情報処理装置であって、
   前記ホスト処理部は、
   ストリームデータを入力するデータ入力手段と、
   少なくとも前記ストリームデータを、前記ネットワークにおいて転送可能なデータフレームの最大サイズを第１サイズとしたとき、該第１サイズよりも大きな第２サイズのブロックデータを単位として、前記バスを介して前記ネットワーク処理部に転送するバス転送手段と、
   を備え、
   前記ネットワーク処理部は、
   前記バス転送手段から前記バスを介して送信されたブロックデータを受信する受信手段と、
   前記受信手段において受信したブロックデータを一時的に記憶するための記憶手段と、
   前記記憶手段から、送信するデータフレームに含めるためのデータを読み込み、前記第１サイズ以下となるデータフレームを生成して、前記ネットワークコネクタに接続されたネットワーク上に該データフレームを送信する送信手段と、
   を備えることを特徴とする情報処理装置。
8. バスにより接続されたホスト処理部とネットワーク処理部を備え、ネットワークにストリーミングデータを送出する情報処理装置であって、
   前記ホスト処理部は、
   ストリームデータを入力するデータ入力部と、
   少なくとも前記ストリームデータを、前記ネットワークにおいて転送可能なデータフレームの最大サイズを第１サイズとしたとき、該第１サイズよりも大きな第２サイズのブロックデータを単位として、前記バスを介して前記ネットワーク処理部に転送するバス転送部と、
   を備え、
   前記ネットワーク処理部は、
   前記バス転送部から送信されたブロックデータを受信する受信部と、
   前記受信部において受信したブロックデータを一時的に記憶するためのバッファメモリと、
   前記バッファメモリから、送信するデータフレームに含めるためのデータを読み込み、前記第１サイズ以下となるデータフレームを生成して、前記ネットワークコネクタに接続されたネットワーク上に該データフレームを送信する送信部と、
   を備えることを特徴とする情報処理装置。

Images