(57)【要約】【課題】  本発明はデータの伝送効率を格段に向上できるようにする。【解決手段】  本発明は、ＴＣＰコネクションを介してクライアント装置３からデータＤＡの送信要求を受け付けた際、当該クライアント装置３との間に当該ＴＣＰコネクションを確立したときに確定した最大のデータサイズである確定マックスセグメントサイズＳＤに最大倍数ｎを乗じた値に基づいて、当該データＤＡを分割するときのチャンクサイズＳＣを決定し、データＤＡをチャンクサイズＳＣ毎に分割しチャンクヘッダを付加してＴＣＰライトバッファに書き込み、当該ＴＣＰライトバッファに書き込まれた書込サイズＳＷの書込データＤＷをさらに確定マックスセグメントサイズＳＤ毎に分割しＴＣＰパケットとしてクライアント装置３へ送信するようにした。【選択図】        図７
2006295819.tif 000002
【特許請求の範囲】
【請求項１】
トランスポート層のプロトコルによるコネクションを介してデータ受信装置からデータの送信要求を受け付けた際、当該データ受信装置との間に当該コネクションを確立したときに確定した最大データサイズを整数倍した値に基づいて、当該データを分割するときの分割サイズを決定する分割サイズ決定手段と、
上記データを上記分割サイズ毎に分割しトランスポート層のプロトコルに対応付けられた送信用バッファに書き込む書込手段と、
上記送信用バッファに書き込まれた上記分割サイズの上記データをさらに上記最大データサイズ毎に分割して上記データ受信装置へ送信する送信手段と
を具えることを特徴とするデータ送信装置。
【請求項２】
上記分割サイズ決定手段は、
上記最大データサイズを整数倍した値のうち上記送信用バッファのサイズ以下となる最大値に基づいて上記分割サイズを決定する
ことを特徴とする請求項１に記載のデータ送信装置。
【請求項３】
上記トランスポート層のプロトコルによるコネクションを複数確立させるコネクション制御手段
を具え、
上記書込手段は、
上記分割サイズ毎に分割した上記データを、上記複数のコネクションにそれぞれ対応付けられた複数の上記送信用バッファに振り分けてそれぞれ書き込み、
上記送信手段は、
上記複数の送信用バッファにそれぞれ書き込まれた上記分割サイズの上記データをそれぞれ上記最大データサイズ毎に分割して上記データ受信装置へそれぞれ送信する
ことを特徴とする請求項１に記載のデータ送信装置。
【請求項４】
上記トランスポート層のプロトコルは、ＴＣＰ（Transmission Control Protocol）である
ことを特徴とする請求項１に記載のデータ送信装置。
【請求項５】
上記書込手段は、ＲＴＰ（Real-time Transport Protocol）である
ことを特徴とする請求項１に記載のデータ送信装置。
【請求項６】
トランスポート層のプロトコルによるコネクションを介してデータ受信装置からデータの送信要求を受け付けた際、当該データ受信装置との間に当該コネクションを確立したときに確定した最大データサイズを整数倍した値に基づいて、当該データを分割するときの分割サイズを決定する分割サイズ決定ステップと、
上記データを上記分割サイズ毎に分割しトランスポート層のプロトコルに対応付けられた送信用バッファに書き込む書込ステップと、
上記送信用バッファに書き込まれた上記分割サイズの上記データをさらに上記最大データサイズ毎に分割して上記データ受信装置へ送信する送信ステップと
を具えることを特徴とするデータ送信方法。
【請求項７】
コンピュータに対して、
トランスポート層のプロトコルによるコネクションを介してデータ受信装置からデータの送信要求を受け付けた際、当該データ受信装置との間に当該コネクションを確立したときに確定した最大データサイズを整数倍した値に基づいて、当該データを分割するときの分割サイズを決定する分割サイズ決定ステップと、
上記データを上記分割サイズ毎に分割しトランスポート層のプロトコルに対応付けられた送信用バッファに書き込む書込ステップと、
上記送信用バッファに書き込まれた上記分割サイズの上記データをさらに上記最大データサイズ毎に分割して上記データ受信装置へ送信する送信ステップと
を実行させることを特徴とするデータ送信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ送信装置、データ送信方法及びデータ送信プログラムに関し、例えばクライアント装置から要求されたデータを送信するサーバ装置に適用して好適なものである。
【背景技術】
【０００２】
近年、インターネット等のネットワークが普及しつつあり、例えばデータを保有するサーバ装置から当該データを要求するクライアント装置へ当該ネットワークを介して当該データを送信する技術が広く利用されている。
【０００３】
インターネットやＬＡＮ（Local Area Network）等のネットワークにおいては、一般的にＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）が利用されている。このＴＣＰ／ＩＰは、階層化モデルに基づいており、例えばサーバ装置は、クライアント装置からデータの送信を要求された場合、トランスポート層に属するＴＣＰ（Transmission Control Protocol）により、上位階層であるセッション層のプロトコルから渡されたデータを、当該データの送信単位であるＴＣＰパケットサイズ毎に分割して、所定サイズのＴＣＰヘッダを付加することによりＴＣＰパケットを構成して下位階層であるネットワーク層へ順次渡す。続いてサーバ装置は、ネットワーク層以下の各層に属する各種プロトコルにより、ＴＣＰパケットをクライアント装置へ順次送信する。
【０００４】
これに応じてクライアント装置は、ネットワーク層以下の各層に属する各種プロトコルにより、当該ＴＣＰパケットを順次受信する。この後クライアント装置は、ＴＣＰによりＴＣＰパケットからＴＣＰパケットサイズの各データを順次取り出し、これらを結合して上位のセッション層へ渡すことにより、最終的に要求したデータを取得することができる（例えば、特許文献１参照）。
【特許文献１】国際公開ＷＯ０２／０１７６３７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、かかる構成のサーバ装置においては、セッション層から渡されたデータをＴＣＰパケットサイズ毎に分割する際、最後に当該ＴＣＰパケットサイズに満たない小さなＴＣＰパケットが生じてしまう可能性がある。
【０００６】
この場合サーバ装置は、この小さなＴＣＰパケットにも所定サイズのＴＣＰヘッダを付加する必要があるため、最終的にクライアント装置に転送したいデータに対して、ＴＣＰヘッダ等の当該データを転送するための付随的なデータの割合を増加させることになり、結果的に伝送効率を悪化させてしまうという問題があった。
【０００７】
本発明は以上の点を考慮してなされたもので、データの伝送効率を格段に向上し得るデータ送信装置、データ送信方法及びデータ送信プログラムを提案しようとするものである。
【課題を解決するための手段】
【０００８】
かかる課題を解決するため本発明においては、トランスポート層のプロトコルによるコネクションを介してデータ受信装置からデータの送信要求を受け付けた際、当該データ受信装置との間に当該コネクションを確立したときに確定した最大データサイズを整数倍した値に基づいて、当該データを分割するときの分割サイズを決定し、データを分割サイズ毎に分割しトランスポート層のプロトコルに対応付けられた送信用バッファに書き込み、送信用バッファに書き込まれた分割サイズのデータをさらに最大データサイズ毎に分割してデータ受信装置へ送信するようにした。
【０００９】
これにより、送信用バッファに書き込まれた分割サイズのデータをさらに最大データサイズ毎に分割する際、当該最大データサイズに満たない小さなデータに分割せずに済み、データ受信装置へ送信するときのパケット数を必要最小限に抑えることができるので、各パケットに付加するパケットヘッダのデータ量を必要最小限に抑えることができる。
【発明の効果】
【００１０】
本発明によれば、送信用バッファに書き込まれた分割サイズのデータをさらに最大データサイズ毎に分割する際、当該最大データサイズに満たない小さなデータに分割せずに済み、データ受信装置へ送信するときのパケット数を必要最小限に抑えることができるので、各パケットに付加するパケットヘッダのデータ量を必要最小限に抑えることができ、かくしてデータの伝送効率を格段に向上し得るデータ送信装置、データ送信方法及びデータ送信プログラムを実現できる。
【発明を実施するための最良の形態】
【００１１】
以下、図面について、本発明の一実施の形態を詳述する。
【００１２】
（１）データ送信システムの構成
図１に示すように、データ送信システム１は、送信用の各種データを保有するサーバ装置２と当該データを要求するクライアント装置３とがインターネット４を介して互いに接続された構成を有している。
【００１３】
データ受信装置としてのクライアント装置３は、ユーザの操作等に応じて、インターネット４を介してサーバ装置２へデータの送信を要求する。一方データ送信装置としてのサーバ装置２は、クライアント装置３からのデータの送信要求を待ち受けるようになされており、当該送信要求を受けた場合、これに応じて当該クライアント装置３へ当該データを送信するようになされている。
【００１４】
図２に示すように、サーバ装置２は、一般的なコンピュータと同様の構成を有し、ＣＰＵ（Central Processing Unit）１０によって全体を統括制御するようになされており、バス１１を介して当該ＣＰＵ１０と接続されたＲＯＭ（Read Only Memory）１２又はハードディスクドライブ１４に格納されたＯＳ（Operating System）等の基本プログラムやデータ送信プログラム等の各種アプリケーションプログラムを読み出し、これをＲＡＭ（Random Access Memory）１３に展開して実行することにより、データ送信等の各種処理を実行し得るようになされている。
【００１５】
ちなみにハードディスクドライブ１４は、ＯＳやデータ送信プログラム等の各種アプリケーションプログラムに加えて、送信用のデータ等も格納されるようになされている。
【００１６】
またサーバ装置２は、ネットワークインタフェース１５により、インターネット４（図１）等のネットワークを介してクライアント装置３等と通信接続するようになされている。例えばサーバ装置２のＣＰＵ１０は、ネットワークインタフェース１５によってクライアント装置３からのデータの送信要求を取得すると、当該送信要求に応じたデータをハードディスクドライブ１４から読み出し、当該ネットワークインタフェース１５から当該データを当該クライアント装置３へ送信する。
【００１７】
図３に示すように、クライアント装置３は、サーバ装置２と一部類似した構成を有しており、ＣＰＵ２０によって全体を統括制御し、バス２１を介して当該ＣＰＵ２０と接続されたＲＯＭ２２又はハードディスクドライブ２４に格納されたＯＳ等の基本プログラムやデータ受信プログラム等の各種アプリケーションプログラムを読み出し、これをＲＡＭ２３に展開して実行することにより、データ受信等の各種処理を実行し得るようになされている。
【００１８】
またクライアント装置３は、インターネット４（図１）等のネットワークを介してサーバ装置２等と接続するネットワークインタフェース２５、キーボードやマウス等（図示せず）でなりユーザの操作指示を受け付ける操作部２６、表示画面を生成する表示制御部２７及び当該表示画面を表示する表示部２８を有している。
【００１９】
例えばクライアント装置３のＣＰＵ２０は、操作部２６を介したユーザの操作指示に応じてデータ受信プログラムを起動し、当該データ受信プログラムに従いネットワークインタフェース２５を介してサーバ装置２と接続して、当該サーバ装置２からデータの情報を取得し、これを基に表示制御部２７によりデータ一覧表示画面を生成して表示部２８により画面表示させる。
【００２０】
（２）サーバ装置からのデータ送信
ところでデータ送信システム１（図１）では、上述したようにインターネット４を介してサーバ装置２とクライアント装置３とが接続されるようになされているが、このインターネット４では、標準的なプロトコルとしてＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）が利用されている。
【００２１】
図４に示すように、サーバ装置２及びクライアント装置３は、それぞれＴＣＰ／ＩＰの各階層に属する複数のプロトコルを実装しており、各プロトコルを相互に連携させることによって、最終的にサーバ装置２の最上位階層に属するデータ送信プログラム３０からクライアント装置３の最上位階層に属するデータ受信プログラム４０へデータを送信し得るようになされている。
【００２２】
ちなみに図４においては、本来４階層でなるＴＣＰ／ＩＰの階層構造の一部を７階層でなるＯＳＩ（Open System Interconnection）参照モデルの階層構造と対応付けて示している。また図中の一点鎖線は、説明の都合上設けたものであり、ＴＣＰ／ＩＰの４階層を表すものではない。
【００２３】
クライアント装置３は、例えばユーザの操作指示に基づいてサーバ装置２からリアルタイムの映像データを受信する、いわゆるストリーミング配信を受ける場合、データ受信プログラム４０から、データをリアルタイムに送受信するためのＲＴＳＰ（Real Time Streaming Protocol）４１へデータの送信要求を送出し、これをＴＣＰポート４４からサーバ装置２へ送信する。
【００２４】
サーバ装置２は、ＲＴＳＰ３１によってＴＣＰポート３４を介してクライアント装置３からのデータの送信要求を受信し、これをデータ送信プログラム３０へ渡す。データ送信プログラム３０は、当該データの送信要求に応じて、要求されたデータの送信指示をＲＴＳＰ３１に供給する。
【００２５】
ちなみにサーバ装置２は、図示しないビデオカメラ等から入力された映像信号をリアルタイムで映像データに変換しており、当該映像データをクライアント装置３に対してストリーミング配信するようになされている。
【００２６】
サーバ装置２のＲＴＳＰ３１は、図５に示すように、送信すべきデータＤＡ（すなわち映像データ）をＴＣＰライトバッファ（後述する）への書き込みに適したサイズのデータ（以下これをチャンクデータＤＣと呼ぶ）に分割し、これを順次Ｍｕｌｔｉ  Ｆｌｏｗ  ＲＴＰ（Real-time Transport Protocol）３２に供給する。
【００２７】
Ｍｕｌｔｉ  Ｆｌｏｗ  ＲＴＰ３２（図４）は、複数のフロー（トランスポート層のプロトコルを介したデータ送信の流れ）によってデータを送信するプロトコルであり、データの送信に利用するＴＣＰポート３６のポート番号や使用するポート数等の制御情報をＲＴＣＰ（RTP Control Protocol）３３へ供給すると共に、ＲＴＳＰ３１から供給されたチャンクデータＤＣをＴＣＰポート３６の動作状態に応じて当該ＴＣＰポート３６に対応付けられたＴＣＰライトバッファへ供給する。
【００２８】
ＲＴＣＰ３３は、Ｍｕｌｔｉ  Ｆｌｏｗ  ＲＴＰ３２から供給された制御情報を基に、分割されたチャンクデータＤＣを再度結合するための制御情報等をＴＣＰポート３５を介してクライアント装置３へ送信する。
【００２９】
ＴＣＰポート３６は、供給されたチャンクデータＤＣをさらに複数のＴＣＰパケットデータＤＫに分割し（図５）、これにＴＣＰヘッダを付加することによりＴＣＰパケットを生成して、これをクライアント装置３へ順次送信する。
【００３０】
これに応じてクライアント装置３は、ＴＣＰポート４５（図４）を介してＴＣＰパケットの組み立て順序等を示す制御情報を受信し、当該制御情報をＲＴＣＰ４３へ供給する。ＲＴＣＰ４３は、当該制御情報をＴＣＰポート４６及びＭｕｌｔｉ  Ｆｌｏｗ  ＲＴＰ４２へ供給する。
【００３１】
ＴＣＰポート４６は、制御情報に基づいてサーバ装置２からのＴＣＰパケットを順次受信すると共に、当該ＴＣＰパケットから取り出した複数のＴＣＰパケットデータＤＫを結合することによりチャンクデータＤＣを復元し（図５）、これをＭｕｌｔｉ  Ｆｌｏｗ  ＲＴＰ４２へ供給する。
【００３２】
Ｍｕｌｔｉ  Ｆｌｏｗ  ＲＴＰ４２（図４）は、ＲＴＣＰ４３から供給された制御情報に基づき、ＴＣＰポート４６から供給されたチャンクデータＤＣを順次結合することにより元のデータＤＡを組み立て（図５）、これをデータ受信プログラム４０へ渡す。これに応じてデータ受信プログラム４０は、データＤＡ（すなわち映像データ）を所定の映像再生プログラムへ渡して再生させることにより、当該映像データの映像をユーザに視聴させるようになされている。
【００３３】
このようにサーバ装置２は、複数のプロトコルによって元のデータＤＡをチャンクデータＤＣ及びＴＣＰパケットデータＤＫへと順次分割し、これをＴＣＰコネクションを介して複数のＴＣＰパケットとしてクライアント装置３へ送信するようになされている。
【００３４】
（３）スリーウェイハンドシェイクによるコネクションの確立
ところでサーバ装置２のＣＰＵ１０は、ＴＣＰポート３４においてクライアント装置３のＴＣＰポート４４（図４）と接続する際、いわゆるスリーウェイハンドシェイクを行うことにより、ＴＣＰコネクションを確立するようになされている。ここで、このスリーウェイハンドシェイクについて、図６のシーケンスチャートを用いて説明する。なお図６では、本来サーバ装置２とクライアント装置３との間に介在するルータ等のネットワーク機器を省略して示している。
【００３５】
クライアント装置３は、１番目の手順としてサーバ装置２への接続を要求するべく、ＴＣＰポート４４（図４）からサーバ装置２へＳＹＮ（同期）パケットＰ１を送信する。このときクライアント装置３は、ＳＹＮパケットのオプション欄に当該クライアント装置３においてＴＣＰパケットに格納可能なＴＣＰパケットデータの最大データサイズを表すマックスセグメントサイズ（MSS:Max Segment Size）ＭＳ３を記述しておく。
【００３６】
ちなみにこのマックスセグメントサイズＭＳ３は、クライアント装置３側（すなわち図１におけるクライアント装置３からインターネット４内のネットワーク機器迄の経路）のデータリンク層におけるＭＴＵ（Max Transmission Unit）に基づいて定まる値であり、当該クライアント装置３に予め設定されているものである。同様にサーバ装置２にも、当該サーバ装置２側のデータリンク層におけるＭＴＵに基づいたマックスセグメントサイズＭＳ２が設定されている。
【００３７】
サーバ装置２は、クライアント装置３からのＳＹＮパケットＰ１を受信し、まず受信したマックスセグメントサイズＭＳ３と当該サーバ装置２に予め設定されたマックスセグメントサイズＭＳ２とを比較し、いずれか小さい方をこのＴＰＣコネクションにおける確定マックスセグメントサイズＳＤとして確定する。続いてサーバ装置２は、２番目の手順として、オプション欄に確定マックスセグメントサイズＳＤを記述したＳＹＮ／ＡＣＫ（同期／応答）パケットＰ２をＴＣＰポート３４（図４）からクライアント装置３へ送信する。
【００３８】
これに応じてクライアント装置３は、サーバ装置２からのＳＹＮ／ＡＣＫパケットＰ２を受信し、当該ＳＹＮ／ＡＣＫパケットＰ２に記述されている確定マックスセグメントサイズＳＤを認識した上で、３番目の手順としてＡＣＫ（応答）パケットＰ３をサーバ装置２へ送信する。サーバ装置２がこのＡＣＫパケットＰ３を受信した時点で、当該サーバ装置２とクライアント装置３との間にＴＣＰコネクションが確立される。
【００３９】
このようにサーバ装置２は、ＴＣＰポート３４とクライアント装置３のＴＣＰポート４４との間でＴＣＰコネクションを確立させる際、スリーウェイハンドシェイクを行うようになされており、このとき同時に両者のマックスセグメントサイズＭＳ２及びＭＳ３のうち小さい方に合わせて確定マックスセグメントサイズＳＤを確定するようになされている。
【００４０】
またサーバ装置２は、実際上クライアント装置毎にその通信経路等に応じてマックスセグメントサイズの値が異なるため、各クライアント装置との間にＴＣＰコネクションを確立する度に、各クライアント装置に合わせた確定マックスセグメントサイズＳＤを決定することになる。
【００４１】
（４）データ分割送信処理手順
ところでサーバ装置２は、各プロトコルによって元のデータＤＡをチャンクデータＤＣへ分割し、さらにＴＣＰパケットデータＤＫに分割する際、当該チャンクデータＤＣ及び当該ＴＣＰパケットデータＤＫの適切なサイズを決定した上で当該データを分割するようになされている。以下では、サーバ装置２が各プロトコルによってデータを段階的に分割してクライアント装置３へ送信するときの具体的なデータ分割送信処理手順ＲＴ１について、図７のフローチャートを用いて説明する。
【００４２】
実際上サーバ装置２のＣＰＵ１０は、電源が投入されＯＳを起動した時点でデータ送信プログラムをハードディスクドライブ１４から読み出して実行するようになされており、このときデータ分割送信処理手順ＲＴ１を開始してステップＳＰ１へ移り、クライアント装置３からのＴＣＰポート３４（図４）を介した接続を待ち受ける。ＣＰＵ１０は、当該クライアント装置３から当該ＴＣＰポート３４を介して接続されると、接続時（すなわちＴＣＰコネクションの確立時）に当該ＴＣＰポート３４を介してクライアント装置３からデータの送信要求を表すＲＴＳＰリクエストを受信し、当該クライアント装置３との間にＲＴＳＰコネクションを確立して次のステップＳＰ２へ移る。
【００４３】
ステップＳＰ２においてＣＰＵ１０は、ＴＣＰポート３４においてＴＣＰコネクションを確立した際に決定した確定マックスセグメントサイズＳＤを認識し、次のステップＳＰ３へ移る。
【００４４】
ステップＳＰ３においてＣＰＵ１０は、確定マックスセグメントサイズＳＤを整数倍した場合の、データ送信に利用するＴＣＰポート３６に対応付けられたＴＣＰライトバッファに収まる範囲での最大倍数ｎ（すなわちＴＣＰライトバッファサイズＳＢを確定マックスセグメントサイズＳＤで割ったときの商に相当）を算出し、次のステップＳＰ４へ移る。
【００４５】
ステップＳＰ４においてＣＰＵ１０は、確定マックスセグメントサイズＳＤと最大倍数ｎとを掛け合わせた値から後述するチャンクヘッダサイズＳＨ（１０バイト）を差し引くことにより、ＲＴＳＰ３１（図４）において元のデータを分割する際の分割サイズとしてのチャンクサイズＳＣを決定し、次のステップＳＰ５へ移る。
【００４６】
ステップＳＰ５においてＣＰＵ１０は、ＲＴＳＰ３１によって元のデータＤＡをチャンクサイズＳＣ毎のチャンクデータＤＣに分割し（図５）、これをＭｕｌｔｉ  Ｆｌｏｗ  ＲＴＰ３２へ順次供給して、次のステップＳＰ６へ移る。
【００４７】
ステップＳＰ６においてＣＰＵ１０は、Ｍｕｌｔｉ  Ｆｌｏｗ  ＲＴＰ３２（図４）により、図８（Ａ）に示すように、チャンクデータＤＣに１０バイトのチャンクヘッダを付加して書込データＤＷとし、これをＴＣＰポート３６のＴＣＰライトバッファに１つ書き込んで次のステップＳＰ７へ移る。
【００４８】
ここでＣＰＵ１０は、書込データＤＷのサイズ（以下これを書込サイズＳＷと呼ぶ）を確定マックスセグメントサイズＳＤと最大倍数ｎとの積としているため、当該最大倍数ｎの算出原理に基づき、当該書込データＤＷをＴＣＰライトバッファに書き込んだ際、当該ＴＣＰライトバッファから溢れることなく確実に収めることができる。
【００４９】
ちなみにチャンクヘッダは、図８（Ｂ）に示すように、各チャンクデータＤＣに対して付与された一連の番号を表す４バイトのシリアルナンバーと、元のデータＤＡを一意的に表す６バイトのデータＩＤ（Identifier）とで構成されている。またデータＩＤは、元のデータＤＡにおけるハッシュ値であるＭＤ５（Message Digest Algorithm 5）の先頭部分が用いられるようになされている。
【００５０】
ステップＳＰ７においてＣＰＵ１０は、ＴＣＰポート３６により、ＴＣＰライトバッファに書き込まれた書込データＤＷを確定マックスセグメントサイズＳＤ毎のＴＣＰパケットデータＤＰに分割し、これに所定のＴＣＰヘッダを付加することによりＴＣＰパケットを生成して、ＴＣＰコネクションを介して全てのＴＣＰパケットをクライアント装置へ順次送信してから次のステップＳＰ８へ移る。
【００５１】
このときＣＰＵ１０は、図５に示したように、ＴＣＰライトバッファに書き込んだ書込データＤＷの書込サイズＳＷを予め確定マックスセグメントサイズＳＤと最大倍数ｎとの積としているため、当該書込データＤＷをＴＣＰパケットデータＤＰに分割する際にいわゆる「余り」を発生させることなく、確定マックスセグメントサイズＳＤに揃えることができる。
【００５２】
またＣＰＵ１０は、書込データＤＷの書込サイズＳＷを確定マックスセグメントサイズＳＤと最大倍数ｎとの積としているため、当該書込データＤＷをＴＣＰライトバッファに書き込んだ際、当該ＴＣＰライトバッファにおける余剰サイズＲＭを確定マックスセグメントサイズＳＤよりも小さくすることになる。すなわちＣＰＵ１０は、当該書込サイズＳＷを、当該書込データＤＷをＴＣＰパケットデータＤＰに分割する際に「余り」を発生させない範囲での最大サイズとしているため、ＴＣＰライトバッファを最も効率良く利用していることになる。
【００５３】
ステップＳＰ８においてＣＰＵ１０は、Ｍｕｌｔｉ  Ｆｌｏｗ  ＲＴＰ３２（図４）により、全てのチャンクデータＤＣをクライアント装置３へ送信し終えたか否かを判定する。ここで否定結果が得られると、このことはまだ送信していないチャンクデータＤＣが残っていることを表しており、このときＣＰＵ１０は、次のチャンクデータＤＣをクライアント装置３へ送信するべく、再度ステップＳＰ６へ戻る。
【００５４】
これに対してステップＳＰ８において肯定結果が得られると、このことはクライアント装置３に対して全てのチャンクデータＤＣを送出し終えたことを表しており、このときＣＰＵ１０は次のステップＳＰ９へ移る。
【００５５】
ステップＳＰ９においてＣＰＵ１０は、データＤＡの送信を終了するべく、クライアント装置３との間のＲＴＳＰコネクションを開放し、次のステップＳＰ１０へ移ってデータ分割送信処理手順ＲＴ１を終了する。
【００５６】
これに応じてクライアント装置３は、上述したようにＴＣＰパケットを順次受信してＴＣＰパケットデータＤＫを結合することにより書込データＤＷを復元し、さらに当該書込データＤＷから取り出したチャンクデータＤＣを順次結合することにより元のデータＤＡを復元するようになされている。
【００５７】
（５）動作及び効果
以上の構成において、サーバ装置２は、クライアント装置３からデータＤＡの送信を要求されると、まずＴＣＰコネクションの確立時に決定した確定マックスセグメントサイズＳＤを認識し、ＴＣＰライトバッファサイズＳＢ以下に収まる当該確定マックスセグメントサイズＳＤの最大倍数ｎを算出して、さらにチャンクヘッダサイズＳＨを差し引くことによりチャンクサイズＳＣを決定する。
【００５８】
続いてサーバ装置２は、ＲＴＳＰ３１によって、元のデータＤＡをチャンクサイズＳＣ毎のチャンクデータＤＣに分割し、これにチャンクヘッダを付加することにより書込データＤＷを生成して、ＴＣＰライトバッファに当該書込データＤＷを１つずつ書き込む。さらにサーバ装置２は、ＴＣＰポート３６によって、書込データＤＷを確定マックスセグメントサイズＳＤ毎に分割してＴＣＰパケットデータＤＫとし、これにＴＣＰヘッダを付加することによりＴＣＰパケットを生成してＴＣＰコネクションを介してクライアント装置３へ順次送信する。
【００５９】
従ってサーバ装置２は、ＴＣＰライトバッファに書き込む書込データＤＷの書込サイズＳＷを予め確定マックスセグメントサイズＳＤと最大倍数ｎとの積としているため、当該書込データＤＷをＴＣＰパケットデータＤＫに分割する際にいわゆる「余り」を発生させることが無く、当該ＴＣＰパケットデータＤＫのサイズを確定マックスセグメントサイズＳＤに揃えることができる。
【００６０】
すなわちサーバ装置２は、各ＴＣＰパケットに格納可能な最大サイズのデータを格納して送信することができるため、ＴＣＰパケット数を必要最小限に抑えることによりＴＣＰヘッダとして送信するデータ量も必要最小限に抑えることができる。この結果サーバ装置２は、実際に送信する全てのデータのうち元のデータＤＡが占める割合を高めることができるので、伝送効率を向上させることができる。
【００６１】
特にサーバ装置２は、元のデータＤＡのサイズが大きい場合、当該データＤＡを分割することにより多数の書込データＤＷを生成する。このため、例えば書込データＤＷが確定マックスセグメントサイズＤＳの整数倍になっておらずＴＣＰパケットデータＤＫに分割する際に毎回「余り」を発生させる場合と比較して、サーバ装置２は、送信するＴＣＰパケットの数を削減してネットワークトラフィックを減少させ得ると共に伝送効率を飛躍的に向上することができ、これに伴いデータＤＡの送信に要する時間も短縮することができる。
【００６２】
同時にサーバ装置２は、確定マックスセグメントサイズＳＤの整数倍という制約の下で、書込サイズＳＷをＴＣＰライトバッファサイズに収まる最大値に決定するので、書込データＤＷをＴＣＰパケットデータＤＰに分割する際に「余り」を発生させない範囲で当該ＴＣＰライトバッファを最大限に利用することができ、この結果、ＴＣＰライトバッファに書込データＤＷを書き込む回数を極力少なく抑えてＣＰＵ１０における処理負荷を軽減することができる。
【００６３】
またサーバ装置２は、クライアント装置３毎に確定マックスセグメントサイズＳＤが異なる値に設定されるものの、ＴＣＰコネクションを確立した際に決定した当該確定マックスセグメントサイズＳＤに応じて最適なチャンクサイズＳＣを決定するため、各クライアント装置３へデータＤＡを送信するときに、書込データＤＷをＴＣＰパケットデータＤＫに分割する際の「余り」を発生させずに済む。
【００６４】
そのうえサーバ装置２は、ＴＣＰライトバッファのサイズではなくチャンクサイズＳＣを確定マックスセグメントサイズＳＤに応じて変更するため、当該ＴＣＰライトバッファのサイズを変更する際に必要なＯＳの再構築等の複雑な処理をせずに済む。
【００６５】
以上の構成によれば、サーバ装置２は、ＴＣＰコネクションの確立時に確定した確定マックスセグメントサイズＳＤを用いてＴＣＰライトバッファサイズＳＢ以下に収まる当該確定マックスセグメントサイズＳＤの最大倍数ｎを算出し、これを基にチャンクサイズＳＣを決定することにより、チャンクデータＤＣにチャンクヘッダを付加した書込データＤＷをＴＣＰパケットデータＤＫに分割する際に、「余り」を発生させること無く確定マックスセグメントサイズＳＤに揃えることができるので、実際に送信する全てのデータのうち元のデータＤＡが占める割合を高めて伝送効率を向上させることができる。
【００６６】
（６）他の実施の形態
なお上述した実施の形態においては、サーバ装置２のＴＣＰポート３６（図４）とクライアント装置３のＴＣＰポート４６とによるＴＣＰコネクションを１つのみ用いてＴＣＰパケットデータＤＫを送信するようにした場合について述べたが、本発明はこれに限らず、サーバ装置２における複数のＴＣＰポートとクライアント装置３における複数のＴＣＰポートとをそれぞれ用いて複数のＴＣＰコネクションを確立し、Ｍｕｌｔｉ  Ｆｌｏｗ  ＲＴＰ３２の制御の下でこれら複数のＴＣＰコネクションによってＴＣＰパケットデータＤＫを並行して送信するようにしても良い。
【００６７】
この場合サーバ装置２は、Ｍｕｌｔｉ  Ｆｌｏｗ  ＲＴＰ３２の制御に基づき、ＴＣＰポート毎に設けられたＴＣＰライトバッファに書込データＤＷを振り分けながら順次書き込めば良く、これにより複数のＴＣＰコネクションを用いて並行してＴＣＰパケットデータＤＫを送信することができるので、ネットワーク上のデータ伝送効率を向上できると共にデータＤＡの送信に要する時間を短縮することができる。
【００６８】
さらにこの場合、仮に１本のＴＣＰコネクションにおけるＴＣＰパケットの送信が途切れてしまった場合でも、他のＴＣＰコネクションを用いて当該ＴＣＰパケットを送信することができるので、ＴＣＰパケットの再送処理等によってデータの送信が完全に中断してしまうことを回避でき、伝送速度をあまり低下させずに済む。
【００６９】
また上述した実施の形態においては、データＤＡを分割して生成したＴＣＰパケットデータＤＫをそれぞれ１回ずつ送信するようにした場合について述べたが、本発明はこれに限らず、複数のＴＣＰコネクションを用いて２以上のＴＣＰコネクションで同一のＴＣＰパケットデータＤＫを送信するようにしても良い。これにより、サーバ装置２からデータＤＡを多重化して送信することができるので、ネットワーク上においてパケットの欠落やエラーの発生時が生じた場合であっても、クライアント装置３において複数のＴＣＰコネクションを経たＴＣＰパケットデータＤＫ同士を元にエラー訂正等を行うことにより、データＤＡを復元することができるので、当該データＤＡの確実性を向上させることができる。
【００７０】
これと同様に、複数のＲＴＳＰコネクションを用いてサーバ装置２からデータＤＡを多重化してクライアント装置３へ送信するようにしても良く、この場合も当該クライアント装置３における当該データＤＡの確実性を向上させることができる。
【００７１】
また上述した実施の形態においては、チャンクサイズＳＣを決定する際、ＴＣＰライトバッファサイズＳＢ以下に収まる確定マックスセグメントサイズＳＤの最大倍数ｎを算出するようにした場合について述べたが、本発明はこれに限らず、例えば何らかの理由により最大倍数ｎを用いることができない場合に、当該確定マックスセグメントサイズＳＤの所定倍数ｍ（ただし１≦ｍ≦ｎ）を用いて、確定マックスセグメントサイズＳＤと当該所定倍数ｍとを掛け合わせた値からチャンクヘッダサイズＳＨ（１０バイト）を差し引いて当該チャンクサイズＳＣを決定するようにしても良く、要は書込データＤＷの書込サイズＳＷが確定マックスセグメントサイズＳＤの整数倍となっていれば良い。
【００７２】
さらに上述した実施の形態においては、チャンクへッダサイズＳＨ（図８（Ｂ））を１０バイトとするようにした場合について述べたが、本発明はこれに限らず、当該チャンクヘッダサイズＳＨを任意のバイト数としても良い。この場合、シリアルナンバーのバイト数については、元のデータＤＡを分割した全てのチャンクデータに一意の番号を設定し得る範囲で任意に設定しても良く、またデータＩＤのバイト数については当該データＤＡと他のデータとを確実に識別し得る範囲で任意に設定しても良い。さらにデータＩＤとしては、ＭＤ５を用いる以外にも、他の種々のハッシュ関数に基づいたハッシュ値や、ファイル名・ファイルサイズ・作成日時等を組み合わせた文字列等、データを識別し得る任意の値を用いるようにしても良い。
【００７３】
さらに上述した実施の形態においては、トランスポート層のプロトコルとしてＴＣＰを用いるようにした場合について述べたが、本発明はこれに限らず、ＴＣＰ以外の他のプロトコルを用いるようにしても良く、この場合、マックスセグメントサイズに相当する、当該プロトコルにおける送信可能な最大のデータサイズの整数倍に応じてチャンクサイズＳＣを算出すれば良い。
【００７４】
さらに上述した実施の形態においては、ＲＴＳＰ３１（図４）により元のデータＤＡをチャンクデータＤＣに分割するようにした場合について述べたが、本発明はこれに限らず、例えば他の種々のセッション層のプロトコル、あるいはデータ送信プログラム３０により当該データＤＡをチャンクデータＤＣに分割するようにしても良い。
【００７５】
さらに上述した実施の形態においては、Ｍｕｌｔｉ  Ｆｌｏｗ  ＲＴＰ３２によりＲＴＰを利用してデータＤＡをクライアント装置３へ送信するようにした場合について述べたが、本発明はこれに限らず、例えばＲＴＰ以外の他のセッション層のプロトコルを利用して当該データＤＡを当該クライアント装置３へ送信するようにしても良い。
【００７６】
さらに上述した実施の形態においては、サーバ装置２からクライアント装置３に対して映像データのストリーミング送信を行う場合について述べたが、本発明はこれに限らず、当該サーバ装置２から当該クライアント装置３に対してオーディオコンテンツや画像データ等の種々の形式のデータを送信する場合に適用するようにしても良い。
【００７７】
さらに上述した実施の形態においては、サーバ装置２とクライアント装置３とがインターネット４に接続された場合について述べたが、本発明はこれに限らず、当該サーバ装置２と当該クライアント装置３とがＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）等の種々のネットワークに接続された場合に適用するようにしても良い。
【００７８】
さらに上述した実施の形態においては、ストリーミング送信を行うサーバ装置２に本発明を適用するようにした場合について述べたが、これに限らず、例えばＦＴＰ（File Transfer Protocol）サーバやＨＴＭＬサーバ、或いはファイルの共有を許可しているパーソナルコンピュータ等、種々のネットワークを介して種々のデータを送信可能な種々のコンピュータに本発明を適用するようにしても良い。
【００７９】
さらに上述した実施の形態においては、データ分割送信処理手順ＲＴ１に示した一連の処理をサーバ２のＣＰＵ１０がソフトウェアにより実現するようにした場合について述べたが、本発明はこれに限らず、各処理をハードウェアによって実現したり、或いはソフトウェアとハードウェアとを組み合わせて実現するようにしても良い。
【００８０】
さらに上述した実施の形態においては、サーバ装置２においてデータ送信プログラム等の各種プログラムをハードディスクドライブ１４に予め記憶しておくようにした場合について述べたが、本発明はこれに限らず、当該データ送信プログラム等の各種プログラムを例えば通信インタフェース１５を介して外部から取得するようにしても良く、或いは交換可能な記憶媒体である光ディスク（図示せず）やメモリースティック（登録商標）等に格納されて提供されるようにしても良く、また当該データ送信プログラム等の各種プログラムをＲＯＭ１２や半導体メモリ（図示せず）等に格納しても良い。
【００８１】
さらに上述した実施の形態においては、分割サイズ決定手段としてのデータ送信プログラム３０及びＲＴＳＰ３１と、書込手段としてのＭｕｌｔｉ  Ｆｌｏｗ  ＲＴＰ３２と、送信手段としてのＴＣＰ３６とによってデータ送信装置としてのサーバ装置２を構成する場合について述べたが、本発明はこれに限らず、その他種々の回路構成でなる分割サイズ決定手段と、書込手段と、送信手段とによってデータ送信装置を構成するようにしても良い。
【産業上の利用可能性】
【００８２】
本発明は、種々のデータを送信するデータ送信装置でも利用できる。
【図面の簡単な説明】
【００８３】
【図１】データ配信システムの全体構成を示すブロック図である。
【図２】サーバ装置の構成を示すブロック図である。
【図３】クライアント装置の構成を示すブロック図である。
【図４】プロトコルの対応関係を示す略線図である。
【図５】データ送信の様子の説明に供する略線図である。
【図６】スリーウェイハンドシェイクによるコネクション確立の説明に供するシーケンスチャートである。
【図７】データ分割送信処理手順を示すフローチャートである。
【図８】書込データの構造を示す略線図である。
【符号の説明】
【００８４】
１……データ送信システム、２……サーバ装置、３……クライアント装置、１０、２０……ＣＰＵ、１４、２４……ハードディスクドライブ、３０……データ送信プログラム、３１、４１……ＲＴＳＰ、３２、４２……Ｍｕｌｔｉ  Ｆｌｏｗ  ＲＴＰ、３３、４３……ＲＴＣＰ、３４、３５、３６、４４、４５、４６……ＴＣＰポート、ＤＡ……データ、ＤＣ……チャンクデータ、ＤＫ……ＴＣＰパケットデータ。
【図１】
2006295819.tif 000003
【図２】
2006295819.tif 000004
【図３】
2006295819.tif 000005
【図４】
2006295819.tif 000006
【図５】
2006295819.tif 000007
【図６】
2006295819.tif 000008
【図７】
2006295819.tif 000009
【図８】
2006295819.tif 000010