JP2006295819A - データ送信装置、データ送信方法及びデータ送信プログラム - Google Patents

データ送信装置、データ送信方法及びデータ送信プログラム Download PDF

Info

Publication number
JP2006295819A
JP2006295819A JP2005117271A JP2005117271A JP2006295819A JP 2006295819 A JP2006295819 A JP 2006295819A JP 2005117271 A JP2005117271 A JP 2005117271A JP 2005117271 A JP2005117271 A JP 2005117271A JP 2006295819 A JP2006295819 A JP 2006295819A
Authority
JP
Japan
Prior art keywords
data
size
transmission
tcp
division
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2005117271A
Other languages
English (en)
Inventor
Seigo Kawamura
聖悟 河村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2005117271A priority Critical patent/JP2006295819A/ja
Publication of JP2006295819A publication Critical patent/JP2006295819A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】
本発明はデータの伝送効率を格段に向上できるようにする。
【解決手段】
本発明は、TCPコネクションを介してクライアント装置3からデータDAの送信要求を受け付けた際、当該クライアント装置3との間に当該TCPコネクションを確立したときに確定した最大のデータサイズである確定マックスセグメントサイズSDに最大倍数nを乗じた値に基づいて、当該データDAを分割するときのチャンクサイズSCを決定し、データDAをチャンクサイズSC毎に分割しチャンクヘッダを付加してTCPライトバッファに書き込み、当該TCPライトバッファに書き込まれた書込サイズSWの書込データDWをさらに確定マックスセグメントサイズSD毎に分割しTCPパケットとしてクライアント装置3へ送信するようにした。
【選択図】 図7

Description

本発明はデータ送信装置、データ送信方法及びデータ送信プログラムに関し、例えばクライアント装置から要求されたデータを送信するサーバ装置に適用して好適なものである。
近年、インターネット等のネットワークが普及しつつあり、例えばデータを保有するサーバ装置から当該データを要求するクライアント装置へ当該ネットワークを介して当該データを送信する技術が広く利用されている。
インターネットやLAN(Local Area Network)等のネットワークにおいては、一般的にTCP/IP(Transmission Control Protocol/Internet Protocol)が利用されている。このTCP/IPは、階層化モデルに基づいており、例えばサーバ装置は、クライアント装置からデータの送信を要求された場合、トランスポート層に属するTCP(Transmission Control Protocol)により、上位階層であるセッション層のプロトコルから渡されたデータを、当該データの送信単位であるTCPパケットサイズ毎に分割して、所定サイズのTCPヘッダを付加することによりTCPパケットを構成して下位階層であるネットワーク層へ順次渡す。続いてサーバ装置は、ネットワーク層以下の各層に属する各種プロトコルにより、TCPパケットをクライアント装置へ順次送信する。
これに応じてクライアント装置は、ネットワーク層以下の各層に属する各種プロトコルにより、当該TCPパケットを順次受信する。この後クライアント装置は、TCPによりTCPパケットからTCPパケットサイズの各データを順次取り出し、これらを結合して上位のセッション層へ渡すことにより、最終的に要求したデータを取得することができる(例えば、特許文献1参照)。
国際公開WO02/017637号公報
しかしながら、かかる構成のサーバ装置においては、セッション層から渡されたデータをTCPパケットサイズ毎に分割する際、最後に当該TCPパケットサイズに満たない小さなTCPパケットが生じてしまう可能性がある。
この場合サーバ装置は、この小さなTCPパケットにも所定サイズのTCPヘッダを付加する必要があるため、最終的にクライアント装置に転送したいデータに対して、TCPヘッダ等の当該データを転送するための付随的なデータの割合を増加させることになり、結果的に伝送効率を悪化させてしまうという問題があった。
本発明は以上の点を考慮してなされたもので、データの伝送効率を格段に向上し得るデータ送信装置、データ送信方法及びデータ送信プログラムを提案しようとするものである。
かかる課題を解決するため本発明においては、トランスポート層のプロトコルによるコネクションを介してデータ受信装置からデータの送信要求を受け付けた際、当該データ受信装置との間に当該コネクションを確立したときに確定した最大データサイズを整数倍した値に基づいて、当該データを分割するときの分割サイズを決定し、データを分割サイズ毎に分割しトランスポート層のプロトコルに対応付けられた送信用バッファに書き込み、送信用バッファに書き込まれた分割サイズのデータをさらに最大データサイズ毎に分割してデータ受信装置へ送信するようにした。
これにより、送信用バッファに書き込まれた分割サイズのデータをさらに最大データサイズ毎に分割する際、当該最大データサイズに満たない小さなデータに分割せずに済み、データ受信装置へ送信するときのパケット数を必要最小限に抑えることができるので、各パケットに付加するパケットヘッダのデータ量を必要最小限に抑えることができる。
本発明によれば、送信用バッファに書き込まれた分割サイズのデータをさらに最大データサイズ毎に分割する際、当該最大データサイズに満たない小さなデータに分割せずに済み、データ受信装置へ送信するときのパケット数を必要最小限に抑えることができるので、各パケットに付加するパケットヘッダのデータ量を必要最小限に抑えることができ、かくしてデータの伝送効率を格段に向上し得るデータ送信装置、データ送信方法及びデータ送信プログラムを実現できる。
以下、図面について、本発明の一実施の形態を詳述する。
(1)データ送信システムの構成
図1に示すように、データ送信システム1は、送信用の各種データを保有するサーバ装置2と当該データを要求するクライアント装置3とがインターネット4を介して互いに接続された構成を有している。
データ受信装置としてのクライアント装置3は、ユーザの操作等に応じて、インターネット4を介してサーバ装置2へデータの送信を要求する。一方データ送信装置としてのサーバ装置2は、クライアント装置3からのデータの送信要求を待ち受けるようになされており、当該送信要求を受けた場合、これに応じて当該クライアント装置3へ当該データを送信するようになされている。
図2に示すように、サーバ装置2は、一般的なコンピュータと同様の構成を有し、CPU(Central Processing Unit)10によって全体を統括制御するようになされており、バス11を介して当該CPU10と接続されたROM(Read Only Memory)12又はハードディスクドライブ14に格納されたOS(Operating System)等の基本プログラムやデータ送信プログラム等の各種アプリケーションプログラムを読み出し、これをRAM(Random Access Memory)13に展開して実行することにより、データ送信等の各種処理を実行し得るようになされている。
ちなみにハードディスクドライブ14は、OSやデータ送信プログラム等の各種アプリケーションプログラムに加えて、送信用のデータ等も格納されるようになされている。
またサーバ装置2は、ネットワークインタフェース15により、インターネット4(図1)等のネットワークを介してクライアント装置3等と通信接続するようになされている。例えばサーバ装置2のCPU10は、ネットワークインタフェース15によってクライアント装置3からのデータの送信要求を取得すると、当該送信要求に応じたデータをハードディスクドライブ14から読み出し、当該ネットワークインタフェース15から当該データを当該クライアント装置3へ送信する。
図3に示すように、クライアント装置3は、サーバ装置2と一部類似した構成を有しており、CPU20によって全体を統括制御し、バス21を介して当該CPU20と接続されたROM22又はハードディスクドライブ24に格納されたOS等の基本プログラムやデータ受信プログラム等の各種アプリケーションプログラムを読み出し、これをRAM23に展開して実行することにより、データ受信等の各種処理を実行し得るようになされている。
またクライアント装置3は、インターネット4(図1)等のネットワークを介してサーバ装置2等と接続するネットワークインタフェース25、キーボードやマウス等(図示せず)でなりユーザの操作指示を受け付ける操作部26、表示画面を生成する表示制御部27及び当該表示画面を表示する表示部28を有している。
例えばクライアント装置3のCPU20は、操作部26を介したユーザの操作指示に応じてデータ受信プログラムを起動し、当該データ受信プログラムに従いネットワークインタフェース25を介してサーバ装置2と接続して、当該サーバ装置2からデータの情報を取得し、これを基に表示制御部27によりデータ一覧表示画面を生成して表示部28により画面表示させる。
(2)サーバ装置からのデータ送信
ところでデータ送信システム1(図1)では、上述したようにインターネット4を介してサーバ装置2とクライアント装置3とが接続されるようになされているが、このインターネット4では、標準的なプロトコルとしてTCP/IP(Transmission Control Protocol/Internet Protocol)が利用されている。
図4に示すように、サーバ装置2及びクライアント装置3は、それぞれTCP/IPの各階層に属する複数のプロトコルを実装しており、各プロトコルを相互に連携させることによって、最終的にサーバ装置2の最上位階層に属するデータ送信プログラム30からクライアント装置3の最上位階層に属するデータ受信プログラム40へデータを送信し得るようになされている。
ちなみに図4においては、本来4階層でなるTCP/IPの階層構造の一部を7階層でなるOSI(Open System Interconnection)参照モデルの階層構造と対応付けて示している。また図中の一点鎖線は、説明の都合上設けたものであり、TCP/IPの4階層を表すものではない。
クライアント装置3は、例えばユーザの操作指示に基づいてサーバ装置2からリアルタイムの映像データを受信する、いわゆるストリーミング配信を受ける場合、データ受信プログラム40から、データをリアルタイムに送受信するためのRTSP(Real Time Streaming Protocol)41へデータの送信要求を送出し、これをTCPポート44からサーバ装置2へ送信する。
サーバ装置2は、RTSP31によってTCPポート34を介してクライアント装置3からのデータの送信要求を受信し、これをデータ送信プログラム30へ渡す。データ送信プログラム30は、当該データの送信要求に応じて、要求されたデータの送信指示をRTSP31に供給する。
ちなみにサーバ装置2は、図示しないビデオカメラ等から入力された映像信号をリアルタイムで映像データに変換しており、当該映像データをクライアント装置3に対してストリーミング配信するようになされている。
サーバ装置2のRTSP31は、図5に示すように、送信すべきデータDA(すなわち映像データ)をTCPライトバッファ(後述する)への書き込みに適したサイズのデータ(以下これをチャンクデータDCと呼ぶ)に分割し、これを順次Multi Flow RTP(Real-time Transport Protocol)32に供給する。
Multi Flow RTP32(図4)は、複数のフロー(トランスポート層のプロトコルを介したデータ送信の流れ)によってデータを送信するプロトコルであり、データの送信に利用するTCPポート36のポート番号や使用するポート数等の制御情報をRTCP(RTP Control Protocol)33へ供給すると共に、RTSP31から供給されたチャンクデータDCをTCPポート36の動作状態に応じて当該TCPポート36に対応付けられたTCPライトバッファへ供給する。
RTCP33は、Multi Flow RTP32から供給された制御情報を基に、分割されたチャンクデータDCを再度結合するための制御情報等をTCPポート35を介してクライアント装置3へ送信する。
TCPポート36は、供給されたチャンクデータDCをさらに複数のTCPパケットデータDKに分割し(図5)、これにTCPヘッダを付加することによりTCPパケットを生成して、これをクライアント装置3へ順次送信する。
これに応じてクライアント装置3は、TCPポート45(図4)を介してTCPパケットの組み立て順序等を示す制御情報を受信し、当該制御情報をRTCP43へ供給する。RTCP43は、当該制御情報をTCPポート46及びMulti Flow RTP42へ供給する。
TCPポート46は、制御情報に基づいてサーバ装置2からのTCPパケットを順次受信すると共に、当該TCPパケットから取り出した複数のTCPパケットデータDKを結合することによりチャンクデータDCを復元し(図5)、これをMulti Flow RTP42へ供給する。
Multi Flow RTP42(図4)は、RTCP43から供給された制御情報に基づき、TCPポート46から供給されたチャンクデータDCを順次結合することにより元のデータDAを組み立て(図5)、これをデータ受信プログラム40へ渡す。これに応じてデータ受信プログラム40は、データDA(すなわち映像データ)を所定の映像再生プログラムへ渡して再生させることにより、当該映像データの映像をユーザに視聴させるようになされている。
このようにサーバ装置2は、複数のプロトコルによって元のデータDAをチャンクデータDC及びTCPパケットデータDKへと順次分割し、これをTCPコネクションを介して複数のTCPパケットとしてクライアント装置3へ送信するようになされている。
(3)スリーウェイハンドシェイクによるコネクションの確立
ところでサーバ装置2のCPU10は、TCPポート34においてクライアント装置3のTCPポート44(図4)と接続する際、いわゆるスリーウェイハンドシェイクを行うことにより、TCPコネクションを確立するようになされている。ここで、このスリーウェイハンドシェイクについて、図6のシーケンスチャートを用いて説明する。なお図6では、本来サーバ装置2とクライアント装置3との間に介在するルータ等のネットワーク機器を省略して示している。
クライアント装置3は、1番目の手順としてサーバ装置2への接続を要求するべく、TCPポート44(図4)からサーバ装置2へSYN(同期)パケットP1を送信する。このときクライアント装置3は、SYNパケットのオプション欄に当該クライアント装置3においてTCPパケットに格納可能なTCPパケットデータの最大データサイズを表すマックスセグメントサイズ(MSS:Max Segment Size)MS3を記述しておく。
ちなみにこのマックスセグメントサイズMS3は、クライアント装置3側(すなわち図1におけるクライアント装置3からインターネット4内のネットワーク機器迄の経路)のデータリンク層におけるMTU(Max Transmission Unit)に基づいて定まる値であり、当該クライアント装置3に予め設定されているものである。同様にサーバ装置2にも、当該サーバ装置2側のデータリンク層におけるMTUに基づいたマックスセグメントサイズMS2が設定されている。
サーバ装置2は、クライアント装置3からのSYNパケットP1を受信し、まず受信したマックスセグメントサイズMS3と当該サーバ装置2に予め設定されたマックスセグメントサイズMS2とを比較し、いずれか小さい方をこのTPCコネクションにおける確定マックスセグメントサイズSDとして確定する。続いてサーバ装置2は、2番目の手順として、オプション欄に確定マックスセグメントサイズSDを記述したSYN/ACK(同期/応答)パケットP2をTCPポート34(図4)からクライアント装置3へ送信する。
これに応じてクライアント装置3は、サーバ装置2からのSYN/ACKパケットP2を受信し、当該SYN/ACKパケットP2に記述されている確定マックスセグメントサイズSDを認識した上で、3番目の手順としてACK(応答)パケットP3をサーバ装置2へ送信する。サーバ装置2がこのACKパケットP3を受信した時点で、当該サーバ装置2とクライアント装置3との間にTCPコネクションが確立される。
このようにサーバ装置2は、TCPポート34とクライアント装置3のTCPポート44との間でTCPコネクションを確立させる際、スリーウェイハンドシェイクを行うようになされており、このとき同時に両者のマックスセグメントサイズMS2及びMS3のうち小さい方に合わせて確定マックスセグメントサイズSDを確定するようになされている。
またサーバ装置2は、実際上クライアント装置毎にその通信経路等に応じてマックスセグメントサイズの値が異なるため、各クライアント装置との間にTCPコネクションを確立する度に、各クライアント装置に合わせた確定マックスセグメントサイズSDを決定することになる。
(4)データ分割送信処理手順
ところでサーバ装置2は、各プロトコルによって元のデータDAをチャンクデータDCへ分割し、さらにTCPパケットデータDKに分割する際、当該チャンクデータDC及び当該TCPパケットデータDKの適切なサイズを決定した上で当該データを分割するようになされている。以下では、サーバ装置2が各プロトコルによってデータを段階的に分割してクライアント装置3へ送信するときの具体的なデータ分割送信処理手順RT1について、図7のフローチャートを用いて説明する。
実際上サーバ装置2のCPU10は、電源が投入されOSを起動した時点でデータ送信プログラムをハードディスクドライブ14から読み出して実行するようになされており、このときデータ分割送信処理手順RT1を開始してステップSP1へ移り、クライアント装置3からのTCPポート34(図4)を介した接続を待ち受ける。CPU10は、当該クライアント装置3から当該TCPポート34を介して接続されると、接続時(すなわちTCPコネクションの確立時)に当該TCPポート34を介してクライアント装置3からデータの送信要求を表すRTSPリクエストを受信し、当該クライアント装置3との間にRTSPコネクションを確立して次のステップSP2へ移る。
ステップSP2においてCPU10は、TCPポート34においてTCPコネクションを確立した際に決定した確定マックスセグメントサイズSDを認識し、次のステップSP3へ移る。
ステップSP3においてCPU10は、確定マックスセグメントサイズSDを整数倍した場合の、データ送信に利用するTCPポート36に対応付けられたTCPライトバッファに収まる範囲での最大倍数n(すなわちTCPライトバッファサイズSBを確定マックスセグメントサイズSDで割ったときの商に相当)を算出し、次のステップSP4へ移る。
ステップSP4においてCPU10は、確定マックスセグメントサイズSDと最大倍数nとを掛け合わせた値から後述するチャンクヘッダサイズSH(10バイト)を差し引くことにより、RTSP31(図4)において元のデータを分割する際の分割サイズとしてのチャンクサイズSCを決定し、次のステップSP5へ移る。
ステップSP5においてCPU10は、RTSP31によって元のデータDAをチャンクサイズSC毎のチャンクデータDCに分割し(図5)、これをMulti Flow RTP32へ順次供給して、次のステップSP6へ移る。
ステップSP6においてCPU10は、Multi Flow RTP32(図4)により、図8(A)に示すように、チャンクデータDCに10バイトのチャンクヘッダを付加して書込データDWとし、これをTCPポート36のTCPライトバッファに1つ書き込んで次のステップSP7へ移る。
ここでCPU10は、書込データDWのサイズ(以下これを書込サイズSWと呼ぶ)を確定マックスセグメントサイズSDと最大倍数nとの積としているため、当該最大倍数nの算出原理に基づき、当該書込データDWをTCPライトバッファに書き込んだ際、当該TCPライトバッファから溢れることなく確実に収めることができる。
ちなみにチャンクヘッダは、図8(B)に示すように、各チャンクデータDCに対して付与された一連の番号を表す4バイトのシリアルナンバーと、元のデータDAを一意的に表す6バイトのデータID(Identifier)とで構成されている。またデータIDは、元のデータDAにおけるハッシュ値であるMD5(Message Digest Algorithm 5)の先頭部分が用いられるようになされている。
ステップSP7においてCPU10は、TCPポート36により、TCPライトバッファに書き込まれた書込データDWを確定マックスセグメントサイズSD毎のTCPパケットデータDPに分割し、これに所定のTCPヘッダを付加することによりTCPパケットを生成して、TCPコネクションを介して全てのTCPパケットをクライアント装置へ順次送信してから次のステップSP8へ移る。
このときCPU10は、図5に示したように、TCPライトバッファに書き込んだ書込データDWの書込サイズSWを予め確定マックスセグメントサイズSDと最大倍数nとの積としているため、当該書込データDWをTCPパケットデータDPに分割する際にいわゆる「余り」を発生させることなく、確定マックスセグメントサイズSDに揃えることができる。
またCPU10は、書込データDWの書込サイズSWを確定マックスセグメントサイズSDと最大倍数nとの積としているため、当該書込データDWをTCPライトバッファに書き込んだ際、当該TCPライトバッファにおける余剰サイズRMを確定マックスセグメントサイズSDよりも小さくすることになる。すなわちCPU10は、当該書込サイズSWを、当該書込データDWをTCPパケットデータDPに分割する際に「余り」を発生させない範囲での最大サイズとしているため、TCPライトバッファを最も効率良く利用していることになる。
ステップSP8においてCPU10は、Multi Flow RTP32(図4)により、全てのチャンクデータDCをクライアント装置3へ送信し終えたか否かを判定する。ここで否定結果が得られると、このことはまだ送信していないチャンクデータDCが残っていることを表しており、このときCPU10は、次のチャンクデータDCをクライアント装置3へ送信するべく、再度ステップSP6へ戻る。
これに対してステップSP8において肯定結果が得られると、このことはクライアント装置3に対して全てのチャンクデータDCを送出し終えたことを表しており、このときCPU10は次のステップSP9へ移る。
ステップSP9においてCPU10は、データDAの送信を終了するべく、クライアント装置3との間のRTSPコネクションを開放し、次のステップSP10へ移ってデータ分割送信処理手順RT1を終了する。
これに応じてクライアント装置3は、上述したようにTCPパケットを順次受信してTCPパケットデータDKを結合することにより書込データDWを復元し、さらに当該書込データDWから取り出したチャンクデータDCを順次結合することにより元のデータDAを復元するようになされている。
(5)動作及び効果
以上の構成において、サーバ装置2は、クライアント装置3からデータDAの送信を要求されると、まずTCPコネクションの確立時に決定した確定マックスセグメントサイズSDを認識し、TCPライトバッファサイズSB以下に収まる当該確定マックスセグメントサイズSDの最大倍数nを算出して、さらにチャンクヘッダサイズSHを差し引くことによりチャンクサイズSCを決定する。
続いてサーバ装置2は、RTSP31によって、元のデータDAをチャンクサイズSC毎のチャンクデータDCに分割し、これにチャンクヘッダを付加することにより書込データDWを生成して、TCPライトバッファに当該書込データDWを1つずつ書き込む。さらにサーバ装置2は、TCPポート36によって、書込データDWを確定マックスセグメントサイズSD毎に分割してTCPパケットデータDKとし、これにTCPヘッダを付加することによりTCPパケットを生成してTCPコネクションを介してクライアント装置3へ順次送信する。
従ってサーバ装置2は、TCPライトバッファに書き込む書込データDWの書込サイズSWを予め確定マックスセグメントサイズSDと最大倍数nとの積としているため、当該書込データDWをTCPパケットデータDKに分割する際にいわゆる「余り」を発生させることが無く、当該TCPパケットデータDKのサイズを確定マックスセグメントサイズSDに揃えることができる。
すなわちサーバ装置2は、各TCPパケットに格納可能な最大サイズのデータを格納して送信することができるため、TCPパケット数を必要最小限に抑えることによりTCPヘッダとして送信するデータ量も必要最小限に抑えることができる。この結果サーバ装置2は、実際に送信する全てのデータのうち元のデータDAが占める割合を高めることができるので、伝送効率を向上させることができる。
特にサーバ装置2は、元のデータDAのサイズが大きい場合、当該データDAを分割することにより多数の書込データDWを生成する。このため、例えば書込データDWが確定マックスセグメントサイズDSの整数倍になっておらずTCPパケットデータDKに分割する際に毎回「余り」を発生させる場合と比較して、サーバ装置2は、送信するTCPパケットの数を削減してネットワークトラフィックを減少させ得ると共に伝送効率を飛躍的に向上することができ、これに伴いデータDAの送信に要する時間も短縮することができる。
同時にサーバ装置2は、確定マックスセグメントサイズSDの整数倍という制約の下で、書込サイズSWをTCPライトバッファサイズに収まる最大値に決定するので、書込データDWをTCPパケットデータDPに分割する際に「余り」を発生させない範囲で当該TCPライトバッファを最大限に利用することができ、この結果、TCPライトバッファに書込データDWを書き込む回数を極力少なく抑えてCPU10における処理負荷を軽減することができる。
またサーバ装置2は、クライアント装置3毎に確定マックスセグメントサイズSDが異なる値に設定されるものの、TCPコネクションを確立した際に決定した当該確定マックスセグメントサイズSDに応じて最適なチャンクサイズSCを決定するため、各クライアント装置3へデータDAを送信するときに、書込データDWをTCPパケットデータDKに分割する際の「余り」を発生させずに済む。
そのうえサーバ装置2は、TCPライトバッファのサイズではなくチャンクサイズSCを確定マックスセグメントサイズSDに応じて変更するため、当該TCPライトバッファのサイズを変更する際に必要なOSの再構築等の複雑な処理をせずに済む。
以上の構成によれば、サーバ装置2は、TCPコネクションの確立時に確定した確定マックスセグメントサイズSDを用いてTCPライトバッファサイズSB以下に収まる当該確定マックスセグメントサイズSDの最大倍数nを算出し、これを基にチャンクサイズSCを決定することにより、チャンクデータDCにチャンクヘッダを付加した書込データDWをTCPパケットデータDKに分割する際に、「余り」を発生させること無く確定マックスセグメントサイズSDに揃えることができるので、実際に送信する全てのデータのうち元のデータDAが占める割合を高めて伝送効率を向上させることができる。
(6)他の実施の形態
なお上述した実施の形態においては、サーバ装置2のTCPポート36(図4)とクライアント装置3のTCPポート46とによるTCPコネクションを1つのみ用いてTCPパケットデータDKを送信するようにした場合について述べたが、本発明はこれに限らず、サーバ装置2における複数のTCPポートとクライアント装置3における複数のTCPポートとをそれぞれ用いて複数のTCPコネクションを確立し、Multi Flow RTP32の制御の下でこれら複数のTCPコネクションによってTCPパケットデータDKを並行して送信するようにしても良い。
この場合サーバ装置2は、Multi Flow RTP32の制御に基づき、TCPポート毎に設けられたTCPライトバッファに書込データDWを振り分けながら順次書き込めば良く、これにより複数のTCPコネクションを用いて並行してTCPパケットデータDKを送信することができるので、ネットワーク上のデータ伝送効率を向上できると共にデータDAの送信に要する時間を短縮することができる。
さらにこの場合、仮に1本のTCPコネクションにおけるTCPパケットの送信が途切れてしまった場合でも、他のTCPコネクションを用いて当該TCPパケットを送信することができるので、TCPパケットの再送処理等によってデータの送信が完全に中断してしまうことを回避でき、伝送速度をあまり低下させずに済む。
また上述した実施の形態においては、データDAを分割して生成したTCPパケットデータDKをそれぞれ1回ずつ送信するようにした場合について述べたが、本発明はこれに限らず、複数のTCPコネクションを用いて2以上のTCPコネクションで同一のTCPパケットデータDKを送信するようにしても良い。これにより、サーバ装置2からデータDAを多重化して送信することができるので、ネットワーク上においてパケットの欠落やエラーの発生時が生じた場合であっても、クライアント装置3において複数のTCPコネクションを経たTCPパケットデータDK同士を元にエラー訂正等を行うことにより、データDAを復元することができるので、当該データDAの確実性を向上させることができる。
これと同様に、複数のRTSPコネクションを用いてサーバ装置2からデータDAを多重化してクライアント装置3へ送信するようにしても良く、この場合も当該クライアント装置3における当該データDAの確実性を向上させることができる。
また上述した実施の形態においては、チャンクサイズSCを決定する際、TCPライトバッファサイズSB以下に収まる確定マックスセグメントサイズSDの最大倍数nを算出するようにした場合について述べたが、本発明はこれに限らず、例えば何らかの理由により最大倍数nを用いることができない場合に、当該確定マックスセグメントサイズSDの所定倍数m(ただし1≦m≦n)を用いて、確定マックスセグメントサイズSDと当該所定倍数mとを掛け合わせた値からチャンクヘッダサイズSH(10バイト)を差し引いて当該チャンクサイズSCを決定するようにしても良く、要は書込データDWの書込サイズSWが確定マックスセグメントサイズSDの整数倍となっていれば良い。
さらに上述した実施の形態においては、チャンクへッダサイズSH(図8(B))を10バイトとするようにした場合について述べたが、本発明はこれに限らず、当該チャンクヘッダサイズSHを任意のバイト数としても良い。この場合、シリアルナンバーのバイト数については、元のデータDAを分割した全てのチャンクデータに一意の番号を設定し得る範囲で任意に設定しても良く、またデータIDのバイト数については当該データDAと他のデータとを確実に識別し得る範囲で任意に設定しても良い。さらにデータIDとしては、MD5を用いる以外にも、他の種々のハッシュ関数に基づいたハッシュ値や、ファイル名・ファイルサイズ・作成日時等を組み合わせた文字列等、データを識別し得る任意の値を用いるようにしても良い。
さらに上述した実施の形態においては、トランスポート層のプロトコルとしてTCPを用いるようにした場合について述べたが、本発明はこれに限らず、TCP以外の他のプロトコルを用いるようにしても良く、この場合、マックスセグメントサイズに相当する、当該プロトコルにおける送信可能な最大のデータサイズの整数倍に応じてチャンクサイズSCを算出すれば良い。
さらに上述した実施の形態においては、RTSP31(図4)により元のデータDAをチャンクデータDCに分割するようにした場合について述べたが、本発明はこれに限らず、例えば他の種々のセッション層のプロトコル、あるいはデータ送信プログラム30により当該データDAをチャンクデータDCに分割するようにしても良い。
さらに上述した実施の形態においては、Multi Flow RTP32によりRTPを利用してデータDAをクライアント装置3へ送信するようにした場合について述べたが、本発明はこれに限らず、例えばRTP以外の他のセッション層のプロトコルを利用して当該データDAを当該クライアント装置3へ送信するようにしても良い。
さらに上述した実施の形態においては、サーバ装置2からクライアント装置3に対して映像データのストリーミング送信を行う場合について述べたが、本発明はこれに限らず、当該サーバ装置2から当該クライアント装置3に対してオーディオコンテンツや画像データ等の種々の形式のデータを送信する場合に適用するようにしても良い。
さらに上述した実施の形態においては、サーバ装置2とクライアント装置3とがインターネット4に接続された場合について述べたが、本発明はこれに限らず、当該サーバ装置2と当該クライアント装置3とがLAN(Local Area Network)やWAN(Wide Area Network)等の種々のネットワークに接続された場合に適用するようにしても良い。
さらに上述した実施の形態においては、ストリーミング送信を行うサーバ装置2に本発明を適用するようにした場合について述べたが、これに限らず、例えばFTP(File Transfer Protocol)サーバやHTMLサーバ、或いはファイルの共有を許可しているパーソナルコンピュータ等、種々のネットワークを介して種々のデータを送信可能な種々のコンピュータに本発明を適用するようにしても良い。
さらに上述した実施の形態においては、データ分割送信処理手順RT1に示した一連の処理をサーバ2のCPU10がソフトウェアにより実現するようにした場合について述べたが、本発明はこれに限らず、各処理をハードウェアによって実現したり、或いはソフトウェアとハードウェアとを組み合わせて実現するようにしても良い。
さらに上述した実施の形態においては、サーバ装置2においてデータ送信プログラム等の各種プログラムをハードディスクドライブ14に予め記憶しておくようにした場合について述べたが、本発明はこれに限らず、当該データ送信プログラム等の各種プログラムを例えば通信インタフェース15を介して外部から取得するようにしても良く、或いは交換可能な記憶媒体である光ディスク(図示せず)やメモリースティック(登録商標)等に格納されて提供されるようにしても良く、また当該データ送信プログラム等の各種プログラムをROM12や半導体メモリ(図示せず)等に格納しても良い。
さらに上述した実施の形態においては、分割サイズ決定手段としてのデータ送信プログラム30及びRTSP31と、書込手段としてのMulti Flow RTP32と、送信手段としてのTCP36とによってデータ送信装置としてのサーバ装置2を構成する場合について述べたが、本発明はこれに限らず、その他種々の回路構成でなる分割サイズ決定手段と、書込手段と、送信手段とによってデータ送信装置を構成するようにしても良い。
本発明は、種々のデータを送信するデータ送信装置でも利用できる。
データ配信システムの全体構成を示すブロック図である。 サーバ装置の構成を示すブロック図である。 クライアント装置の構成を示すブロック図である。 プロトコルの対応関係を示す略線図である。 データ送信の様子の説明に供する略線図である。 スリーウェイハンドシェイクによるコネクション確立の説明に供するシーケンスチャートである。 データ分割送信処理手順を示すフローチャートである。 書込データの構造を示す略線図である。
符号の説明
1……データ送信システム、2……サーバ装置、3……クライアント装置、10、20……CPU、14、24……ハードディスクドライブ、30……データ送信プログラム、31、41……RTSP、32、42……Multi Flow RTP、33、43……RTCP、34、35、36、44、45、46……TCPポート、DA……データ、DC……チャンクデータ、DK……TCPパケットデータ。

Claims (7)

  1. トランスポート層のプロトコルによるコネクションを介してデータ受信装置からデータの送信要求を受け付けた際、当該データ受信装置との間に当該コネクションを確立したときに確定した最大データサイズを整数倍した値に基づいて、当該データを分割するときの分割サイズを決定する分割サイズ決定手段と、
    上記データを上記分割サイズ毎に分割しトランスポート層のプロトコルに対応付けられた送信用バッファに書き込む書込手段と、
    上記送信用バッファに書き込まれた上記分割サイズの上記データをさらに上記最大データサイズ毎に分割して上記データ受信装置へ送信する送信手段と
    を具えることを特徴とするデータ送信装置。
  2. 上記分割サイズ決定手段は、
    上記最大データサイズを整数倍した値のうち上記送信用バッファのサイズ以下となる最大値に基づいて上記分割サイズを決定する
    ことを特徴とする請求項1に記載のデータ送信装置。
  3. 上記トランスポート層のプロトコルによるコネクションを複数確立させるコネクション制御手段
    を具え、
    上記書込手段は、
    上記分割サイズ毎に分割した上記データを、上記複数のコネクションにそれぞれ対応付けられた複数の上記送信用バッファに振り分けてそれぞれ書き込み、
    上記送信手段は、
    上記複数の送信用バッファにそれぞれ書き込まれた上記分割サイズの上記データをそれぞれ上記最大データサイズ毎に分割して上記データ受信装置へそれぞれ送信する
    ことを特徴とする請求項1に記載のデータ送信装置。
  4. 上記トランスポート層のプロトコルは、TCP(Transmission Control Protocol)である
    ことを特徴とする請求項1に記載のデータ送信装置。
  5. 上記書込手段は、RTP(Real-time Transport Protocol)である
    ことを特徴とする請求項1に記載のデータ送信装置。
  6. トランスポート層のプロトコルによるコネクションを介してデータ受信装置からデータの送信要求を受け付けた際、当該データ受信装置との間に当該コネクションを確立したときに確定した最大データサイズを整数倍した値に基づいて、当該データを分割するときの分割サイズを決定する分割サイズ決定ステップと、
    上記データを上記分割サイズ毎に分割しトランスポート層のプロトコルに対応付けられた送信用バッファに書き込む書込ステップと、
    上記送信用バッファに書き込まれた上記分割サイズの上記データをさらに上記最大データサイズ毎に分割して上記データ受信装置へ送信する送信ステップと
    を具えることを特徴とするデータ送信方法。
  7. コンピュータに対して、
    トランスポート層のプロトコルによるコネクションを介してデータ受信装置からデータの送信要求を受け付けた際、当該データ受信装置との間に当該コネクションを確立したときに確定した最大データサイズを整数倍した値に基づいて、当該データを分割するときの分割サイズを決定する分割サイズ決定ステップと、
    上記データを上記分割サイズ毎に分割しトランスポート層のプロトコルに対応付けられた送信用バッファに書き込む書込ステップと、
    上記送信用バッファに書き込まれた上記分割サイズの上記データをさらに上記最大データサイズ毎に分割して上記データ受信装置へ送信する送信ステップと
    を実行させることを特徴とするデータ送信プログラム。
JP2005117271A 2005-04-14 2005-04-14 データ送信装置、データ送信方法及びデータ送信プログラム Pending JP2006295819A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2005117271A JP2006295819A (ja) 2005-04-14 2005-04-14 データ送信装置、データ送信方法及びデータ送信プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005117271A JP2006295819A (ja) 2005-04-14 2005-04-14 データ送信装置、データ送信方法及びデータ送信プログラム

Publications (1)

Publication Number Publication Date
JP2006295819A true JP2006295819A (ja) 2006-10-26

Family

ID=37415857

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005117271A Pending JP2006295819A (ja) 2005-04-14 2005-04-14 データ送信装置、データ送信方法及びデータ送信プログラム

Country Status (1)

Country Link
JP (1) JP2006295819A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120110230A1 (en) * 2005-03-30 2012-05-03 Canon Kabushiki Kaisha Device for arbitrating bus accesses and method for controlling same

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0822425A (ja) * 1994-07-08 1996-01-23 Fuji Xerox Co Ltd トランスポート通信装置
JP2002084289A (ja) * 2000-09-07 2002-03-22 Kddi Corp Tcp通信方法
JP2003209577A (ja) * 2002-01-16 2003-07-25 Ntt Docomo Inc 通信システム、通信方法、送信端末、受信端末及び中継機器
JP2005057482A (ja) * 2003-08-04 2005-03-03 Fujitsu Fip Corp データ転送方法、データ転送用プログラムおよび記録媒体
WO2005039150A1 (ja) * 2003-10-22 2005-04-28 Nec Corporation 通信装置およびその通信方法ならびにプログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0822425A (ja) * 1994-07-08 1996-01-23 Fuji Xerox Co Ltd トランスポート通信装置
JP2002084289A (ja) * 2000-09-07 2002-03-22 Kddi Corp Tcp通信方法
JP2003209577A (ja) * 2002-01-16 2003-07-25 Ntt Docomo Inc 通信システム、通信方法、送信端末、受信端末及び中継機器
JP2005057482A (ja) * 2003-08-04 2005-03-03 Fujitsu Fip Corp データ転送方法、データ転送用プログラムおよび記録媒体
WO2005039150A1 (ja) * 2003-10-22 2005-04-28 Nec Corporation 通信装置およびその通信方法ならびにプログラム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120110230A1 (en) * 2005-03-30 2012-05-03 Canon Kabushiki Kaisha Device for arbitrating bus accesses and method for controlling same
US8706939B2 (en) * 2005-03-30 2014-04-22 Canon Kabushiki Kaisha Device for arbitrating bus accesses and method for controlling same

Similar Documents

Publication Publication Date Title
US7447775B1 (en) Methods and apparatus for supporting transmission of streaming data
US9253289B2 (en) Network connection hand-off using state transformations
EP1678909B1 (en) Method, system and article for dynamic real-time stream aggregation in a network
KR101366364B1 (ko) 콘텐츠 블록 교환 협상 방법, 컴퓨터 프로그램, 및 피어 노드
US7055028B2 (en) HTTP multiplexor/demultiplexor system for use in secure transactions
US8488661B2 (en) Systems and methods for data streaming
US20120331160A1 (en) Multi-path transmission control protocol proxy service
US9578074B2 (en) Adaptive content transmission
JP2019528604A (ja) 仮想マルチパスデータトランスポートのためのシステム及び方法
KR102110421B1 (ko) 클라이언트 장치에 시청각 컨텐츠를 전달하는 시스템 및 방법
JP2006074744A (ja) 拡張可能なメディアの分散ストリーミングのシステムおよび方法
JP2006074781A (ja) ストリーミングメディアの消去符号化のシステム及び方法
JP2006079606A (ja) ピアツーピアネットワークでの受信側主導のシステム及び方法
US11271856B2 (en) Concept for segmenting an application buffer into data packets
KR102345473B1 (ko) 사물 인터넷 서비스를 제공하기 위한 QUIC-Proxy를 이용한 데이터 전달 방법 및 장치
US20230107093A1 (en) Data download method and apparatus, computer device, and storage medium
JP5091121B2 (ja) 埋め込み型システムのための高速データ処理・通信方法及び装置
He et al. Quanta: a toolkit for high performance data delivery over photonic networks
US7543072B1 (en) Method and system capable of performing a data stream over multiple TCP connections or concurrent interleave of multiple data streams over multiple TCP connections
JP4950938B2 (ja) データ転送方法とプロキシサーバおよびストレージサブシステム
CA3144009C (en) Data forwarding in a content delivery network
JP2006295819A (ja) データ送信装置、データ送信方法及びデータ送信プログラム
Bakri et al. HTTP/2 and QUIC for Virtual Worlds and the 3D Web?
WO2023203701A1 (ja) 制御装置、映像伝送システム、制御方法、及びプログラム
JP4418409B2 (ja) プレミアパケット識別装置、端末装置、プレミアパケット識別システムおよびプレミアパケット識別方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080311

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100201

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100311

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100428

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100922