(57)【特許請求の範囲】
【請求項１】
ＴＣＰとして規定された通信規約に基づき、送信先からの確認応答に応じて動画データのパケットを送信するデータ送信装置において、
前記送信先からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットを複数格納するバッファと、
該バッファに格納してある各パケットを順次、前記送信先に送信する送信部と、
該送信部で送信した各パケットが前記送信先に到達したことを示す確認応答を前記送信先から受信する受信部と、
該受信部で受信した前記確認応答により確認されたパケットを格納してあるバッファの領域を解放し、該領域に新たなパケットを格納する制御部と、
解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定するバッファ判定部と、
該バッファ判定部で解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記受信部で確認応答を受信するまでの応答時間が予め設定してある単位時間に達するか否かを判定する時間判定部と
を備え、
前記制御部は、前記時間判定部で応答時間が単位時間に達すると判定したとき、前記送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを前記送信部に送信させ、該パケットを格納してあるバッファの領域を解放するようにしてあることを特徴とするデータ送信装置。
【請求項２】
前記所定個は、インタレース又はプログレッシブ形式に従って分割された一画面の各ラインに相当するパケット数であることを特徴とする請求項１に記載のデータ送信装置。
【請求項３】
前記単位時間は、前記所定個のパケットを前記送信部で送信するのに要する時間であることを特徴とする請求項１又は２に記載のデータ送信装置。
【請求項４】
コンピュータに、ＴＣＰとして規定された通信規約に基づき、送信先からの確認応答に応じて動画データのパケットを送信させるコンピュータプログラムにおいて、
前記送信先からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットをバッファに複数格納させるステップと、
バッファに格納してある各パケットを順次、前記送信先に送信させるステップと、
送信した各パケットが到達したことを示す確認応答を前記送信先から受信させるステップと、
受信した確認応答により確認されたパケットを格納してあるバッファの領域を解放し、該領域に新たなパケットを格納させるステップと、
解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定させるステップと、
解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記確認応答を受信するまでの応答時間が予め設定してある単位時間に達する否かを判定させるステップと、
応答時間が単位時間に達すると判定したとき、送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを送信させ、該パケットを格納してあるバッファの領域を解放させるステップと
をコンピュータに実行させることを特徴とするコンピュータプログラム。
【請求項５】
ＴＣＰとして規定された通信規約に基づき、送信先からの確認応答に応じて動画データのパケットを送信するデータ送信方法において、
前記送信先からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットをバッファに複数格納し、
バッファに格納してある各パケットを順次、前記送信先に送信し、
送信した各パケットが到達したことを示す確認応答を前記送信先から受信したとき、受信した確認応答に基づいて確認されたパケットを格納してあるバッファの領域を解放して該領域に新たなパケットを格納し、
解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定し、
解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記確認応答の受信までの応答時間が予め設定してある単位時間に達するか否かを判定し、
応答時間が単位時間に達すると判定したとき、前記送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを送信させ、該パケットを格納してあるバッファの領域を解放することを特徴とするデータ送信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＴＣＰに従ってストリーミングデータ転送を行うデータ送信装置、コンピュータプログラム及びデータ送信方法であって、特に、ネットワークの遅延又は障害などに対するエラー耐性を高めたデータ送信装置、コンピュータプログラム及びデータ送信方法に関する。
【背景技術】
【０００２】
従来、インターネット通信など、様々な通信媒体に介した画像、音声データなどのデータ転送が盛んに行われている。特に、インターネット上のデータ転送において、従来から利用されているダウンロード型伝送方式に加えて、ストリーム型伝送方式によるサービスが増加している。
【０００３】
ダウンロード型伝送方式は、動画ファイル又は音声ファイルなどのマルチメディアデータを転送する場合、データファイルを配信サーバから通信端末装置の記憶部にダウンロードして一度記憶し、記憶したデータファイルを再生するので、受信側端末装置が全てのファイルをダウンロードするまで再生することができず、長時間再生又はリアルタイム再生などには向いていない。
【０００４】
一方、ストリーム型伝送方式は、データファイルを配信サーバから通信端末装置にダウンロードしつつ、ダウンロードしたファイルを再生するので、例えば、動画ファイルの長時間再生又はリアルタイム再生に向いている。
【０００５】
ストリーム型伝送方式において、パーソナルコンピュータ（以下、「ＰＣ」という。）、ＰＤＡ（Personal Digital Assistant）又は携帯電話機などの送信側通信装置は、動画データにＭＰＥＧ圧縮処理を施してＭＰＥＧストリームとし、これをＩＰ（Internet Protocol）パケットとしてフレームバッファに格納する。格納してあるパケットは、配信サーバを介してＴＣＰ／ＩＰ通信で転送される。受信側通信装置は、パケットを受信し、動画データとして一定速度のリアルタイム再生を行う。
【０００６】
しかし、ＴＣＰ／ＩＰ通信は、ネットワーク環境に応じて変動し易い。例えば、ネットワーク環境でデータの輻輳が発生した場合、ＴＣＰ制御によるセグメント送信が停止し、送信側通信装置でリアルタイムデータのフレームバッファがオーバーフローし、受信側通信装置で出力すべきリアルタイムデータのフレームバッファがアンダーフローし、送信できないデータを廃棄する。このように、ＴＣＰ／ＩＰ通信は、受信側通信装置でのリアルタイム再生を不可能とする問題を有している。
【０００７】
そこで、従来、ＵＤＰ（User Datagram Protocol）に基づくＲＴＰ（Real-time Transport Protocol）及びＲＴＣＰ（RTP Control Protocol）を用いて、廃棄されたデータの再送処理を行うよう工夫されたデータ通信装置及びデータ送信システムが提案された（例えば、特許文献１）。
【特許文献１】特開２００３−１６９０４０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、ＵＤＰは、送受信間で送達確認などを一切行わない無手順方式でのデータ転送であり、通信中のパケット紛失又はデータの誤り検出などを行わない。そのため、特許文献１に記載された通信装置にあっては、ＴＣＰによる通信に比べてデータ通信の信頼性が著しく低下するという問題を有している。
【０００９】
本発明はかかる事情に鑑みてなされたものであり、ＴＣＰとして規定された通信規約に基づき、ウィンドウサイズを上限として送信前のパケットをバッファに格納して送信し、送信先からの確認応答に応じてパケットをバッファから解放し、送信先からの確認応答がないためにバッファ内のパケットが解放されずにウィンドウサイズに達したと判定したとき、この判定から確認応答を受信するまでの応答時間を計時し、計時した応答時間が所定時間に達すると判定したとき、送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを送信してバッファから解放するようにしてあることにより、ＴＣＰに従ってデータ通信の調整を行いつつ、ネットワークの遅延、輻輳又は障害などが発生したときには、これを意識することなく、リアルタイムでデータ送信できるデータ送信装置、コンピュータプログラム及びデータ送信方法を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明に係るデータ送信装置は、ＴＣＰとして規定された通信規約に基づき、送信先からの確認応答に応じて動画データのパケットを送信するデータ送信装置において、前記送信先からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットを複数格納するバッファと、該バッファに格納してある各パケットを順次、前記送信先に送信する送信部と、該送信部で送信した各パケットが前記送信先に到達したことを示す確認応答を前記送信先から受信する受信部と、該受信部で受信した前記確認応答により確認されたパケットを格納してあるバッファの領域を解放し、該領域に新たなパケットを格納する制御部と、解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定するバッファ判定部と、該バッファ判定部で解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記受信部で確認応答を受信するまでの応答時間が予め設定してある単位時間に達するか否かを判定する時間判定部とを備え、前記制御部は、前記時間判定部で応答時間が単位時間に達すると判定したとき、前記送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを前記送信部に送信させ、該パケットを格納してあるバッファの領域を解放するようにしてあることを要件とする。
【００１１】
また、本発明に係るデータ送信装置は、前記所定個は、インタレース又はプログレッシブ形式に従って分割された一画面の各ラインに相当するパケット数であることを要件とする。
【００１２】
また、本発明に係るデータ送信装置は、前記単位時間は、前記所定個のパケットを前記送信部で送信するのに要する時間であることを要件とする。
【００１３】
また、本発明に係るコンピュータプログラムは、コンピュータに、ＴＣＰとして規定された通信規約に基づき、送信先からの確認応答に応じて動画データのパケットを送信させるコンピュータプログラムにおいて、前記送信先からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットをバッファに複数格納させるステップと、バッファに格納してある各パケットを順次、前記送信先に送信させるステップと、送信した各パケットが到達したことを示す確認応答を前記送信先から受信させるステップと、受信した確認応答により確認されたパケットを格納してあるバッファの領域を解放し、該領域に新たなパケットを格納させるステップと、解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定させるステップと、解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記確認応答を受信するまでの応答時間が予め設定してある単位時間に達する否かを判定させるステップと、応答時間が単位時間に達すると判定したとき、送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを送信させ、該パケットを格納してあるバッファの領域を解放させるステップとをコンピュータに実行させることを要件とする。
【００１４】
更にまた、本発明に係るデータ送信方法は、ＴＣＰとして規定された通信規約に基づき、送信先からの確認応答に応じて動画データのパケットを送信するデータ送信方法において、前記送信先からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットをバッファに複数格納し、バッファに格納してある各パケットを順次、前記送信先に送信し、送信した各パケットが到達したことを示す確認応答を前記送信先から受信したとき、受信した確認応答に基づいて確認されたパケットを格納してあるバッファの領域を解放して該領域に新たなパケットを格納し、解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定し、解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記確認応答の受信までの応答時間が予め設定してある単位時間に達するか否かを判定し、応答時間が単位時間に達すると判定したとき、前記送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを送信させ、該パケットを格納してあるバッファの領域を解放することを要件とする。
【００１５】
本発明にあっては、ＴＣＰとして規定された通信規約に基づき、バッファに格納してある各パケットを順次送信し、送信先から確認応答を受信した場合、確認応答により確認されたパケットを格納してあるバッファの領域から解放し、該領域に新たなパケットを格納する。一方、送信先から確認応答がなく解放されていないバッファの領域がウィンドウサイズに達した場合、このときから確認応答を受信するまでの応答時間が所定の単位時間に達するか否かを判定し、応答時間が所定の単位時間に達したと判定したとき、送信先から確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを順次送信し、このパケットを格納してあるバッファの領域を解放することにより、ネットワークの遅延、輻輳又は障害などを意識することなく、リアルタイムでデータ送信する。
【発明の効果】
【００１６】
本発明にあっては、ＴＣＰに従って通信する相手との間で通信の調整を行いつつ、ネットワークの遅延、輻輳又は障害などが発生したときには、これを意識することなく、リアルタイムでデータ送信できる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明に係るデータ送信装置、コンピュータプログラム及びデータ送信方法について、実施の形態を示す図面に基づいて説明する。図１は本発明に係るデータ送信システムの全体構成を示すブロック図である。本発明に係るデータ送信システムは、データ送信装置である送信側通信装置１と送信先となる受信側通信装置２とを備える。
【００１８】
送信側通信装置１及び受信側通信装置２は、携帯電話機、通信機能付きのＰＤＡ（Personal Data Assistance）又はＰＣなどが該当する。本実施の形態では、送信側通信装置１及び受信側通信装置２をＰＣとする一例を説明する。
【００１９】
送信側通信装置１は、デジタルビデオストリームを入力するための入力インタフェース１０と、デジタルビデオストリームに各種処理を施す情報処理部１１と、プログラムを記憶する補助記憶装置１２と、ＴＣＰ（Transmission Control Protocol）に従ってパケットを送信するためのＴＣＰ制御部１３と、送信すべきパケットを一時的に格納するフレームバッファ１４と、データ通信を行うための通信インタフェース１５とを備え、各ハードウェアは、バス１６により相互に接続される。
【００２０】
入力インタフェース１０は、例えば、ＩＴＵ−Ｒ．ＢＴ６５６に基づきビデオカメラなどの記録機器（図示せず。以下同じ。）に接続される。入力インタフェース１０は、補助記憶装置１２に記憶してあるプログラムに従い、接続された記録機器からデジタルビデオストリームを取得して情報処理部１１へ出力する。デジタルビデオストリームは、後述するようインタレース又はプログレッシブ形式に従って分割された一画面の１ライン分に相当する動画データを含んでいる。
【００２１】
情報処理部１１は、補助記憶装置１２に記憶してあるプログラムに従い、デジタルビデオストリームから動画データを抽出してパケット化し、このパケットをフレームバッファ１４に書き込む。
【００２２】
補助記憶装置１２は、例えば、磁気記憶方式のハードディスクなどが該当し、本発明に係るデータ送信方法を実行するためのプログラムを記憶する。
【００２３】
ＴＣＰ制御部１３は、補助記憶装置１２に記憶してあるプログラムに従い、受信側通信装置２へのパケットの送信を制御する。ＴＣＰ制御部１３は、時間を計測する計時手段１３０と、計測した時間に関する判定を行う時間判定手段１３１と、ウィンドウサイズに基づいて送信すべきパケットを決定するウィンドウ制御手段１３２と、決定されたパケットを送信するセグメント送信制御手段１３３という機能を有する。
【００２４】
ＴＣＰ制御部１３は、計時手段１３０として機能する場合、ウィンドウ制御手段１３２から出力された後述のバッファオーバーフロー通知に従い、受信側通信装置２から確認応答（以下、ＡＣＫ（Acknowledgement）という。）を受信するまでの応答時間を計測し、計測した時間を時間判定手段１３１へ出力する。
【００２５】
ＴＣＰ制御部１３は、時間判定手段１３１として機能する場合、計時手段１３０から受け付けた応答時間が単位時間に達するか否かを判定し、応答時間が単位時間に達すると判定したときにタイムアウト通知をウィンドウ制御手段１３２へ出力する。単位時間の具体的な値は、後述にて説明する。
【００２６】
ＴＣＰ制御部１３は、ウィンドウ制御手段１３２として機能する場合、フレームバッファ１４の未解放領域がウィンドウサイズに相当するデータ量に達するか否かを判定し、この未解放領域がウィンドウサイズに相当するデータ量に達すると判定したときにバッファオーバーフロー通知を計時手段１３０へ出力する。また、ＴＣＰ制御部１３は、通信インタフェース１５を介して受信したＡＣＫ受信通知に従うか、又は時間判定手段１３１から出力されたタイムアウト通知に従い、確認シーケンス番号及び次送信シーケンス番号を更新してセグメント送信制御手段１３３へ出力する。また、ＴＣＰ制御部１３は、受信側通信装置２から同じシーケンス番号を含むＡＣＫを複数回（例えば３回）受信したとき、このシーケンス番号が示すパケットの再送通知をセグメント送信制御手段１３３へ出力する。
【００２７】
ＴＣＰ制御部１３は、セグメント送信制御手段１３３として機能する場合、ウィンドウ制御手段１３２から出力された確認シーケンス番号及び次送信シーケンス番号に従うか、又は再送通知に従い、フレームバッファ１４からパケットを読み出して受信側通信装置２へ送信する。
【００２８】
フレームバッファ１４は、パケットを送信する前に格納する半導体記憶装置である。フレームバッファ１４の記憶領域は、概念的にインタレース又はプログレッシブ形式に従って分割された一画面のラインをなしている。記憶領域については、後述にて説明する。
【００２９】
通信インタフェース１５は、セグメント送信制御手段１３３の指示に従い、フレームバッファ１４から読み出したパケットを受信側通信装置２へ送信するか、又は受信側通信装置２から送信されたＡＣＫを受信する。
【００３０】
受信側通信装置２は、デジタルビデオストリームを出力するための出力インタフェース２０と、デジタルビデオストリームへの復号などの各種処理を行う情報処理部２１と、プログラムを記憶する補助記憶装置２２と、ＴＣＰに従ってパケットを送信するためのＴＣＰ制御部２３と、パケットを一時的に格納するフレームバッファ２４と、データ通信を行うための通信インタフェース２５とを備え、各ハードウェアは、バス２６により相互に接続される。
【００３１】
出力インタフェース２０は、液晶ディスプレイなどの動画出力装置（図示せず。以下同じ。）に接続される。出力インタフェース２０は、補助記憶装置２２に記憶してあるプログラムに従い、接続された動画出力装置へデジタルビデオストリームを出力する。
【００３２】
情報処理部２１は、補助記憶装置２２に記憶してあるプログラムに従い、パケットを復号して動画データとし、デジタルビデオストリームに変換して出力インタフェース２０へ出力する。
【００３３】
補助記憶装置２３は、例えば、磁気記憶方式のハードディスクなどが該当し、本発明に係るデータ送信方法を実行するためのプログラムを記憶する。
【００３４】
ＴＣＰ制御部２３は、補助記憶装置２２に記憶してあるプログラムに従い、送信側通信装置１からのパケットの受信を制御する。ＴＣＰ制御部２３は、時間を計測する計時手段２３０と、計測した時間に関する判定を行う時間判定手段２３１と、ウィンドウサイズに基づき次回受信すべきパケットを決定するウィンドウ制御手段２３２と、受信したパケットについてのＡＣＫを送信するＡＣＫ送信制御手段２３３という機能を有する。
【００３５】
ＴＣＰ制御部２３は、計時手段２３０として機能する場合、通信インタフェース２５から出力されたパケット受信通知に従うか、又はＡＣＫ送信制御手段１３３から出力されたＡＣＫ送信通知に従い、次のパケットを受信するまでの待ち時間を計測し、計測した待ち時間を時間判定手段２３１へ出力する。
【００３６】
ＴＣＰ制御部２３は、時間判定手段２３１として機能する場合、計時手段２３０から受け付けた待ち時間が単位時間に達するか否かを判定し、待ち時間が単位時間に達すると判定したときにタイムアウト通知をウィンドウ制御手段２３２へ出力する。
【００３７】
ＴＣＰ制御部２３は、ウィンドウ制御手段２３２として機能する場合、通信インタフェース２５から出力されたパケット受信通知に従うか、又は時間判定手段２３１から出力されたタイムアウト通知に従い、次回受信すべきパケットのシーケンス番号（以下、ＡＣＫ番号という。）を更新してＡＣＫ送信制御手段２３３へ出力する。パケット受信通知に従う更新では、受信したパケットに含まれるＡＣＫ番号に１を加算する。また、タイムアウト通知に従う更新では、前回更新したパケットのシーケンス番号に、インタレース又はプログレッシブ形式に従って分割された一画面の１ライン分に相当するパケット数を加算する。
【００３８】
ＴＣＰ制御部２３は、ＡＣＫ送信制御手段２３３として機能する場合、ウィンドウ制御手段２３２から出力されたシーケンス番号を含むＡＣＫを通信インタフェース２５を介して送信側通信装置１へ送信する指示を出力し、ＡＣＫ送信通知を出力する。
【００３９】
フレームバッファ２４は、受信したパケットを格納する半導体記憶装置である。フレームバッファ２４の記憶領域は、概念的にインタレース又はプログレッシブ形式に従って分割された一画面のラインをなしている。記憶領域については、後述にて説明する。
【００４０】
通信インタフェース２５は、ＡＣＫ送信制御手段２３３の指示に従い、ＡＣＫを送信側通信装置１へ送信するか、又は送信側通信装置１からパケットを受信してパケット受信通知を出力する。
【００４１】
上述したハードウェアを有する送信側通信装置１は、ＴＣＰに従い、動画データをパケット化し、このパケットを受信側通信装置２へ送信する。そこで、このパケットの内容について説明する。図２は本発明で用いるパケットの内容を説明する概念図である。
【００４２】
パケットは、送信側通信装置１を示す発信ポート、受信側通信装置２を示す着信ポート、送信したパケットの位置を示すシーケンス番号、次に受信すべきパケットのシーケンス番号を示すＡＣＫ番号、ＴＣＰが運んでいるパケットの始点を示すデータオフセット、拡張用のＲＳＶ、制御用のフラグ、送信先からのＡＣＫを待たずに送信できるデータサイズを示すウィンドウサイズ、データの破損を確認するためのチェックサム、緊急用のデータを格納するための緊急ポインタ、オプションの種別、オプションデータのバイト数、本発明で用いる単位時間となるタイマ設定、復旧を示すオプションフラグ、復旧時のＩＤ認証を行うためのオプションＩＤ、オプションＮＯＰ及びセグメントデータを含む。これらのデータは、送信側通信装置１のＴＣＰ制御部１３及び受信側通信装置２のＴＣＰ制御部２３で夫々記憶されている。
【００４３】
シーケンス番号は、送信側通信装置１において、確認シーケンス番号及び次送信シーケンス番号として管理される。確認シーケンス番号は、受信側通信装置２が正しく受信したパケットの終了位置を示し、次送信シーケンス番号は、次回送信すべきパケットの開始位置を示す。送信側通信装置１は、原則として、受信側通信装置２から受信したＡＣＫに基づいて確認シーケンス番号を決定し、前回更新した次送信シーケンス番号に１を加算して次送信シーケンス番号を決定する。また、送信側通信装置１は、タイムアウトした場合、前回決定した確認シーケンス番号にインタレース又はプログレッシブ形式に従って分割された一画面の１ライン分に相当するパケット数を加算して次送信シーケンス番号を決定する。受信側通信装置２は、受信したパケットに含まれるシーケンス番号を参照することにより、順番通りにパケットを受信できない場合であっても、正しい順番にパケットを並べ替えて動画データに復号することができる。
【００４４】
ＡＣＫ番号は、受信側通信装置２において、次回受信すべきパケットのシーケンス番号として管理されている。受信側通信装置２は、受信したパケットに含まれるＡＣＫ番号を読み出してＡＣＫ番号に１又はインタレース又はプログレッシブ形式に従って分割された一画面の１ライン分に相当するパケット数を加算し、加算したＡＣＫ番号をＡＣＫとして送信側通信装置１へ送信する。送信側通信装置１は、受信したＡＣＫと次送信シーケンス番号とを比較することにより、受信側通信装置２が正しく受信できたか否かを判断できる。ＴＣＰに従ってデータ送信を行う本発明は、通信間による確認をすることにより、ＵＤＰと比較して高い信頼性を確保できる。
【００４５】
緊急ポインタには、インタレース又はプログレッシブ形式に従って分割された一画面の１ライン分に相当するパケット数を格納する。受信側通信装置２は、受信したパケットに含まれる緊急ポインタを読み出し、この緊急ポイント内のパケット数に基づいてタイムアウトした場合のＡＣＫ番号を更新する。
【００４６】
ウィンドウサイズは、ＡＣＫ番号から何バイトのパケットを受信できるかを示すものである。送信側通信装置１は、通信路の開設時に受信側通信装置２からウィンドウサイズを受信し、ウィンドウサイズを上限としてパケットを送信する。ウィンドウサイズは、送信側通信装置１がパケットを送信してフレームバッファ１４から解放したとき、送信したパケット数だけ増大し、送信側通信装置１がパケットを送信できず、新たなパケットが格納され続けたとき、減少する。
【００４７】
従来の装置は、ウィンドウサイズが減少し続けて値が０となる場合、パケット送信ができなくなる。しかし、送信側通信装置１にあっては、パケットの送信が不可能とならないよう、ウィンドウ制御手段１３２でバッファオーバーフロー通知を出力し、計時手段１３０でＡＣＫを受信するまでの応答時間を計測し、計測した応答時間が単位時間に達したとき、強制的にパケットを送信する。本実施の形態では、この計時行為を「タイマ監視」と称して説明する。単位時間は、タイマ値に相当し、通信路の開設時に送信側通信装置１から受信側通信装置２に伝えられる。受信側通信装置２は、受信したタイマ値に基づいてパケット受信の待ち時間を時間判定手段２３１で判定する。
【００４８】
タイマ値は、例えば、インタレース又はプログレッシブ形式に従って分割された一画面の各ライン当たり６４μｓ（マイクロ秒）が好適である。動画データは、後述するよう、少なくとも１ライン分のパケットが消失した場合に復号されない。送信側通信装置１は、インタレース又はプログレッシブ形式に従って分割された一画面の各ラインに相当するパケットを約６３５５５ｎｓ（ナノ秒）でリアルタイムに入力する。従って、本発明で用いるタイマ値は、１ライン当たり約６４μｓに設定される。
【００４９】
送信側通信装置１は、受信側通信装置２からＡＣＫを受信できないときにタイマ監視を開始する。そして、送信側通信装置１は、応答時間が単位時間に達したと判定したとき、ＡＣＫを受信することなく、フレームバッファ１４に格納してあるパケットを受信側通信装置２へ送信する。一方、受信側通信装置２は、送信側通信装置１からパケットを受信できないときにタイマ監視を実行する。そして、受信側通信装置２は、待ち時間が単位時間に達したと判定したとき、パケットを受信することなく、ＡＣＫを送信側通信装置１へ送信する。
【００５０】
その結果、本発明に用いるデータ送信システムにあっては、ＴＣＰに従って通信する相手との間で通信の調整を行いつつ、ネットワークの遅延、輻輳又は障害などが発生したときには、これを意識することなく、リアルタイムでデータ送信できる。
【００５１】
ところで、ネットワークの遅延、輻輳又は障害などは、送信側通信装置１から受信側通信装置２へパケット送信するときか、受信側通信装置２から送信側通信装置１へＡＣＫ送信するときに発生する。そこで、ネットワークの遅延、輻輳又は障害などについて、想定されうる様々な態様を実施例１乃至３として説明する。以下の実施例では、ネットワークの障害が発生したときの一例を説明するが、ネットワークの遅延又は輻輳などが発生したときも同様である。
【００５２】
実施例１．
実施例１では、受信側通信装置２がパケットを受信できない場合の送信側通信装置１及び受信側通信装置２で実行するデータ送信処理を説明する。図３は実施例１におけるデータ送信処理を説明する概念図である。
【００５３】
図３は、データ送信処理の手順を左から右への時系列により示し、送信側通信装置１のデータ送信処理を上段に示し、受信側通信装置２のデータ送信処理を下段に示し、送信対象となるパケットのシーケンス番号をＦｘ（但し、ｘは自然数である。）で示し、確認シーケンス番号を確認ＳＮ、ＡＣＫ番号を次ＳＮと示す。
【００５４】
送信側通信装置１は、パケットＦ１を受信側通信装置２へ送信し、確認シーケンス番号をＦ１とする。受信側通信装置２は、パケットＦ１を受信し、ＴＣＰ制御部２３で管理するＡＣＫ番号を初期値からＦ２に更新し、タイマ監視を開始する。
【００５５】
その後、送信側通信装置１は、パケットＦ２乃至Ｆ７を受信側通信装置２へ順次送信する。しかし、受信側通信装置２は、ネットワークの障害が発生したことにより、パケットＦ２乃至Ｆ７を受信できず、ＡＣＫ番号を更新してＡＣＫを送信することができないため、待ち時間を計測する。その結果、受信側通信装置２は、計測した待ち時間が単位時間に達すると判定したとき、タイムアウトとしてＡＣＫ番号をＦ５に更新する。ここで受信側通信装置２がＦ５に更新したのは、インタレース又はプログレッシブ形式に従って分割された一画面の１ライン分に相当するパケット数が４個となるからである。受信側通信装置２は、ＡＣＫ番号Ｆ５のＡＣＫを送信側通信装置１へ送信し、タイマ監視を再び開始する。
【００５６】
送信側通信装置１は、受信側通信装置２からＡＣＫを受信し、このＡＣＫに基づいて確認シーケンス番号をＦ５に更新する。その結果、送信側通信装置１は、受信側通信装置２がパケットＦ１乃至Ｆ４を正しく受信したとみなし、フレームバッファ１４からパケットＦ１乃至Ｆ４を解放し、新たなパケットを格納する。その後、送信側通信装置１は、パケットＦ８乃至Ｆ１１を受信側通信装置２へ順次送信する。
【００５７】
実施例２．
実施例２では、送信側通信装置１がＡＣＫを受信できない場合の送信側通信装置１及び受信側通信装置２で実行するデータ送信処理を説明する。図４及び図５は実施例２におけるデータ送信処理を説明する概念図である。
【００５８】
図４及び図５は、図３と同様、データ送信処理の手順を左から右への時系列により示し、送信側通信装置１のデータ送信処理を上段に示し、受信側通信装置２のデータ送信処理を下段に示し、送信対象となるパケットのシーケンス番号をＦｘ（但し、ｘは自然数である。）で示し、確認シーケンス番号を確認ＳＮ、ＡＣＫ番号を次ＳＮと示す。
【００５９】
送信側通信装置１は、パケットＦ１を受信側通信装置２へ送信し、確認シーケンス番号をＦ１とする。受信側通信装置２は、パケットＦ１を受信し、ＡＣＫ番号をＦ２に更新してタイマ監視を開始する。
【００６０】
送信側通信装置１は、パケットＦ２乃至Ｆ７を順次送信するが、受信側通信装置２は、ネットワークの障害が発生したことにより、これらのパケットを受信できず、ＡＣＫ番号を更新してＡＣＫを送信することができないため、待ち時間を計測する。その結果、受信側通信装置２は、待ち時間が単位時間に達すると判定したとき、タイムアウトとしてＡＣＫ番号をＦ５に更新し、ＡＣＫ番号Ｆ５のＡＣＫを送信側通信装置１へ送信する。
【００６１】
一方、送信側通信装置１は、ネットワークの障害により、受信側通信装置２からＡＣＫを受信できないので、フレームバッファ１４からパケットを解放できずに新たなパケットを格納し続けてウィンドウサイズを減少させる。送信側通信装置１は、ウィンドウサイズが０になるまで、Ｆ８乃至Ｆ１５を順次送信する。
【００６２】
このとき、受信側通信装置２は、待ち時間が単位時間に達すると判定する都度タイムアウト通知を出力し、タイムアウトとしてＡＣＫ番号をＦ９、Ｆ１３へ順次更新してタイマ監視を開始する。受信側通信装置２は、ＡＣＫ番号をＦ９、Ｆ１３としたＡＣＫを送信側通信装置１へ順次送信する。
【００６３】
送信側通信装置１は、ネットワークの障害により、受信側通信装置２からＡＣＫを受信できないので、フレームバッファ１４からパケットＦ８乃至Ｆ１５を解放できずに新たなパケットを格納し続けて送信可能なウィンドウサイズを更に減少させる。送信側通信装置１は、送信可能なウィンドウサイズが０になったとき、バッファオーバーフローと判定してパケットの送信を停止し、タイマ監視を開始する。
【００６４】
受信側通信装置２は、送信側通信装置１がパケットの送信を停止しているので、パケットを受信できず、待ち時間を計測する。受信側通信装置２は、待ち時間が単位時間に達すると判定したとき、タイムアウトとしてＡＣＫ番号をＦ１７に更新してタイマ監視を再び開始し、ＡＣＫ番号Ｆ１７のＡＣＫを送信側通信装置１へ送信する。
【００６５】
送信側通信装置１は、ネットワークの障害により、受信側通信装置２からＡＣＫを送信できずにタイマ監視を継続する。送信側通信装置１は、応答時間が単位時間に達したと判定したとき、タイムアウトとして確認シーケンス番号をＦ５に更新する。ここで送信側通信装置１が確認シーケンス番号をＦ５に更新したのは、ＡＣＫを参照できないため、最後に更新した確認シーケンス番号であるＦ１にインタレース又はプログレッシブ形式に従って分割された一画面の１ライン分に相当するパケット数を加算したからである。送信側通信装置１は、受信側通信装置２がパケットＦ４まで正しく受信したとみなし、時系列的に古く格納した順序に従い、フレームバッファ１４から所定個のパケットを解放し、解放された領域に新たなパケットを格納する。所定個のパケットは、後述するように、インタレース又はプログレッシブ形式に従って分割された一画面の１ライン分に相当するパケット数である４個とする。送信側通信装置１は、パケットＦ１７乃至Ｆ２０を受信側通信装置２へ順次送信する。
【００６６】
受信側通信装置２は、ネットワークの障害により、送信側通信装置１からパケットＦ１７乃至Ｆ２０を受信できず、ＡＣＫを送信できない。送信側通信装置１は、受信側通信装置２からＡＣＫを受信できないので、フレームバッファ１４からパケットＦ１７乃至Ｆ２０を解放できない。送信側通信装置１は、送信可能なウィンドウサイズが０となったとき、パケットの送信を停止してタイマ監視を開始する。
【００６７】
実施例３．
実施例３では、障害状態にあったネットワークが復旧した場合の送信側通信装置１及び受信側通信装置２で実行するデータ送信処理を説明する。図６は実施例３におけるデータ送信処理を説明する概念図、図７は実施例３におけるＳＮ制御を説明する図である。
【００６８】
図６は、図３と同様、データ送信処理の手順を左から右への時系列により示し、送信側通信装置１のデータ送信処理を上段に示し、受信側通信装置２のデータ送信処理を下段に示し、送信対象となるパケットのシーケンス番号をＦｎｘ（但し、ｘは自然数である。）で示し、確認シーケンス番号を確認ＳＮと、ＡＣＫ番号を次ＳＮと示す。また、実施例３では、ネットワークの障害により、ウィンドウサイズが０の状態にあり、送信側通信装置１がタイマ監視を実行している時点から説明する。
【００６９】
送信側通信装置１は、応答時間が単位時間に達してタイムアウトになったとき、確認シーケンス番号をＦｘ（Ｆｎより前の番号）に更新し、パケットＦｎ１乃至Ｆｎ４を受信側通信装置２へ順次送信する。しかし、送信側通信装置１は、ネットワークの障害により、受信側通信装置２からＡＣＫが返ってこないので、フレームバッファ１４からパケットＦｎ１乃至Ｆｎ４を解放できない。その結果、送信側通信装置１は、ウィンドウサイズが再び０となり、パケットの送信を停止してタイマ監視を開始する。
【００７０】
その後、送信側通信装置１及び受信側通信装置２のデータ送信処理が進み、送信側通信装置１がパケットＦｎ４まで送信し、受信側通信装置２がＡＣＫ番号Ｆｎ１７のＡＣＫを送信するとき、ネットワークが復旧したとする。送信側通信装置１は、このＡＣＫを受信することにより、タイマ監視を停止し、確認シーケンス番号及び次送信シーケンス番号をＦｎ１７に更新する。ここで送信側通信装置１が確認シーケンス番号及び次送信シーケンス番号をＦｎ１７に更新したのは、ＡＣＫ番号であるＦｎ１７が次送信シーケンス番号より大きくウィンドウサイズ範囲外のためである。送信側通信装置１は、受信側通信装置２がシーケンス番号Ｆｎ１７までのパケットを正しく受信したとみなし、フレームバッファ１４からシーケンス番号Ｆｎ４までのパケットを解放する。その結果、ウィンドウサイズは、増大して最大限（ＦＵＬＬ）の状態になる。このとき、受信側通信装置２は、ＡＣＫ番号Ｆｎ１７からウィンドウサイズとなるαまでのパケットを受信可能とする。
【００７１】
その後、送信側通信装置１及び受信側通信装置２は、通常のＴＣＰに従ったデータ送信を行う。
【００７２】
本発明で用いるタイマ値、及びタイムアウト時に時系列的に古く格納した順序に従い解放するパケットの所定個は、インタレース又はプログレッシブ形式に従って分割された一画面の１ライン分に相当するパケット数が好適である。従って、送信側通信装置１のフレームバッファ１４及び受信側通信装置２のフレームバッファ２４は、インタレース又はプログレッシブ形式に従って分割された一画面のラインに従い、データを格納する。図８は本発明で用いるフレームバッファ１４の格納例を説明する概念図、図９は本発明で用いるセグメントデータを説明する概念図である。
【００７３】
デジタルビデオストリームは、デジタルライン上に水平／垂直の有効映像期間終了点の識別子であるＥＡＶ（End of Active Video）コードと、ブランキングと、水平／垂直の有効映像期間開始点の識別子であるＳＡＶ(Start of Active Video)コードとを備え、アクティブライン上にインタレース又はプログレッシブ形式に従って分割された一画面のラインに相当する１４４０バイトの動画データを備える。送信側通信装置１の情報処理部１１は、デジタルビデオストリームから、この１４４０バイトの動画データを抽出する。
【００７４】
情報処理部１１は、この１４４０バイトの動画データを更に８等分して１８０バイトとし（図８参照）、データの位置情報を示す５バイトのヘッダを付した１８５バイトのセグメントデータを生成する（図９参照）。このセグメントデータは、ＴＣＰ／ＩＰでのパケットとなる。情報処理部１１は、５バイトの位置情報に対応するフレームバッファ１４の領域に書き込む（図８参照）。尚、送信側通信装置１のフレームバッファ１４の格納例を説明したが、受信側通信装置２のフレームバッファ２４の格納も同じようになされる。
【００７５】
その結果、送信側通信装置１がウィンドウサイズを強制的に進めて飛躍したシーケンス番号のパケットを順次送信し、フレームバッファ２４への格納が飛躍した場合であっても、フレームバッファ２４の領域には、飛躍前に受信したパケットが格納されているから、受信側通信装置２は、このパケットを利用して動画データを復号することができ、復号した動画データをデジタルビデオストリームとしてリアルタイム再生することができる。但し、再生されたデジタルビデオストリームの画像にあっては、散点的にブロックノイズが生じる。
【００７６】
最後に、送信側通信装置１が実行するデータ送信処理の手順について説明する。図１０は送信側通信装置１が実行するデータ送信処理の手順を示すフローチャートである。
【００７７】
送信側通信装置１は、入力インタフェース１０に接続された記録機器からデジタルビデオストリームを取得すると共に、ＴＣＰ制御部１３で送信要求を受け付けたか否かを判断する（Ｓ１０１）。その結果、送信側通信装置１は、ＴＣＰ制御部１３で送信要求を受け付けていないと判断した場合（Ｓ１０１でＮＯ）、処理を完了する。
【００７８】
一方、送信側通信装置１は、ＴＣＰ制御部１３で送信要求を受け付けたと判断した場合（Ｓ１０１でＹＥＳ）、情報処理部１１でデジタルビデオストリームから動画データを抽出してパケット化し、ＴＣＰ制御部１３でこのパケットを受信側通信装置２へセグメント送信する（Ｓ１０２）。受信側通信装置２は、パケットを正しく受信した場合にＡＣＫを返すので、送信側通信装置１は、受信側通信装置２からＡＣＫを受信したか否かを判断する（Ｓ１０３）。その結果、送信側通信装置１は、受信側通信装置２からＡＣＫを受信したと判断した場合（Ｓ１０３でＹＥＳ）、このＡＣＫに基づいて確認シーケンス番号を更新し（Ｓ１０７）、今回送信したシーケンス番号に１を加算して次送信シーケンス番号を更新し（Ｓ１０８）、ウィンドウサイズを設定する（Ｓ１０９）。送信側通信装置１は、ステップＳ１０１へ戻り、処理を繰り返す。
【００７９】
一方、送信側通信装置１は、受信側通信装置２からＡＣＫを受信していないと判断した場合（Ｓ１０３でＮＯ）、フレームバッファ１４に格納されているパケットがウィンドウサイズに相当するデータ量に達するか否か、即ち、送信可能なウィンドウサイズが０になるか否かを判断する（Ｓ１０４）。その結果、送信側通信装置１は、送信可能なウィンドウサイズが０になっていないと判断した場合（Ｓ１０４でＮＯ）、確認シーケンス番号を同じ値に更新し（Ｓ１０７）、今回送信したシーケンス番号に送信したデータサイズを加算して次送信シーケンス番号を更新し（Ｓ１０８）、ウィンドウサイズを設定する（Ｓ１０９）。送信側通信装置１は、ステップＳ１０１へ戻り、処理を繰り返す。
【００８０】
一方、送信側通信装置１は、送信可能なウィンドウサイズが０になると判断した場合（Ｓ１０４でＹＥＳ）、タイマ監視を実行し（Ｓ１０５）、タイムアウトであるか否かを判断する（Ｓ１０６）。その結果、送信側通信装置１は、タイムアウトでないと判断した場合（Ｓ１０６でＮＯ）、ステップＳ１０５へ戻り、処理を繰り返す。
【００８１】
一方、送信側通信装置１は、タイムアウトであると判断した場合（Ｓ１０６でＹＥＳ）、ＡＣＫを参照できないため、最後に更新した確認シーケンス番号にインタレース又はプログレッシブ形式に従って分割された一画面の１ライン分に相当するパケット数である４を加算して確認シーケンス番号を更新し（Ｓ１０７）、最後に更新した次送信シーケンス番号と同じ次送信シーケンス番号に更新し（Ｓ１０８）、ウィンドウサイズを設定する（Ｓ１０９）。送信側通信装置１は、ステップＳ１０１へ戻り、処理を繰り返す。
【００８２】
尚、上述した実施の形態では、デジタルビデオストリームをストリーム型伝送方式で送信する一例を説明した。しかし、本発明は、これに限定するものでなく、音楽、その他の大容量データをストリーム型伝送方式で送信するようにしてもよい。
【００８３】
以上の形態に関し、更に以下の付記を開示する。
【００８４】
（付記１）
ＴＣＰとして規定された通信規約に基づき、送信先からの確認応答に応じて動画データのパケットを送信するデータ送信装置において、
前記送信先からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットを複数格納するバッファと、
該バッファに格納してある各パケットを順次、前記送信先に送信する送信部と、
該送信部で送信した各パケットが前記送信先に到達したことを示す確認応答を前記送信先から受信する受信部と、
該受信部で受信した前記確認応答により確認されたパケットを格納してあるバッファの領域を解放し、該領域に新たなパケットを格納する制御部と、
解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定するバッファ判定部と、
該バッファ判定部で解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記受信部で確認応答を受信するまでの応答時間が予め設定してある単位時間に達するか否かを判定する時間判定部と
を備え、
前記制御部は、前記時間判定部で応答時間が単位時間に達すると判定したとき、前記送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを前記送信部に送信させ、該パケットを格納してあるバッファの領域を解放するようにしてあることを特徴とするデータ送信装置。
【００８５】
（付記２）
前記所定個は、インタレース又はプログレッシブ形式に従って分割された一画面の各ラインに相当するパケット数であることを特徴とする付記１に記載のデータ送信装置。
【００８６】
（付記３）
前記単位時間は、前記所定個のパケットを前記送信部で送信するのに要する時間であることを特徴とする付記１又は２に記載のデータ送信装置。
【００８７】
（付記４）
コンピュータに、ＴＣＰとして規定された通信規約に基づき、送信先からの確認応答に応じて動画データのパケットを送信させるコンピュータプログラムにおいて、
前記送信先からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットをバッファに複数格納させるステップと、
バッファに格納してある各パケットを順次、前記送信先に送信させるステップと、
送信した各パケットが到達したことを示す確認応答を前記送信先から受信させるステップと、
受信した確認応答により確認されたパケットを格納してあるバッファの領域を解放し、該領域に新たなパケットを格納させるステップと、
解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定させるステップと、
解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記確認応答を受信するまでの応答時間が予め設定してある単位時間に達する否かを判定させるステップと、
応答時間が単位時間に達すると判定したとき、送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを送信させ、該パケットを格納してあるバッファの領域を解放させるステップと
をコンピュータに実行させることを特徴とするコンピュータプログラム。
【００８８】
（付記５）
ＴＣＰとして規定された通信規約に基づき、送信先からの確認応答に応じて動画データのパケットを送信するデータ送信方法において、
前記送信先からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットをバッファに複数格納し、
バッファに格納してある各パケットを順次、前記送信先に送信し、
送信した各パケットが到達したことを示す確認応答を前記送信先から受信したとき、受信した確認応答に基づいて確認されたパケットを格納してあるバッファの領域を解放して該領域に新たなパケットを格納し、
解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定し、
解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記確認応答の受信までの応答時間が予め設定してある単位時間に達するか否かを判定し、
応答時間が単位時間に達すると判定したとき、前記送信先からの確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを送信させ、該パケットを格納してあるバッファの領域を解放することを特徴とするデータ送信方法。
【００８９】
（付記６）
動画データを送信する第１端末装置と、該第１端末装置に通信網を介して接続できる第２端末装置とを備え、ＴＣＰとして規定された通信規約に基づき、第２端末装置は、動画データの受信に応じて確認応答を送信し、第１端末装置は、該確認応答に応じてデータのパケットを送信するデータ送信システムにおいて、
前記第１端末装置は、
前記第２端末装置からの確認応答を待たずに送信できるパケット数であるウィンドウサイズを上限としてパケットを複数格納するバッファと、
該バッファに格納してある各パケットを順次送信する送信部と、
該送信部で送信した各パケットが到達したことを示す確認応答を第２端末装置から受信する受信部と、
該受信部で受信した確認応答により確認されたパケットを格納してあるバッファの領域を解放し、該領域に新たなパケットを格納する制御部と、
解放されていないバッファの領域が前記ウィンドウサイズに達するか否かを判定するバッファ判定部と、
該バッファ判定部で解放されていないバッファの領域が前記ウィンドウサイズに達すると判定したときから前記受信部で確認応答を受信するまでの応答時間が予め設定してある単位時間に達するか否かを判定する応答時間判定部と
を備え、
前記第２端末装置は、
パケットを受信したときから次パケットを受信するまでの待ち時間が予め設定してある単位時間に達するか否かを判定する待ち時間判定部と、
前記待ち時間判定部で待ち時間が単位時間に達すると判定したとき、第１端末装置からのパケットの受信を待たずに、所定個のパケットが到達したとみなす確認応答を送信する応答制御部と
を備え、
前記制御部は、前記応答時間判定部で応答時間が単位時間に達すると判定したとき、第２端末装置から確認応答を待たずに、時系列的に古く格納した順序に従って所定個のパケットを前記送信部に送信させ、該パケットを格納してあるバッファの領域を解放するようにしてあることを特徴とするデータ送信システム。
【００９０】
（付記７）
前記所定個は、インタレース又はプログレッシブ形式に従って分割された一画面の各ラインに相当するパケット数であることを特徴とする付記６に記載のデータ送信システム。
【００９１】
（付記８）
前記単位時間は、前記所定個のパケットを前記送信部で送信するのに要する時間であることを特徴とする付記６又は７に記載のデータ送信システム。
【図面の簡単な説明】
【００９２】
【図１】本発明に係るデータ送信システムの全体構成を示すブロック図である。
【図２】本発明で用いるパケットの内容を説明する概念図である。
【図３】実施例１におけるデータ送信処理を説明する概念図である。
【図４】実施例２におけるデータ送信処理を説明する概念図である。
【図５】実施例２におけるデータ送信処理を説明する概念図である。
【図６】実施例３におけるデータ送信処理を説明する概念図である。
【図７】実施例３におけるＳＮ制御を説明する図である。
【図８】本発明で用いるフレームバッファの格納例を説明する概念図である。
【図９】本発明で用いるセグメントデータを説明する概念図である。
【図１０】送信側通信装置が実行するデータ送信処理の手順を示すフローチャートである。
【符号の説明】
【００９３】
１  送信側通信装置
１０  入力インタフェース
１１  情報処理部
１２  補助記憶装置
１３  ＴＣＰ制御部
１３０  計時手段
１３１  時間判定手段
１３２  ウィンドウ制御手段
１３３  セグメント送信制御手段
１４  フレームバッファ
１５  通信インタフェース
２  受信側通信装置
２０  出力インタフェース
２１  情報処理部
２２  補助記憶装置
２３  ＴＣＰ制御部
２３０  計時手段
２３１  時間判定手段
２３２  ウィンドウ制御手段
２３３  ＡＣＫ送信制御手段
２４  フレームバッファ
２５  通信インタフェース
【図１】
0004808227.tif 000002
【図２】
0004808227.tif 000003
【図３】
0004808227.tif 000004
【図４】
0004808227.tif 000005
【図５】
0004808227.tif 000006
【図６】
0004808227.tif 000007
【図７】
0004808227.tif 000008
【図８】
0004808227.tif 000009
【図９】
0004808227.tif 000010
【図１０】
0004808227.tif 000011