JP2009194565A - データ送信装置、コンピュータプログラム及びデータ送信方法 - Google Patents

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

Info

Publication number
JP2009194565A
JP2009194565A JP2008032283A JP2008032283A JP2009194565A JP 2009194565 A JP2009194565 A JP 2009194565A JP 2008032283 A JP2008032283 A JP 2008032283A JP 2008032283 A JP2008032283 A JP 2008032283A JP 2009194565 A JP2009194565 A JP 2009194565A
Authority
JP
Japan
Prior art keywords
packet
transmission
packets
buffer
time
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.)
Granted
Application number
JP2008032283A
Other languages
English (en)
Other versions
JP4808227B2 (ja
Inventor
Junichi Hasegawa
順一 長谷川
Shigeo Kanariki
重夫 金力
Atsunori Yamamoto
敦則 山本
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.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
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 Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2008032283A priority Critical patent/JP4808227B2/ja
Publication of JP2009194565A publication Critical patent/JP2009194565A/ja
Application granted granted Critical
Publication of JP4808227B2 publication Critical patent/JP4808227B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Communication Control (AREA)

Abstract

【課題】TCPに従ってデータ通信の調整を行いつつ、ネットワークの遅延、輻輳又は障害などが発生したときには、これを意識することなく、リアルタイムでデータ送信できるデータ送信装置、コンピュータプログラム及びデータ送信方法を提供する。
【解決手段】TCPに基づき、ウィンドウサイズを上限としてパケットをフレームバッファ14に格納してから送信し、受信側通信装置2からの確認応答に応じてパケットをフレームバッファ14から解放し、受信側通信装置2からのACKがないためにフレームバッファ14内のパケットが解放されずにウィンドウサイズに達したと判定したとき、この判定からのACKを受信するまでの応答時間を計時し、計時した応答時間が所定時間に達すると判定したとき、受信側通信装置2からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを送信してフレームバッファ14から解放するようにしてある。
【選択図】図1

Description

本発明は、TCPに従ってストリーミングデータ転送を行うデータ送信装置、コンピュータプログラム及びデータ送信方法であって、特に、ネットワークの遅延又は障害などに対するエラー耐性を高めたデータ送信装置、コンピュータプログラム及びデータ送信方法に関する。
従来、インターネット通信など、様々な通信媒体に介した画像、音声データなどのデータ転送が盛んに行われている。特に、インターネット上のデータ転送において、従来から利用されているダウンロード型伝送方式に加えて、ストリーム型伝送方式によるサービスが増加している。
ダウンロード型伝送方式は、動画ファイル又は音声ファイルなどのマルチメディアデータを転送する場合、データファイルを配信サーバから通信端末装置の記憶部にダウンロードして一度記憶し、記憶したデータファイルを再生するので、受信側端末装置が全てのファイルをダウンロードするまで再生することができず、長時間再生又はリアルタイム再生などには向いていない。
一方、ストリーム型伝送方式は、データファイルを配信サーバから通信端末装置にダウンロードしつつ、ダウンロードしたファイルを再生するので、例えば、動画ファイルの長時間再生又はリアルタイム再生に向いている。
ストリーム型伝送方式において、パーソナルコンピュータ(以下、「PC」という。)、PDA(Personal Digital Assistant)又は携帯電話機などの送信側通信装置は、動画データにMPEG圧縮処理を施してMPEGストリームとし、これをIP(Internet Protocol)パケットとしてフレームバッファに格納する。格納してあるパケットは、配信サーバを介してTCP/IP通信で転送される。受信側通信装置は、パケットを受信し、動画データとして一定速度のリアルタイム再生を行う。
しかし、TCP/IP通信は、ネットワーク環境に応じて変動し易い。例えば、ネットワーク環境でデータの輻輳が発生した場合、TCP制御によるセグメント送信が停止し、送信側通信装置でリアルタイムデータのフレームバッファがオーバーフローし、受信側通信装置で出力すべきリアルタイムデータのフレームバッファがアンダーフローし、送信できないデータを廃棄する。このように、TCP/IP通信は、受信側通信装置でのリアルタイム再生を不可能とする問題を有している。
そこで、従来、UDP(User Datagram Protocol)に基づくRTP(Real-time Transport Protocol)及びRTCP(RTP Control Protocol)を用いて、廃棄されたデータの再送処理を行うよう工夫されたデータ通信装置及びデータ送信システムが提案された(例えば、特許文献1)。
特開2003−169040号公報
しかしながら、UDPは、送受信間で送達確認などを一切行わない無手順方式でのデータ転送であり、通信中のパケット紛失又はデータの誤り検出などを行わない。そのため、特許文献1に記載された通信装置にあっては、TCPによる通信に比べてデータ通信の信頼性が著しく低下するという問題を有している。
本発明はかかる事情に鑑みてなされたものであり、TCPとして規定された通信規約に基づき、ウィンドウサイズを上限として送信前のパケットをバッファに格納して送信し、送信先からの確認応答に応じてパケットをバッファから解放し、送信先からの確認応答がないためにバッファ内のパケットが解放されずにウィンドウサイズに達したと判定したとき、この判定から確認応答を受信するまでの応答時間を計時し、計時した応答時間が所定時間に達すると判定したとき、送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを送信してバッファから解放するようにしてあることにより、TCPに従ってデータ通信の調整を行いつつ、ネットワークの遅延、輻輳又は障害などが発生したときには、これを意識することなく、リアルタイムでデータ送信できるデータ送信装置、コンピュータプログラム及びデータ送信方法を提供することを目的とする。
本発明に係るデータ送信装置は、TCPとして規定された通信規約に基づき、送信先からの確認応答に応じて動画データのパケットを送信するデータ送信装置において、前記送信先からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットを複数格納するバッファと、該バッファに格納してある各パケットを順次、前記送信先に送信する送信部と、該送信部で送信した各パケットが前記送信先に到達したことを示す確認応答を前記送信先から受信する受信部と、該受信部で受信した前記確認応答により確認されたパケットを格納してあるバッファの領域を解放し、該領域に新たなパケットを格納する制御部と、解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定するバッファ判定部と、該バッファ判定部で解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記受信部で確認応答を受信するまでの応答時間が予め設定してある単位時間に達するか否かを判定する時間判定部とを備え、前記制御部は、前記時間判定部で応答時間が単位時間に達すると判定したとき、前記送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを前記送信部に送信させ、該パケットを格納してあるバッファの領域を解放するようにしてあることを要件とする。
また、本発明に係るデータ送信装置は、前記所定個は、インタレース又はプログレッシブ形式に従って分割された一画面の各ラインに相当するパケット数であることを要件とする。
また、本発明に係るデータ送信装置は、前記単位時間は、前記所定個のパケットを前記送信部で送信するのに要する時間であることを要件とする。
また、本発明に係るコンピュータプログラムは、コンピュータに、TCPとして規定された通信規約に基づき、送信先からの確認応答に応じて動画データのパケットを送信させるコンピュータプログラムにおいて、前記送信先からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットをバッファに複数格納させるステップと、バッファに格納してある各パケットを順次、前記送信先に送信させるステップと、送信した各パケットが到達したことを示す確認応答を前記送信先から受信させるステップと、受信した確認応答により確認されたパケットを格納してあるバッファの領域を解放し、該領域に新たなパケットを格納させるステップと、解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定させるステップと、解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記確認応答を受信するまでの応答時間が予め設定してある単位時間に達する否かを判定させるステップと、応答時間が単位時間に達すると判定したとき、送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを送信させ、該パケットを格納してあるバッファの領域を解放させるステップとをコンピュータに実行させることを要件とする。
更にまた、本発明に係るデータ送信方法は、TCPとして規定された通信規約に基づき、送信先からの確認応答に応じて動画データのパケットを送信するデータ送信方法において、前記送信先からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットをバッファに複数格納し、バッファに格納してある各パケットを順次、前記送信先に送信し、送信した各パケットが到達したことを示す確認応答を前記送信先から受信したとき、受信した確認応答に基づいて確認されたパケットを格納してあるバッファの領域を解放して該領域に新たなパケットを格納し、解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定し、解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記確認応答の受信までの応答時間が予め設定してある単位時間に達するか否かを判定し、応答時間が単位時間に達すると判定したとき、前記送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを送信させ、該パケットを格納してあるバッファの領域を解放することを要件とする。
本発明にあっては、TCPとして規定された通信規約に基づき、バッファに格納してある各パケットを順次送信し、送信先から確認応答を受信した場合、確認応答により確認されたパケットを格納してあるバッファの領域から解放し、該領域に新たなパケットを格納する。一方、送信先から確認応答がなく解放されていないバッファの領域がウィンドウサイズに達した場合、このときから確認応答を受信するまでの応答時間が所定の単位時間に達するか否かを判定し、応答時間が所定の単位時間に達したと判定したとき、送信先から確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを順次送信し、このパケットを格納してあるバッファの領域を解放することにより、ネットワークの遅延、輻輳又は障害などを意識することなく、リアルタイムでデータ送信する。
本発明にあっては、TCPに従って通信する相手との間で通信の調整を行いつつ、ネットワークの遅延、輻輳又は障害などが発生したときには、これを意識することなく、リアルタイムでデータ送信できる。
以下、本発明に係るデータ送信装置、コンピュータプログラム及びデータ送信方法について、実施の形態を示す図面に基づいて説明する。図1は本発明に係るデータ送信システムの全体構成を示すブロック図である。本発明に係るデータ送信システムは、データ送信装置である送信側通信装置1と送信先となる受信側通信装置2とを備える。
送信側通信装置1及び受信側通信装置2は、携帯電話機、通信機能付きのPDA(Personal Data Assistance)又はPCなどが該当する。本実施の形態では、送信側通信装置1及び受信側通信装置2をPCとする一例を説明する。
送信側通信装置1は、デジタルビデオストリームを入力するための入力インタフェース10と、デジタルビデオストリームに各種処理を施す情報処理部11と、プログラムを記憶する補助記憶装置12と、TCP(Transmission Control Protocol)に従ってパケットを送信するためのTCP制御部13と、送信すべきパケットを一時的に格納するフレームバッファ14と、データ通信を行うための通信インタフェース15とを備え、各ハードウェアは、バス16により相互に接続される。
入力インタフェース10は、例えば、ITU−R.BT656に基づきビデオカメラなどの記録機器(図示せず。以下同じ。)に接続される。入力インタフェース10は、補助記憶装置12に記憶してあるプログラムに従い、接続された記録機器からデジタルビデオストリームを取得して情報処理部11へ出力する。デジタルビデオストリームは、後述するようインタレース又はプログレッシブ形式に従って分割された一画面の1ライン分に相当する動画データを含んでいる。
情報処理部11は、補助記憶装置12に記憶してあるプログラムに従い、デジタルビデオストリームから動画データを抽出してパケット化し、このパケットをフレームバッファ14に書き込む。
補助記憶装置12は、例えば、磁気記憶方式のハードディスクなどが該当し、本発明に係るデータ送信方法を実行するためのプログラムを記憶する。
TCP制御部13は、補助記憶装置12に記憶してあるプログラムに従い、受信側通信装置2へのパケットの送信を制御する。TCP制御部13は、時間を計測する計時手段130と、計測した時間に関する判定を行う時間判定手段131と、ウィンドウサイズに基づいて送信すべきパケットを決定するウィンドウ制御手段132と、決定されたパケットを送信するセグメント送信制御手段133という機能を有する。
TCP制御部13は、計時手段130として機能する場合、ウィンドウ制御手段132から出力された後述のバッファオーバーフロー通知に従い、受信側通信装置2から確認応答(以下、ACK(Acknowledgement)という。)を受信するまでの応答時間を計測し、計測した時間を時間判定手段131へ出力する。
TCP制御部13は、時間判定手段131として機能する場合、計時手段130から受け付けた応答時間が単位時間に達するか否かを判定し、応答時間が単位時間に達すると判定したときにタイムアウト通知をウィンドウ制御手段132へ出力する。単位時間の具体的な値は、後述にて説明する。
TCP制御部13は、ウィンドウ制御手段132として機能する場合、フレームバッファ14の未解放領域がウィンドウサイズに相当するデータ量に達するか否かを判定し、この未解放領域がウィンドウサイズに相当するデータ量に達すると判定したときにバッファオーバーフロー通知を計時手段130へ出力する。また、TCP制御部13は、通信インタフェース15を介して受信したACK受信通知に従うか、又は時間判定手段131から出力されたタイムアウト通知に従い、確認シーケンス番号及び次送信シーケンス番号を更新してセグメント送信制御手段133へ出力する。また、TCP制御部13は、受信側通信装置2から同じシーケンス番号を含むACKを複数回(例えば3回)受信したとき、このシーケンス番号が示すパケットの再送通知をセグメント送信制御手段133へ出力する。
TCP制御部13は、セグメント送信制御手段133として機能する場合、ウィンドウ制御手段132から出力された確認シーケンス番号及び次送信シーケンス番号に従うか、又は再送通知に従い、フレームバッファ14からパケットを読み出して受信側通信装置2へ送信する。
フレームバッファ14は、パケットを送信する前に格納する半導体記憶装置である。フレームバッファ14の記憶領域は、概念的にインタレース又はプログレッシブ形式に従って分割された一画面のラインをなしている。記憶領域については、後述にて説明する。
通信インタフェース15は、セグメント送信制御手段133の指示に従い、フレームバッファ14から読み出したパケットを受信側通信装置2へ送信するか、又は受信側通信装置2から送信されたACKを受信する。
受信側通信装置2は、デジタルビデオストリームを出力するための出力インタフェース20と、デジタルビデオストリームへの復号などの各種処理を行う情報処理部21と、プログラムを記憶する補助記憶装置22と、TCPに従ってパケットを送信するためのTCP制御部23と、パケットを一時的に格納するフレームバッファ24と、データ通信を行うための通信インタフェース25とを備え、各ハードウェアは、バス26により相互に接続される。
出力インタフェース20は、液晶ディスプレイなどの動画出力装置(図示せず。以下同じ。)に接続される。出力インタフェース20は、補助記憶装置22に記憶してあるプログラムに従い、接続された動画出力装置へデジタルビデオストリームを出力する。
情報処理部21は、補助記憶装置22に記憶してあるプログラムに従い、パケットを復号して動画データとし、デジタルビデオストリームに変換して出力インタフェース20へ出力する。
補助記憶装置23は、例えば、磁気記憶方式のハードディスクなどが該当し、本発明に係るデータ送信方法を実行するためのプログラムを記憶する。
TCP制御部23は、補助記憶装置22に記憶してあるプログラムに従い、送信側通信装置1からのパケットの受信を制御する。TCP制御部23は、時間を計測する計時手段230と、計測した時間に関する判定を行う時間判定手段231と、ウィンドウサイズに基づき次回受信すべきパケットを決定するウィンドウ制御手段232と、受信したパケットについてのACKを送信するACK送信制御手段233という機能を有する。
TCP制御部23は、計時手段230として機能する場合、通信インタフェース25から出力されたパケット受信通知に従うか、又はACK送信制御手段133から出力されたACK送信通知に従い、次のパケットを受信するまでの待ち時間を計測し、計測した待ち時間を時間判定手段231へ出力する。
TCP制御部23は、時間判定手段231として機能する場合、計時手段230から受け付けた待ち時間が単位時間に達するか否かを判定し、待ち時間が単位時間に達すると判定したときにタイムアウト通知をウィンドウ制御手段232へ出力する。
TCP制御部23は、ウィンドウ制御手段232として機能する場合、通信インタフェース25から出力されたパケット受信通知に従うか、又は時間判定手段231から出力されたタイムアウト通知に従い、次回受信すべきパケットのシーケンス番号(以下、ACK番号という。)を更新してACK送信制御手段233へ出力する。パケット受信通知に従う更新では、受信したパケットに含まれるACK番号に1を加算する。また、タイムアウト通知に従う更新では、前回更新したパケットのシーケンス番号に、インタレース又はプログレッシブ形式に従って分割された一画面の1ライン分に相当するパケット数を加算する。
TCP制御部23は、ACK送信制御手段233として機能する場合、ウィンドウ制御手段232から出力されたシーケンス番号を含むACKを通信インタフェース25を介して送信側通信装置1へ送信する指示を出力し、ACK送信通知を出力する。
フレームバッファ24は、受信したパケットを格納する半導体記憶装置である。フレームバッファ24の記憶領域は、概念的にインタレース又はプログレッシブ形式に従って分割された一画面のラインをなしている。記憶領域については、後述にて説明する。
通信インタフェース25は、ACK送信制御手段233の指示に従い、ACKを送信側通信装置1へ送信するか、又は送信側通信装置1からパケットを受信してパケット受信通知を出力する。
上述したハードウェアを有する送信側通信装置1は、TCPに従い、動画データをパケット化し、このパケットを受信側通信装置2へ送信する。そこで、このパケットの内容について説明する。図2は本発明で用いるパケットの内容を説明する概念図である。
パケットは、送信側通信装置1を示す発信ポート、受信側通信装置2を示す着信ポート、送信したパケットの位置を示すシーケンス番号、次に受信すべきパケットのシーケンス番号を示すACK番号、TCPが運んでいるパケットの始点を示すデータオフセット、拡張用のRSV、制御用のフラグ、送信先からのACKを待たずに送信できるデータサイズを示すウィンドウサイズ、データの破損を確認するためのチェックサム、緊急用のデータを格納するための緊急ポインタ、オプションの種別、オプションデータのバイト数、本発明で用いる単位時間となるタイマ設定、復旧を示すオプションフラグ、復旧時のID認証を行うためのオプションID、オプションNOP及びセグメントデータを含む。これらのデータは、送信側通信装置1のTCP制御部13及び受信側通信装置2のTCP制御部23で夫々記憶されている。
シーケンス番号は、送信側通信装置1において、確認シーケンス番号及び次送信シーケンス番号として管理される。確認シーケンス番号は、受信側通信装置2が正しく受信したパケットの終了位置を示し、次送信シーケンス番号は、次回送信すべきパケットの開始位置を示す。送信側通信装置1は、原則として、受信側通信装置2から受信したACKに基づいて確認シーケンス番号を決定し、前回更新した次送信シーケンス番号に1を加算して次送信シーケンス番号を決定する。また、送信側通信装置1は、タイムアウトした場合、前回決定した確認シーケンス番号にインタレース又はプログレッシブ形式に従って分割された一画面の1ライン分に相当するパケット数を加算して次送信シーケンス番号を決定する。受信側通信装置2は、受信したパケットに含まれるシーケンス番号を参照することにより、順番通りにパケットを受信できない場合であっても、正しい順番にパケットを並べ替えて動画データに復号することができる。
ACK番号は、受信側通信装置2において、次回受信すべきパケットのシーケンス番号として管理されている。受信側通信装置2は、受信したパケットに含まれるACK番号を読み出してACK番号に1又はインタレース又はプログレッシブ形式に従って分割された一画面の1ライン分に相当するパケット数を加算し、加算したACK番号をACKとして送信側通信装置1へ送信する。送信側通信装置1は、受信したACKと次送信シーケンス番号とを比較することにより、受信側通信装置2が正しく受信できたか否かを判断できる。TCPに従ってデータ送信を行う本発明は、通信間による確認をすることにより、UDPと比較して高い信頼性を確保できる。
緊急ポインタには、インタレース又はプログレッシブ形式に従って分割された一画面の1ライン分に相当するパケット数を格納する。受信側通信装置2は、受信したパケットに含まれる緊急ポインタを読み出し、この緊急ポイント内のパケット数に基づいてタイムアウトした場合のACK番号を更新する。
ウィンドウサイズは、ACK番号から何バイトのパケットを受信できるかを示すものである。送信側通信装置1は、通信路の開設時に受信側通信装置2からウィンドウサイズを受信し、ウィンドウサイズを上限としてパケットを送信する。ウィンドウサイズは、送信側通信装置1がパケットを送信してフレームバッファ14から解放したとき、送信したパケット数だけ増大し、送信側通信装置1がパケットを送信できず、新たなパケットが格納され続けたとき、減少する。
従来の装置は、ウィンドウサイズが減少し続けて値が0となる場合、パケット送信ができなくなる。しかし、送信側通信装置1にあっては、パケットの送信が不可能とならないよう、ウィンドウ制御手段132でバッファオーバーフロー通知を出力し、計時手段130でACKを受信するまでの応答時間を計測し、計測した応答時間が単位時間に達したとき、強制的にパケットを送信する。本実施の形態では、この計時行為を「タイマ監視」と称して説明する。単位時間は、タイマ値に相当し、通信路の開設時に送信側通信装置1から受信側通信装置2に伝えられる。受信側通信装置2は、受信したタイマ値に基づいてパケット受信の待ち時間を時間判定手段231で判定する。
タイマ値は、例えば、インタレース又はプログレッシブ形式に従って分割された一画面の各ライン当たり64μs(マイクロ秒)が好適である。動画データは、後述するよう、少なくとも1ライン分のパケットが消失した場合に復号されない。送信側通信装置1は、インタレース又はプログレッシブ形式に従って分割された一画面の各ラインに相当するパケットを約63555ns(ナノ秒)でリアルタイムに入力する。従って、本発明で用いるタイマ値は、1ライン当たり約64μsに設定される。
送信側通信装置1は、受信側通信装置2からACKを受信できないときにタイマ監視を開始する。そして、送信側通信装置1は、応答時間が単位時間に達したと判定したとき、ACKを受信することなく、フレームバッファ14に格納してあるパケットを受信側通信装置2へ送信する。一方、受信側通信装置2は、送信側通信装置1からパケットを受信できないときにタイマ監視を実行する。そして、受信側通信装置2は、待ち時間が単位時間に達したと判定したとき、パケットを受信することなく、ACKを送信側通信装置1へ送信する。
その結果、本発明に用いるデータ送信システムにあっては、TCPに従って通信する相手との間で通信の調整を行いつつ、ネットワークの遅延、輻輳又は障害などが発生したときには、これを意識することなく、リアルタイムでデータ送信できる。
ところで、ネットワークの遅延、輻輳又は障害などは、送信側通信装置1から受信側通信装置2へパケット送信するときか、受信側通信装置2から送信側通信装置1へACK送信するときに発生する。そこで、ネットワークの遅延、輻輳又は障害などについて、想定されうる様々な態様を実施例1乃至3として説明する。以下の実施例では、ネットワークの障害が発生したときの一例を説明するが、ネットワークの遅延又は輻輳などが発生したときも同様である。
実施例1.
実施例1では、受信側通信装置2がパケットを受信できない場合の送信側通信装置1及び受信側通信装置2で実行するデータ送信処理を説明する。図3は実施例1におけるデータ送信処理を説明する概念図である。
図3は、データ送信処理の手順を左から右への時系列により示し、送信側通信装置1のデータ送信処理を上段に示し、受信側通信装置2のデータ送信処理を下段に示し、送信対象となるパケットのシーケンス番号をFx(但し、xは自然数である。)で示し、確認シーケンス番号を確認SN、ACK番号を次SNと示す。
送信側通信装置1は、パケットF1を受信側通信装置2へ送信し、確認シーケンス番号をF1とする。受信側通信装置2は、パケットF1を受信し、TCP制御部23で管理するACK番号を初期値からF2に更新し、タイマ監視を開始する。
その後、送信側通信装置1は、パケットF2乃至F7を受信側通信装置2へ順次送信する。しかし、受信側通信装置2は、ネットワークの障害が発生したことにより、パケットF2乃至F7を受信できず、ACK番号を更新してACKを送信することができないため、待ち時間を計測する。その結果、受信側通信装置2は、計測した待ち時間が単位時間に達すると判定したとき、タイムアウトとしてACK番号をF5に更新する。ここで受信側通信装置2がF5に更新したのは、インタレース又はプログレッシブ形式に従って分割された一画面の1ライン分に相当するパケット数が4個となるからである。受信側通信装置2は、ACK番号F5のACKを送信側通信装置1へ送信し、タイマ監視を再び開始する。
送信側通信装置1は、受信側通信装置2からACKを受信し、このACKに基づいて確認シーケンス番号をF5に更新する。その結果、送信側通信装置1は、受信側通信装置2がパケットF1乃至F4を正しく受信したとみなし、フレームバッファ14からパケットF1乃至F4を解放し、新たなパケットを格納する。その後、送信側通信装置1は、パケットF8乃至F11を受信側通信装置2へ順次送信する。
実施例2.
実施例2では、送信側通信装置1がACKを受信できない場合の送信側通信装置1及び受信側通信装置2で実行するデータ送信処理を説明する。図4及び図5は実施例2におけるデータ送信処理を説明する概念図である。
図4及び図5は、図3と同様、データ送信処理の手順を左から右への時系列により示し、送信側通信装置1のデータ送信処理を上段に示し、受信側通信装置2のデータ送信処理を下段に示し、送信対象となるパケットのシーケンス番号をFx(但し、xは自然数である。)で示し、確認シーケンス番号を確認SN、ACK番号を次SNと示す。
送信側通信装置1は、パケットF1を受信側通信装置2へ送信し、確認シーケンス番号をF1とする。受信側通信装置2は、パケットF1を受信し、ACK番号をF2に更新してタイマ監視を開始する。
送信側通信装置1は、パケットF2乃至F7を順次送信するが、受信側通信装置2は、ネットワークの障害が発生したことにより、これらのパケットを受信できず、ACK番号を更新してACKを送信することができないため、待ち時間を計測する。その結果、受信側通信装置2は、待ち時間が単位時間に達すると判定したとき、タイムアウトとしてACK番号をF5に更新し、ACK番号F5のACKを送信側通信装置1へ送信する。
一方、送信側通信装置1は、ネットワークの障害により、受信側通信装置2からACKを受信できないので、フレームバッファ14からパケットを解放できずに新たなパケットを格納し続けてウィンドウサイズを減少させる。送信側通信装置1は、ウィンドウサイズが0になるまで、F8乃至F15を順次送信する。
このとき、受信側通信装置2は、待ち時間が単位時間に達すると判定する都度タイムアウト通知を出力し、タイムアウトとしてACK番号をF9、F13へ順次更新してタイマ監視を開始する。受信側通信装置2は、ACK番号をF9、F13としたACKを送信側通信装置1へ順次送信する。
送信側通信装置1は、ネットワークの障害により、受信側通信装置2からACKを受信できないので、フレームバッファ14からパケットF8乃至F15を解放できずに新たなパケットを格納し続けて送信可能なウィンドウサイズを更に減少させる。送信側通信装置1は、送信可能なウィンドウサイズが0になったとき、バッファオーバーフローと判定してパケットの送信を停止し、タイマ監視を開始する。
受信側通信装置2は、送信側通信装置1がパケットの送信を停止しているので、パケットを受信できず、待ち時間を計測する。受信側通信装置2は、待ち時間が単位時間に達すると判定したとき、タイムアウトとしてACK番号をF17に更新してタイマ監視を再び開始し、ACK番号F17のACKを送信側通信装置1へ送信する。
送信側通信装置1は、ネットワークの障害により、受信側通信装置2からACKを送信できずにタイマ監視を継続する。送信側通信装置1は、応答時間が単位時間に達したと判定したとき、タイムアウトとして確認シーケンス番号をF5に更新する。ここで送信側通信装置1が確認シーケンス番号をF5に更新したのは、ACKを参照できないため、最後に更新した確認シーケンス番号であるF1にインタレース又はプログレッシブ形式に従って分割された一画面の1ライン分に相当するパケット数を加算したからである。送信側通信装置1は、受信側通信装置2がパケットF4まで正しく受信したとみなし、時系列的に古く格納した順序に従い、フレームバッファ14から所定個のパケットを解放し、解放された領域に新たなパケットを格納する。所定個のパケットは、後述するように、インタレース又はプログレッシブ形式に従って分割された一画面の1ライン分に相当するパケット数である4個とする。送信側通信装置1は、パケットF17乃至F20を受信側通信装置2へ順次送信する。
受信側通信装置2は、ネットワークの障害により、送信側通信装置1からパケットF17乃至F20を受信できず、ACKを送信できない。送信側通信装置1は、受信側通信装置2からACKを受信できないので、フレームバッファ14からパケットF17乃至F20を解放できない。送信側通信装置1は、送信可能なウィンドウサイズが0となったとき、パケットの送信を停止してタイマ監視を開始する。
実施例3.
実施例3では、障害状態にあったネットワークが復旧した場合の送信側通信装置1及び受信側通信装置2で実行するデータ送信処理を説明する。図6は実施例3におけるデータ送信処理を説明する概念図、図7は実施例3におけるSN制御を説明する図である。
図6は、図3と同様、データ送信処理の手順を左から右への時系列により示し、送信側通信装置1のデータ送信処理を上段に示し、受信側通信装置2のデータ送信処理を下段に示し、送信対象となるパケットのシーケンス番号をFnx(但し、xは自然数である。)で示し、確認シーケンス番号を確認SNと、ACK番号を次SNと示す。また、実施例3では、ネットワークの障害により、ウィンドウサイズが0の状態にあり、送信側通信装置1がタイマ監視を実行している時点から説明する。
送信側通信装置1は、応答時間が単位時間に達してタイムアウトになったとき、確認シーケンス番号をFx(Fnより前の番号)に更新し、パケットFn1乃至Fn4を受信側通信装置2へ順次送信する。しかし、送信側通信装置1は、ネットワークの障害により、受信側通信装置2からACKが返ってこないので、フレームバッファ14からパケットFn1乃至Fn4を解放できない。その結果、送信側通信装置1は、ウィンドウサイズが再び0となり、パケットの送信を停止してタイマ監視を開始する。
その後、送信側通信装置1及び受信側通信装置2のデータ送信処理が進み、送信側通信装置1がパケットFn4まで送信し、受信側通信装置2がACK番号Fn17のACKを送信するとき、ネットワークが復旧したとする。送信側通信装置1は、このACKを受信することにより、タイマ監視を停止し、確認シーケンス番号及び次送信シーケンス番号をFn17に更新する。ここで送信側通信装置1が確認シーケンス番号及び次送信シーケンス番号をFn17に更新したのは、ACK番号であるFn17が次送信シーケンス番号より大きくウィンドウサイズ範囲外のためである。送信側通信装置1は、受信側通信装置2がシーケンス番号Fn17までのパケットを正しく受信したとみなし、フレームバッファ14からシーケンス番号Fn4までのパケットを解放する。その結果、ウィンドウサイズは、増大して最大限(FULL)の状態になる。このとき、受信側通信装置2は、ACK番号Fn17からウィンドウサイズとなるαまでのパケットを受信可能とする。
その後、送信側通信装置1及び受信側通信装置2は、通常のTCPに従ったデータ送信を行う。
本発明で用いるタイマ値、及びタイムアウト時に時系列的に古く格納した順序に従い解放するパケットの所定個は、インタレース又はプログレッシブ形式に従って分割された一画面の1ライン分に相当するパケット数が好適である。従って、送信側通信装置1のフレームバッファ14及び受信側通信装置2のフレームバッファ24は、インタレース又はプログレッシブ形式に従って分割された一画面のラインに従い、データを格納する。図8は本発明で用いるフレームバッファ14の格納例を説明する概念図、図9は本発明で用いるセグメントデータを説明する概念図である。
デジタルビデオストリームは、デジタルライン上に水平/垂直の有効映像期間終了点の識別子であるEAV(End of Active Video)コードと、ブランキングと、水平/垂直の有効映像期間開始点の識別子であるSAV(Start of Active Video)コードとを備え、アクティブライン上にインタレース又はプログレッシブ形式に従って分割された一画面のラインに相当する1440バイトの動画データを備える。送信側通信装置1の情報処理部11は、デジタルビデオストリームから、この1440バイトの動画データを抽出する。
情報処理部11は、この1440バイトの動画データを更に8等分して180バイトとし(図8参照)、データの位置情報を示す5バイトのヘッダを付した185バイトのセグメントデータを生成する(図9参照)。このセグメントデータは、TCP/IPでのパケットとなる。情報処理部11は、5バイトの位置情報に対応するフレームバッファ14の領域に書き込む(図8参照)。尚、送信側通信装置1のフレームバッファ14の格納例を説明したが、受信側通信装置2のフレームバッファ24の格納も同じようになされる。
その結果、送信側通信装置1がウィンドウサイズを強制的に進めて飛躍したシーケンス番号のパケットを順次送信し、フレームバッファ24への格納が飛躍した場合であっても、フレームバッファ24の領域には、飛躍前に受信したパケットが格納されているから、受信側通信装置2は、このパケットを利用して動画データを復号することができ、復号した動画データをデジタルビデオストリームとしてリアルタイム再生することができる。但し、再生されたデジタルビデオストリームの画像にあっては、散点的にブロックノイズが生じる。
最後に、送信側通信装置1が実行するデータ送信処理の手順について説明する。図10は送信側通信装置1が実行するデータ送信処理の手順を示すフローチャートである。
送信側通信装置1は、入力インタフェース10に接続された記録機器からデジタルビデオストリームを取得すると共に、TCP制御部13で送信要求を受け付けたか否かを判断する(S101)。その結果、送信側通信装置1は、TCP制御部13で送信要求を受け付けていないと判断した場合(S101でNO)、処理を完了する。
一方、送信側通信装置1は、TCP制御部13で送信要求を受け付けたと判断した場合(S101でYES)、情報処理部11でデジタルビデオストリームから動画データを抽出してパケット化し、TCP制御部13でこのパケットを受信側通信装置2へセグメント送信する(S102)。受信側通信装置2は、パケットを正しく受信した場合にACKを返すので、送信側通信装置1は、受信側通信装置2からACKを受信したか否かを判断する(S103)。その結果、送信側通信装置1は、受信側通信装置2からACKを受信したと判断した場合(S103でYES)、このACKに基づいて確認シーケンス番号を更新し(S107)、今回送信したシーケンス番号に1を加算して次送信シーケンス番号を更新し(S108)、ウィンドウサイズを設定する(S109)。送信側通信装置1は、ステップS101へ戻り、処理を繰り返す。
一方、送信側通信装置1は、受信側通信装置2からACKを受信していないと判断した場合(S103でNO)、フレームバッファ14に格納されているパケットがウィンドウサイズに相当するデータ量に達するか否か、即ち、送信可能なウィンドウサイズが0になるか否かを判断する(S104)。その結果、送信側通信装置1は、送信可能なウィンドウサイズが0になっていないと判断した場合(S104でNO)、確認シーケンス番号を同じ値に更新し(S107)、今回送信したシーケンス番号に送信したデータサイズを加算して次送信シーケンス番号を更新し(S108)、ウィンドウサイズを設定する(S109)。送信側通信装置1は、ステップS101へ戻り、処理を繰り返す。
一方、送信側通信装置1は、送信可能なウィンドウサイズが0になると判断した場合(S104でYES)、タイマ監視を実行し(S105)、タイムアウトであるか否かを判断する(S106)。その結果、送信側通信装置1は、タイムアウトでないと判断した場合(S106でNO)、ステップS105へ戻り、処理を繰り返す。
一方、送信側通信装置1は、タイムアウトであると判断した場合(S106でYES)、ACKを参照できないため、最後に更新した確認シーケンス番号にインタレース又はプログレッシブ形式に従って分割された一画面の1ライン分に相当するパケット数である4を加算して確認シーケンス番号を更新し(S107)、最後に更新した次送信シーケンス番号と同じ次送信シーケンス番号に更新し(S108)、ウィンドウサイズを設定する(S109)。送信側通信装置1は、ステップS101へ戻り、処理を繰り返す。
尚、上述した実施の形態では、デジタルビデオストリームをストリーム型伝送方式で送信する一例を説明した。しかし、本発明は、これに限定するものでなく、音楽、その他の大容量データをストリーム型伝送方式で送信するようにしてもよい。
以上の形態に関し、更に以下の付記を開示する。
(付記1)
TCPとして規定された通信規約に基づき、送信先からの確認応答に応じて動画データのパケットを送信するデータ送信装置において、
前記送信先からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットを複数格納するバッファと、
該バッファに格納してある各パケットを順次、前記送信先に送信する送信部と、
該送信部で送信した各パケットが前記送信先に到達したことを示す確認応答を前記送信先から受信する受信部と、
該受信部で受信した前記確認応答により確認されたパケットを格納してあるバッファの領域を解放し、該領域に新たなパケットを格納する制御部と、
解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定するバッファ判定部と、
該バッファ判定部で解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記受信部で確認応答を受信するまでの応答時間が予め設定してある単位時間に達するか否かを判定する時間判定部と
を備え、
前記制御部は、前記時間判定部で応答時間が単位時間に達すると判定したとき、前記送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを前記送信部に送信させ、該パケットを格納してあるバッファの領域を解放するようにしてあることを特徴とするデータ送信装置。
(付記2)
前記所定個は、インタレース又はプログレッシブ形式に従って分割された一画面の各ラインに相当するパケット数であることを特徴とする付記1に記載のデータ送信装置。
(付記3)
前記単位時間は、前記所定個のパケットを前記送信部で送信するのに要する時間であることを特徴とする付記1又は2に記載のデータ送信装置。
(付記4)
コンピュータに、TCPとして規定された通信規約に基づき、送信先からの確認応答に応じて動画データのパケットを送信させるコンピュータプログラムにおいて、
前記送信先からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットをバッファに複数格納させるステップと、
バッファに格納してある各パケットを順次、前記送信先に送信させるステップと、
送信した各パケットが到達したことを示す確認応答を前記送信先から受信させるステップと、
受信した確認応答により確認されたパケットを格納してあるバッファの領域を解放し、該領域に新たなパケットを格納させるステップと、
解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定させるステップと、
解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記確認応答を受信するまでの応答時間が予め設定してある単位時間に達する否かを判定させるステップと、
応答時間が単位時間に達すると判定したとき、送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを送信させ、該パケットを格納してあるバッファの領域を解放させるステップと
をコンピュータに実行させることを特徴とするコンピュータプログラム。
(付記5)
TCPとして規定された通信規約に基づき、送信先からの確認応答に応じて動画データのパケットを送信するデータ送信方法において、
前記送信先からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットをバッファに複数格納し、
バッファに格納してある各パケットを順次、前記送信先に送信し、
送信した各パケットが到達したことを示す確認応答を前記送信先から受信したとき、受信した確認応答に基づいて確認されたパケットを格納してあるバッファの領域を解放して該領域に新たなパケットを格納し、
解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定し、
解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記確認応答の受信までの応答時間が予め設定してある単位時間に達するか否かを判定し、
応答時間が単位時間に達すると判定したとき、前記送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを送信させ、該パケットを格納してあるバッファの領域を解放することを特徴とするデータ送信方法。
(付記6)
動画データを送信する第1端末装置と、該第1端末装置に通信網を介して接続できる第2端末装置とを備え、TCPとして規定された通信規約に基づき、第2端末装置は、動画データの受信に応じて確認応答を送信し、第1端末装置は、該確認応答に応じてデータのパケットを送信するデータ送信システムにおいて、
前記第1端末装置は、
前記第2端末装置からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットを複数格納するバッファと、
該バッファに格納してある各パケットを順次送信する送信部と、
該送信部で送信した各パケットが到達したことを示す確認応答を第2端末装置から受信する受信部と、
該受信部で受信した確認応答により確認されたパケットを格納してあるバッファの領域を解放し、該領域に新たなパケットを格納する制御部と、
解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定するバッファ判定部と、
該バッファ判定部で解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記受信部で確認応答を受信するまでの応答時間が予め設定してある単位時間に達するか否かを判定する応答時間判定部と
を備え、
前記第2端末装置は、
パケットを受信したときから次パケットを受信するまでの待ち時間が予め設定してある単位時間に達するか否かを判定する待ち時間判定部と、
前記待ち時間判定部で待ち時間が単位時間に達すると判定したとき、第1端末装置からのパケットの受信を待たずに、所定個のパケットが到達したとみなす確認応答を送信する応答制御部と
を備え、
前記制御部は、前記応答時間判定部で応答時間が単位時間に達すると判定したとき、第2端末装置から確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを前記送信部に送信させ、該パケットを格納してあるバッファの領域を解放するようにしてあることを特徴とするデータ送信システム。
(付記7)
前記所定個は、インタレース又はプログレッシブ形式に従って分割された一画面の各ラインに相当するパケット数であることを特徴とする付記6に記載のデータ送信システム。
(付記8)
前記単位時間は、前記所定個のパケットを前記送信部で送信するのに要する時間であることを特徴とする付記6又は7に記載のデータ送信システム。
本発明に係るデータ送信システムの全体構成を示すブロック図である。 本発明で用いるパケットの内容を説明する概念図である。 実施例1におけるデータ送信処理を説明する概念図である。 実施例2におけるデータ送信処理を説明する概念図である。 実施例2におけるデータ送信処理を説明する概念図である。 実施例3におけるデータ送信処理を説明する概念図である。 実施例3におけるSN制御を説明する図である。 本発明で用いるフレームバッファの格納例を説明する概念図である。 本発明で用いるセグメントデータを説明する概念図である。 送信側通信装置が実行するデータ送信処理の手順を示すフローチャートである。
符号の説明
1 送信側通信装置
10 入力インタフェース
11 情報処理部
12 補助記憶装置
13 TCP制御部
130 計時手段
131 時間判定手段
132 ウィンドウ制御手段
133 セグメント送信制御手段
14 フレームバッファ
15 通信インタフェース
2 受信側通信装置
20 出力インタフェース
21 情報処理部
22 補助記憶装置
23 TCP制御部
230 計時手段
231 時間判定手段
232 ウィンドウ制御手段
233 ACK送信制御手段
24 フレームバッファ
25 通信インタフェース

Claims (5)

  1. TCPとして規定された通信規約に基づき、送信先からの確認応答に応じて動画データのパケットを送信するデータ送信装置において、
    前記送信先からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットを複数格納するバッファと、
    該バッファに格納してある各パケットを順次、前記送信先に送信する送信部と、
    該送信部で送信した各パケットが前記送信先に到達したことを示す確認応答を前記送信先から受信する受信部と、
    該受信部で受信した前記確認応答により確認されたパケットを格納してあるバッファの領域を解放し、該領域に新たなパケットを格納する制御部と、
    解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定するバッファ判定部と、
    該バッファ判定部で解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記受信部で確認応答を受信するまでの応答時間が予め設定してある単位時間に達するか否かを判定する時間判定部と
    を備え、
    前記制御部は、前記時間判定部で応答時間が単位時間に達すると判定したとき、前記送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを前記送信部に送信させ、該パケットを格納してあるバッファの領域を解放するようにしてあることを特徴とするデータ送信装置。
  2. 前記所定個は、インタレース又はプログレッシブ形式に従って分割された一画面の各ラインに相当するパケット数であることを特徴とする請求項1に記載のデータ送信装置。
  3. 前記単位時間は、前記所定個のパケットを前記送信部で送信するのに要する時間であることを特徴とする請求項1又は2に記載のデータ送信装置。
  4. コンピュータに、TCPとして規定された通信規約に基づき、送信先からの確認応答に応じて動画データのパケットを送信させるコンピュータプログラムにおいて、
    前記送信先からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットをバッファに複数格納させるステップと、
    バッファに格納してある各パケットを順次、前記送信先に送信させるステップと、
    送信した各パケットが到達したことを示す確認応答を前記送信先から受信させるステップと、
    受信した確認応答により確認されたパケットを格納してあるバッファの領域を解放し、該領域に新たなパケットを格納させるステップと、
    解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定させるステップと、
    解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記確認応答を受信するまでの応答時間が予め設定してある単位時間に達する否かを判定させるステップと、
    応答時間が単位時間に達すると判定したとき、送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを送信させ、該パケットを格納してあるバッファの領域を解放させるステップと
    をコンピュータに実行させることを特徴とするコンピュータプログラム。
  5. TCPとして規定された通信規約に基づき、送信先からの確認応答に応じて動画データのパケットを送信するデータ送信方法において、
    前記送信先からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットをバッファに複数格納し、
    バッファに格納してある各パケットを順次、前記送信先に送信し、
    送信した各パケットが到達したことを示す確認応答を前記送信先から受信したとき、受信した確認応答に基づいて確認されたパケットを格納してあるバッファの領域を解放して該領域に新たなパケットを格納し、
    解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定し、
    解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記確認応答の受信までの応答時間が予め設定してある単位時間に達するか否かを判定し、
    応答時間が単位時間に達すると判定したとき、前記送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを送信させ、該パケットを格納してあるバッファの領域を解放することを特徴とするデータ送信方法。
JP2008032283A 2008-02-13 2008-02-13 データ送信装置、コンピュータプログラム及びデータ送信方法 Expired - Fee Related JP4808227B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2008032283A JP4808227B2 (ja) 2008-02-13 2008-02-13 データ送信装置、コンピュータプログラム及びデータ送信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008032283A JP4808227B2 (ja) 2008-02-13 2008-02-13 データ送信装置、コンピュータプログラム及びデータ送信方法

Publications (2)

Publication Number Publication Date
JP2009194565A true JP2009194565A (ja) 2009-08-27
JP4808227B2 JP4808227B2 (ja) 2011-11-02

Family

ID=41076202

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008032283A Expired - Fee Related JP4808227B2 (ja) 2008-02-13 2008-02-13 データ送信装置、コンピュータプログラム及びデータ送信方法

Country Status (1)

Country Link
JP (1) JP4808227B2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011151781A (ja) * 2009-12-24 2011-08-04 Canon Inc 通信装置、その処理方法及びプログラム
US20140198671A1 (en) * 2013-01-15 2014-07-17 Fluke Corporation Method and apparatus to dynamically sample nrt using a double-ended queue that allows for seamless transition from full nrt analysis to sampled nrt analysis

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1070523A (ja) * 1996-08-28 1998-03-10 Kokusai Electric Co Ltd パケット伝送方法及び装置
JP2004274237A (ja) * 2003-03-06 2004-09-30 Sony Corp 情報処理装置および方法、記録媒体、並びにプログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1070523A (ja) * 1996-08-28 1998-03-10 Kokusai Electric Co Ltd パケット伝送方法及び装置
JP2004274237A (ja) * 2003-03-06 2004-09-30 Sony Corp 情報処理装置および方法、記録媒体、並びにプログラム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011151781A (ja) * 2009-12-24 2011-08-04 Canon Inc 通信装置、その処理方法及びプログラム
US20140198671A1 (en) * 2013-01-15 2014-07-17 Fluke Corporation Method and apparatus to dynamically sample nrt using a double-ended queue that allows for seamless transition from full nrt analysis to sampled nrt analysis
US8917739B2 (en) * 2013-01-15 2014-12-23 Fluke Corporation Method and apparatus to dynamically sample NRT using a double-ended queue that allows for seamless transition from full NRT analysis to sampled NRT analysis

Also Published As

Publication number Publication date
JP4808227B2 (ja) 2011-11-02

Similar Documents

Publication Publication Date Title
EP3108639B1 (en) Transport accelerator implementing extended transmission control functionality
US7583666B2 (en) Protocol information processing system and method information processing device and method recording medium and program
JP3757857B2 (ja) データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム
KR100967377B1 (ko) 데이터 통신 시스템, 데이터 송신 장치, 데이터 수신 장치, 데이터 통신 방법, 및 컴퓨터 프로그램을 기록한 매체
US7958435B2 (en) Packet transmission apparatus, communication system and program
CN101356814B (zh) 通信处理设备和通信控制方法
JP2010154547A (ja) パケット化データのビットレートの適合化とデータパケットの再送信との間の連携
US20160323062A1 (en) Packet recovery in interactive real-time media protocol
US20150271231A1 (en) Transport accelerator implementing enhanced signaling
JP2016213811A (ja) インタラクティブなリアルタイムメディアの転送プロトコル
CN110830460A (zh) 一种连接建立方法、装置、电子设备及存储介质
US7123618B2 (en) Data transmitting apparatus and data receiving apparatus
JP3871661B2 (ja) マルチメディアコンテンツ受信装置及びマルチメディアコンテンツ受信方法
JP4808227B2 (ja) データ送信装置、コンピュータプログラム及びデータ送信方法
US8078752B2 (en) Method and program for managing the quantity of data transmitted by a transmission device over a telecommunication network
CN1868165A (zh) 传输数据的设备、系统和方法
US7643503B2 (en) System and method for dynamically determining retransmit buffer time
JP2005110013A (ja) 受信装置、受信方法および受信プログラム
US20240165508A1 (en) Method, apparatuses and systems directed to quality of experience improvement in cloud gaming
KR101236231B1 (ko) Rtp 패킷의 송수신 방법 및 시스템
WO2016067561A1 (ja) 通信端末、通信システムおよび通信方法、並びにコンピュータ・プログラムが格納されているコンピュータ読み取り可能な記憶媒体
JP2006067410A (ja) 送信装置および方法、プログラム、並びに送受信システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100917

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110729

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110816

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110816

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140826

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees