(57)【要約】【課題】  ＵＤＰベース通信の高速性を活かしつつ、データの到達保障も実現しながら、通信パフォーマンスを極力低下させずに迅速に、欠落したデータの再送を行うことが求められている。【解決手段】  送信側の通信装置は、送信対象の複数のデータにシーケンス番号を付して、前記複数のデータを順次送信し、受信側の通信装置からシーケンス番号を含む再送要求を受信すると、当該シーケンス番号に対応するデータを前記受信側の通信装置に送信する。一方、受信側の通信装置は、送信側の通信装置から送信されたデータを受信し、その受信したデータにおいて、欠落したシーケンス番号があるか否かを判定し、欠落したシーケンス番号があると判定すると、所定のタイミングで、当該欠落したシーケンス番号を含む再送要求を送信側の通信装置に送信する。【選択図】  図１２
2014195158.tif 000002
【特許請求の範囲】
【請求項１】
送信側の通信装置から受信側の通信装置にＵＤＰでデータを送信する通信システムであって、
前記送信側の通信装置は、
送信対象の複数のデータにシーケンス番号を付して、前記複数のデータを順次送信する送信手段と、
前記受信側の通信装置から前記シーケンス番号を含む再送要求を受信すると、当該シーケンス番号に対応するデータを前記受信側の通信装置に送信する再送手段とを有し、
前記受信側の通信装置は、
前記送信側の通信装置から送信されたデータを受信する受信手段と、
前記受信手段が受信したデータにおいて、欠落したシーケンス番号があるか否かを判定する判定手段と、
前記判定手段が欠落したシーケンス番号があると判定すると、所定のタイミングで、当該欠落したシーケンス番号を含む前記再送要求を前記送信側の通信装置に送信する再送要求手段と、
を有することを特徴とする通信システム。
【請求項２】
前記再送手段は、前記再送要求に含まれる前記シーケンス番号に対応するデータと、当該データに続く残りのデータを前記受信側の通信装置に送信することを特徴とする請求項１に記載の通信システム。
【請求項３】
前記所定のタイミングは、前記判定手段が欠落したシーケンス番号があると判定したタイミングであることを特徴とする請求項１又は２に記載の通信システム。
【請求項４】
前記所定のタイミングは、前記判定手段が欠落したシーケンス番号があると判定した後、前記受信手段が所定数のデータを受信したタイミングであることを特徴とする請求項１又は２に記載の通信システム。
【請求項５】
前記所定のタイミングは、前記受信手段が前記複数のデータの最後のデータを受信したタイミングであることを特徴とする請求項１に記載の通信システム。
【請求項６】
前記送信側の通信装置によるデータの送信は、前記受信側の通信装置からのデータ取得要求に応じて起動されることを特徴とする請求項１乃至５のいずれか１項に記載の通信システム。
【請求項７】
前記送信側の通信装置は、前記データ取得要求に応答して、当該要求されたデータのサイズを前記受信側の通信装置に送信し、
前記受信側の通信装置は、前記データのサイズと、前記受信側の通信装置の受信性能とに基づいて前記データを前記複数のデータに分割するための分割情報を決定し、当該分割情報を前記送信側の通信装置に送信し、
前記送信側の通信装置は、前記分割情報に従って前記データを前記複数のデータに分割することを特徴とする請求項１乃至６のいずれか１項に記載の通信システム。
【請求項８】
前記データのサイズ及び前記分割情報は、ＴＣＰで送信されることを特徴とする請求項７に記載の通信システム。
【請求項９】
前記再送要求手段は、前記再送要求をＴＣＰで送信することを特徴とする請求項１乃至８のいずれか１項に記載の通信システム。
【請求項１０】
送信側の通信装置からＵＤＰで送信されたデータを受信する通信装置であって、
データの取得を前記送信側の通信装置にＴＣＰで要求するデータ取得要求手段と、
前記データ取得要求手段による前記要求に応答して前記送信側の通信装置から取得した前記データのサイズと、前記通信装置の受信性能とに基づいて前記データを複数のサブデータに分割するための分割情報を決定し、当該分割情報を前記送信側の通信装置にＴＣＰで送信する送信手段と、
前記分割情報に基づいて前記送信側の通信装置で複数のサブデータに分割され、当該サブデータの順番を示すシーケンス番号が付されたサブデータをＵＤＰで受信する受信手段と、
前記受信手段が受信した前記サブデータにおいて、欠落したシーケンス番号があるか否かを判定する判定手段と、
前記判定手段が欠落したシーケンス番号があると判定すると、当該欠落したシーケンス番号を含む再送要求をＴＣＰで前記送信側の通信装置に送信する再送要求手段と、
前記受信手段が前記複数のサブデータの全てを受信すると、ＴＣＰで到達確認を前記送信側の通信装置に送信する到達確認手段と、
を有することを特徴とする通信装置。
【請求項１１】
前記再送要求手段は、前記判定手段が欠落したシーケンス番号があると判定した後、前記受信手段が所定数のサブデータを受信した後で前記再送要求を送信することを特徴とする請求項１０に記載の通信装置。
【請求項１２】
前記再送要求手段は、前記判定手段が欠落したシーケンス番号があると判定した後、前記受信手段が前記複数のサブデータの最後のサブデータを受信した後で前記再送要求を送信することを特徴とする請求項１０に記載の通信装置。
【請求項１３】
送信側の通信装置から受信側の通信装置にＵＤＰでデータを送信する通信システムを制御する制御方法であって、
前記送信側の通信装置は、送信対象の複数のデータにシーケンス番号を付して、前記複数のデータを順次送信し、
前記受信側の通信装置から前記シーケンス番号を含む再送要求を受信すると、当該シーケンス番号に対応するデータを前記受信側の通信装置に送信し、
前記受信側の通信装置は、前記送信側の通信装置から送信されたデータを受信し、
前記受信したデータにおいて、欠落したシーケンス番号があるか否かを判定し、
前記欠落したシーケンス番号があると判定すると、所定のタイミングで、当該欠落したシーケンス番号を含む前記再送要求を前記送信側の通信装置に送信することを特徴とする通信システムの制御方法。
【請求項１４】
送信側の通信装置からＵＤＰで送信されたデータを受信する通信装置を制御する制御方法であって、
データの取得を前記送信側の通信装置にＴＣＰで要求するデータ取得要求工程と、
前記データ取得要求工程による前記要求に応答して前記送信側の通信装置から取得した前記データのサイズと、前記通信装置の受信性能とに基づいて前記データを複数のサブデータに分割するための分割情報を決定し、当該分割情報を前記送信側の通信装置にＴＣＰで送信する送信工程と、
前記分割情報に基づいて前記送信側の通信装置で複数のサブデータに分割され、当該サブデータの順番を示すシーケンス番号が付されたサブデータをＵＤＰで受信する受信工程と、
前記受信工程で受信した前記サブデータにおいて、欠落したシーケンス番号があるか否かを判定する判定工程と、
前記判定工程が欠落したシーケンス番号があると判定すると、当該欠落したシーケンス番号を含む再送要求をＴＣＰで前記送信側の通信装置に送信する再送要求工程と、
前記受信工程で前記複数のサブデータの全てを受信すると、ＴＣＰで到達確認を前記送信側の通信装置に送信する到達確認工程と、
を有することを特徴とする通信装置の制御方法。
【請求項１５】
コンピュータに、請求項１３又は請求項１４に記載の制御方法を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）などの通信プロトコルで通信を行う技術に関するものである。
【背景技術】
【０００２】
原稿をスキャンして得られた画像データ等を複写機からネットワーク上のサーバに送信したり、また或いは、ネットワーク上のサーバに格納された印刷データを複写機が受信して印刷するシステムが存在している。このようなシステムで使用されるサーバは、社内ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）のように複写機が接続されているのと同じネットワーク内に設置されているのが一般的であった。
【０００３】
しかしながら、近年、クラウドコンピューティングシステムに代表される通信インフラの普及及び発展に伴って、サーバが社内ＬＡＮ以外のインターネット上やＶＬＡＮを介した社内の他拠点に存在するケースも増えてきている。また、このような複写機とサーバ間でやり取りされるデータのサイズも増加し続けているため、通信をより高速に行う必要性が増している。
【０００４】
通信高速化の手法の一つとして、従来はＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｏｒｏｌ Ｐｒｏｔｏｃｏｌ）で行っていた通信をＵＤＰで行う手法がある。ＴＣＰでは、送信側は所定のデータを送信した後、送信したデータの到達確認応答が受信側から返信されるのを待つ。受信側では所定のデータを受信すると、その到達確認応答を送信側に返信する。送信側は、その到達確認応答を受信した後、次のデータを送信する。このように到達確認のやり取りを所定タイミングで行うことで、データ到達の信頼性を保証している。
【０００５】
これに対してＵＤＰは、上記のような到達確認応答のやり取りを省略するプロトコルである。送信側は自分の送りたいデータを自分のタイミングで送信し、受信側も到達確認応答を送信側に返さない。それにより、双方向の通信や到達確認応答待ちが発生せず、高速に通信を行うことが可能になる。しかしながら、ＵＤＰを用いた通信には一般的に以下の問題点が存在する。
（１）データの到達保障が無い。
【０００６】
そのため、データの取りこぼしが発生し得る。
（２）帯域制御ができない。
【０００７】
送信側が大量のデータを一気に送ることで、ネットワーク上の帯域を占有し過ぎたり、受信側の受信性能を超えてデータを送りつけてしまう可能性がある。
【０００８】
このため、スキャンデータや印刷データのようにデータの欠落が許されないデータの送信では、単純に通信プロトコルをＴＣＰからＵＤＰに変更するだけでは不十分で、上述した問題点をアプリケーション層の処理で解決する必要がある。
【０００９】
そこで、ＵＤＰベース通信において到達保障性を実現するためのアイデアが複数提案されている（例えば、特許文献１や特許文献２）。特許文献１は、送信側は、データをＵＤＰパケットサイズに分割して送信し、受信側は複数のパケットを受信したらまとめて到達確認応答を返し、送信側は所定時間内に到達確認応答が届かなければパケットを再送する技術を記載している。また特許文献２は、送信側はデータを分割し、各分割データにシーケンス番号を付与して送信し、受信側はデータの欠落を検知すると、その欠落したシーケンス番号を通知することを記載している。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００１−３３９４３４号公報
【特許文献２】特開２０００-１３４２６３号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
しかしながら、特許文献１の技術によると、データの欠落が発生した際に送信側が当該データの再送を行うのは、到達確認応答の受信待ちがタイムアウトした時点である。そのため、送信側では到達確認応答の受信待ち時間が発生するため、データの欠落が発生した時点で速やかに再送を行うことはできない。また、通信相手に応じてタイムアウト時間を適切に設定しなければならない。例えば、距離が非常に離れた相手にデータを送信する場合に、タイムアウト時間を短く設定すると、到達確認応答の受信よりも先にタイムアウト時間に達してしまう可能性が存在する。このような場合は、本来は不要なはずの再送が頻発し、通信パフォーマンスが著しく低下する可能性が考えられる。また或いは逆に、近距離の相手との通信の場合にタイムアウト時間を長く設定すると、再送開始までに空き時間が長く生じてしまい、やはり通信パフォーマンスが低下する可能性がある。
【００１２】
また特許文献２においても、例えば、データの欠落が多発する環境では、受信側からのシーケンス番号の通知による双方向のやり取りが増加し、期待したような通信パフォーマンスの高速化が得られない可能性がある。
【００１３】
従って、ＵＤＰベース通信の高速性を活かしつつ、データの到達保障も実現しながら、ネットワーク上の帯域に負荷をかけ過ぎることなく、かつ、通信パフォーマンスを極力低下させずに迅速に、欠落したデータの再送を行うことが求められる。
【００１４】
本発明の目的は、上記従来技術の問題点を解決することにある。
【００１５】
本発明の特徴は、ＵＤＰによるデータ通信においても、データの到達保障も実現しながら、通信パフォーマンスを極力低下させずに通信を行うことができる技術を提供することにある。
【課題を解決するための手段】
【００１６】
上記目的を達成するために本発明の一態様に係る通信装置は以下のような構成を備える。即ち、
送信側の通信装置から受信側の通信装置にＵＤＰでデータを送信する通信システムであって、
前記送信側の通信装置は、
送信対象の複数のデータにシーケンス番号を付して、前記複数のデータを順次送信する送信手段と、
前記受信側の通信装置から前記シーケンス番号を含む再送要求を受信すると、当該シーケンス番号に対応するデータを前記受信側の通信装置に送信する再送手段とを有し、
前記受信側の通信装置は、
前記送信側の通信装置から送信されたデータを受信する受信手段と、
前記受信手段が受信したデータにおいて、欠落したシーケンス番号があるか否かを判定する判定手段と、
前記判定手段が欠落したシーケンス番号があると判定すると、所定のタイミングで、当該欠落したシーケンス番号を含む前記再送要求を前記送信側の通信装置に送信する再送要求手段と、を有することを特徴とする。
【発明の効果】
【００１７】
本発明によれば、ＵＤＰによるデータ通信においても、データの到達保障も実現しながら、通信パフォーマンスを極力低下させずに通信を行うことができるという効果がある。
【図面の簡単な説明】
【００１８】
【図１】本発明の実施形態１に係る通信装置を含む通信システムの構成を示す図。
【図２】実施形態１に係る通信装置のハードウェア構成を示すブロック図。
【図３】実施形態１に係る通信装置のソフトウェア構成を説明するための機能ブロック図。
【図４】本実施形態１に係る通信装置によるデータ送信処理を説明するフローチャート。
【図５】図４のＳ４０１の送信事前ネゴシエーションの処理を説明するフローチャート。
【図６】実施形態１に係る通信装置１０１がＳ４０３で実行するサブデータ送信処理を説明するフローチャート。
【図７】本実施形態１に係る通信装置によるデータ受信処理を説明するフローチャート。
【図８】実施形態１に係る通信装置のデータ通信制御部がＳ７０１で実行する受信事前ネゴシエーション処理を説明するフローチャート。
【図９】実施形態１に係る通信装置のデータ通信制御部がＳ７０２で実行するサブデータの受信処理を説明するフローチャート。
【図１０】本発明の実施形態２に係る通信装置による再送要求方法（パターンＡ）を示すシーケンス図。
【図１１】本発明の実施形態２に係る通信装置による再送要求方法（パターンＢ）を示すシーケンス図。
【図１２】本発明の実施形態１に係る通信装置による再送要求方法（パターンＣ）を示すシーケンス図。
【図１３】本発明の実施形態２に係る通信装置による再送要求方法（パターンＤ）を示すシーケンス図。
【図１４】実施形態２に係る通信装置のソフトウェア構成を説明するための機能ブロック図。
【図１５】実施形態２に係る再送要求方法パターンテーブルの一例を示す図。
【図１６】実施形態に係る通信装置のデータ通信制御部が実行するデータ分割情報の決定処理を説明するフローチャート。
【図１７】本実施形態に係る通信環境診断結果テーブルの一例を示す図。
【発明を実施するための形態】
【００１９】
以下、添付図面を参照して本発明の実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。
【００２０】
図１は、本発明の実施形態１に係る通信装置を含む通信システムの構成を示す図である。
【００２１】
通信装置１００はＬＡＮ１１０に接続されており、また通信装置１０１はＬＡＮ１３０に接続されている。ＬＡＮ１１０とＬＡＮ１３０はＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）１２０を介して相互に接続されている。従って、通信装置１００と通信装置１０１とは、ＬＡＮ１１０，１３０及びＷＡＮ１２０を介してお互いにデータの送受信を行うことができる。尚、本実施形態では、通信装置１００と通信装置１０１とはそれぞれ別のＬＡＮ上に存在しているが、必ずしも別のＬＡＮ上に存在していなくても良い。即ち、通信装置１００と通信装置１０１とが同一のＬＡＮ上に存在し、ＷＡＮ１２０を介さずに直接通信可能な構成であっても良い。
【００２２】
図２は、実施形態１に係る通信装置１００，１０１のハードウェア構成を示すブロック図である。尚、通信装置１０１のハードウェア構成も図２に示した構成と同じであるため、通信装置１００に関してのみ説明する。
【００２３】
ＣＰＵ２０１を含む制御部２００は、この通信装置１００全体の動作を制御する。ＣＰＵ２０１は、ＨＤＤ２０４からＲＡＭ２０３に展開された制御プログラムに従って本実施形態に係る通信制御などの各種制御を行う。ＲＯＭ２０２は、ブートプログラムや各種設定情報を記憶している。通信装置１００の電源がオンされると、ＣＰＵ２０１はＲＯＭ２０２に記憶されたブートプログラムを実行してＨＤＤ２０４にインストールされているＯＳや各種制御プログラムを読み出し、それを展開してＲＡＭ２０３に記憶する。その後、ＣＰＵ２０１がＲＡＭ２０３に展開されたプログラムを実行することにより、この通信装置１００が起動される。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ２０４は、データや各種プログラム、或いは各種情報テーブルを記憶する。操作部Ｉ／Ｆ２０５は、操作部２０６と制御部２００とのインターフェースを制御する。操作部２０６には、タッチパネル機能を有する表示部やキーボードなどが備えられている。ネットワークＩ／Ｆ２０７は、制御部２００（通信装置１００）をＬＡＮ１１０に接続する。ネットワークＩ／Ｆ２０７は、ＬＡＮ１１０上やＬＡＮ１３０上の外部装置（例えば、通信装置１０１）に情報を送信したり、或いはそれら外部装置から各種情報を受信したりする。
【００２４】
図３は、実施形態１に係る通信装置１００，１０１のソフトウェア構成を説明するための機能ブロック図である。尚、この図３に示す各機能部は、通信装置１００が有しているＣＰＵ２０１が制御プログラムを実行することにより実現される。
【００２５】
通信装置１００は、データ通信制御部３０１、データ通信実行部３０２、ＴＣＰ通信部３０３、ＵＤＰ通信部３０４、データ記憶部３０５を有する。データ通信制御部３０１は、データ通信実行部３０２が、例えば通信装置１０１等の外部装置との間で実行するデータ通信を制御する。データ通信実行部３０２は、例えば通信装置１０１等の外部装置との間でデータのやり取りを行う。ＴＣＰ通信部３０３は、例えば通信装置１０１等の外部装置との間でＴＣＰを用いた通信を行う。データ通信制御部３０１は、ＴＣＰ通信部３０３上で動作するアプリケーションである。ＵＤＰ通信部３０４は、ＵＤＰを用いて、例えば通信装置１０１等の外部装置との間で通信を行う。データ通信実行部３０２は、ＵＤＰ通信部３０４上で動作するアプリケーションである。データ記憶部３０５は、データ通信実行部３０２が外部装置との間で送受信したデータを記憶し、またデータ通信制御部３０１或いはデータ通信実行部３０２からの指示により、記憶しているデータを参照したり、或いは指定されたデータを記憶したりする。
【００２６】
通信環境診断部３０６は、操作部２０６を介して入力されるユーザの指示に従い、ユーザにより指定された外部の通信装置との間の通信環境を診断する。ここで診断する項目は、対象となる通信装置との間のＲＴＴ（往復遅延時間：Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）とパケットロス率である。通信環境診断部３０６は、例えば、対象となる通信装置に対して応答性のある存在確認パケットを所定数送信する。そして、その存在確認パケットの送信から、それらに対する応答パケットの受信までの時間を計測し、その平均値を算出することでＲＴＴを計測する。また、送信した存在確認パケット数と受信した応答パケット数とを比較することで、パケットロス率を求めることができる。
【００２７】
例えば、存在確認パケットはＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）のＥｃｈｏ要求パケットであり、応答パケットはＩＣＭＰのＥｃｈｏ応答パケットである。また或いは、存在確認パケット及び応答パケットはその他のプロトコルを用いた独自作成のアプリケーションであっても良い。
【００２８】
性能情報記憶部３０７は、ＣＰＵ２０１の性能情報３１０や、通信における受信性能情報３１１等を記憶している。ＣＰＵ性能情報３１０は、ＣＰＵ２０１の動作クロックの周波数を数値で保持している。また受信性能情報３１１は、データ通信実行部３０２が受信処理用に確保可能なメモリサイズと、ＵＤＰ通信部３０４がデータ通信実行部３０２用に占有して割り当て可能な受信バッファサイズ等を保持している。更に、物理層であるネットワークＩ／Ｆ２０７が現在動作している通信速度の情報（１０Ｂａｓｅ，１００Ｂａｓｅ等）も保持している。尚、通信装置１０１も同様に、図３に示すソフトウェア構成を備えているものとする。
【００２９】
本実施形態１では、以上のような構成において、通信装置１０１から通信装置１００にデータを転送する例を挙げて説明する。
【００３０】
具体的には、通信装置１０１のデータ記憶部３０５に記憶されているデータを、通信装置１０１から通信装置１００にＵＤＰを用いた通信で送信し、通信装置１００のデータ記憶部３０５に記憶させる場合で説明する。また、その送信は、通信装置１００の操作部２０６からユーザがデータの受信指示を行うことにより開始されるものとする。
【００３１】
図４は、本実施形態１に係る通信装置１０１によるデータ送信処理を説明するフローチャートである。Ｓ４０１〜Ｓ４０４は各処理ステップを示し、通信装置１０１が行うデータ送信処理の流れに対応する。尚、このフローチャートで示される制御手順を実行するためのプログラムは、通信装置１０１のＲＯＭ２０２，ＲＡＭ２０３，ＨＤＤ２０４のいずれかに記憶されており、そのプログラムをＣＰＵ２０１が実行することにより、この制御手順が実行される。
【００３２】
まずＳ４０１で、通信装置１０１のデータ通信制御部３０１は、送信事前ネゴシエーションの処理を実行する。
【００３３】
図５は、図４のＳ４０１の送信事前ネゴシエーションの処理を説明するフローチャートである。Ｓ５０１〜Ｓ５０３は各処理ステップを示し、通信装置１０１のデータ通信制御部３０１が行う送信事前ネゴシエーション処理の流れに対応する。
【００３４】
先ずＳ５０１で、通信装置１０１のデータ通信制御部３０１は、ＴＣＰ通信部３０３を介して外部の通信装置からデータ取得要求の受信を待つ。本実施形態１では、通信装置１００よりデータ取得要求を受け取ったものとする。データ取得要求を受信するとＳ５０２に進み、データ通信制御部３０１はデータ記憶部３０５を参照し、そこに記憶されている要求された、送信対象のデータのサイズを確認して、そのデータサイズをＴＣＰ通信部３０３を介して通信装置１００に送信する。
【００３５】
次にＳ５０３に進み、通信装置１０１のデータ通信制御部３０１は、ＴＣＰ通信部３０３を介して通信装置１００からデータ分割情報を受信するのを待つ。このデータ分割情報とは、例えば、Ｓ５０２で通知したデータのサイズが５Ｍバイトであった場合に、そのデータを、それぞれが１Ｍバイトの５つのサブデータに分割して送信するよう、通信装置１００が通信装置１０１に要求するものである。こうしてデータ分割情報を受信すると、このサブルーチンのフローチャートを終了する。
【００３６】
こうしてＳ４０１で、図５に示したサブルーチンの処理を実行するとＳ４０２に進み、通信装置１０１のデータ通信実行部３０２は、データ記憶部３０５から、その要求されたデータを読み出して取得する。そして図５のＳ５０３で受信したデータ分割情報に従って、そのデータを複数のサブデータに分割する。そしてＳ４０３に進み、サブデータの送信処理を実行し、分割したサブデータの内の一つを通信装置１００に送信する。このサブデータ送信処理の詳細については後述する。そしてＳ４０４で、通信装置１０１のデータ通信実行部３０２が、サブデータを順次送信して、全てのサブデータの送信を完了したか否かを判定し、まだ未送信のサブデータが存在する場合はＳ４０３に戻って前述の処理を実行する。こうして全てのサブデータの送信が完了した場合は、このフローチャートを終了する。
【００３７】
図６は、実施形態１に係る通信装置１０１がＳ４０３で実行するサブデータ送信処理を説明するフローチャートである。Ｓ６０１〜Ｓ６０７は各処理ステップを示し、通信装置１０１が行うサブデータ送信処理の流れに対応する。
【００３８】
通信装置１０１のデータ通信実行部３０２は、先ずＳ６０１で、これから送信するサブデータを、任意サイズのＵＤＰパケットデータに更に分割する。このＵＤＰパケットデータは任意のサイズであるが、例えば、最終的なイーサフレームパケットが通信装置１００との間の通信経路におけるＭＴＵ（Ｍａｘｉｍｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ）に収まるようなサイズにすることが望ましい。
【００３９】
次にＳ６０２に進み、通信装置１０１のデータ通信実行部３０２は、その各ＵＤＰパケットデータの先頭に、そのパケットデータの順番を示すシーケンス番号を付与する。そしてＳ６０３に進み、通信装置１０１のデータ通信実行部３０２は、ＵＤＰ通信部３０４を介して通信装置１００にＵＤＰパケットデータを送信する。そしてＳ６０４に進み、通信装置１０１のデータ通信実行部３０２は、各サブデータに対応するＵＤＰパケットデータを全て送信したかを判定し、未送信のＵＤＰパケットデータが存在する場合はＳ６０２に戻って前述の処理を実行する。
【００４０】
Ｓ６０４で、全てのサブデータの送信を完了した場合はＳ６０５に進み、通信装置１０１のデータ通信制御部３０１は、ＴＣＰ通信部３０３を介して通信装置１００からの応答を受信するのを待つ。Ｓ６０５で通信装置１００からの応答を受信するとＳ６０６に進み、通信装置１０１のデータ通信制御部３０１は、その応答が再送要求パケットかどうかを判定する。ここで、この再送要求パケットには、通信装置１００が再送を要求するＵＤＰパケットデータのシーケンス番号が格納されている。Ｓ６０６で受信したのが再送要求パケットでは無く、通信装置１００が、それらサブデータを全て受け取ったことを示す到達確認パケットであった場合は、このサブルーチンによる処理を終了する。
【００４１】
一方、再送要求パケットを受信したときはＳ６０７に進み、通信装置１０１のデータ通信実行部３０２は、再送要求パケットで指定されたシーケンス番号以降のＵＤＰパケットデータの全てを、ＵＤＰ通信部３０４を介して通信装置１００に再送する。そして再度、Ｓ６０５に戻って通信装置１００からの応答を待つ。
【００４２】
次に、本実施形態１に係る通信装置１００によるデータ受信処理について説明する。
【００４３】
図７は、本実施形態１に係る通信装置１００によるデータ受信処理を説明するフローチャートである。Ｓ７０１〜Ｓ７０４は各処理ステップを示し、通信装置１００が行うデータ受信処理の流れに対応する。尚、このフローチャートで示される制御手順を実行するためのプログラムは、通信装置１００のＲＯＭ２０２，ＲＡＭ２０３，ＨＤＤ２０４のいずれかに記憶されており、そのプログラムをＣＰＵ２０１が実行することにより、この制御手順が実行される。
【００４４】
まずＳ７０１で、通信装置１００のデータ通信制御部３０１は、受信事前ネゴシエーションの処理を実行する。この受信事前ネゴシエーションサブルーチンの詳細については後述する。次にＳ７０２に進み、通信装置１００のデータ通信実行部３０２は、サブデータの受信処理を実行する。このサブデータの受信処理の詳細についても後述する。次にＳ７０３に進み、通信装置１００のデータ通信実行部３０２は、サブデータを全て受信したか否かを判定し、まだサブデータを全て受信していない場合はＳ７０２に戻って次のサブデータの受信処理を行う。一方、Ｓ７０３で、サブデータの受信を完了したと判定した場合はＳ７０４に進み、通信装置１００のデータ通信実行部３０２は、受信した全てのサブデータを結合したデータを、通信装置１００のデータ記憶部３０５に保存して、この処理を終了する。
【００４５】
図８は、実施形態１に係る通信装置１００のデータ通信制御部３０１がＳ７０１で実行する受信事前ネゴシエーション処理を説明するフローチャートである。Ｓ８０１〜Ｓ８０４は各処理ステップを示し、通信装置１００のデータ通信制御部３０１が行う受信事前ネゴシエーション処理の流れに対応する。尚、このフローチャートで示す処理は、通信装置１０１のデータ通信制御部３０１が行う、図５に示した送信事前ネゴシエーション処理と対になるものである。
【００４６】
先ずＳ８０１で、通信装置１００のデータ通信制御部３０１は、操作部２０６からユーザがデータ取得要求を入力するを待つ。ここでデータ取得要求が入力されたことを検知するとＳ８０２に進む。Ｓ８０２で通信装置１００のデータ通信制御部３０１は、そのユーザによって指示された外部の通信装置（本実施形態１では通信装置１０１）に対して、ユーザによって指示されたデータの取得要求を、通信装置１００のＴＣＰ通信部３０３を介して送信する。次にＳ８０３に進み、通信装置１００のデータ通信制御部３０１は、ＴＣＰ通信部３０３を介して通信装置１０１から、そのデータのサイズ情報を受信するのを待つ。Ｓ８０３で、データのサイズ情報を受信するとＳ８０４に進み、通信装置１００のデータ通信制御部３０１は、そのサイズ情報を基にどのようなサブデータに分割して通信装置１０１からデータ送信してもらうかを判定する。そして、通信装置１００のデータ通信制御部３０１は、その判定結果であるデータ分割情報を、ＴＣＰ通信部３０３を介して通信装置１０１に送信する。以上の処理を実行した後、このサブルーチンの処理を終了する。
【００４７】
尚、ここで通信装置１００は、データ分割情報において適切な分割サイズを通信装置１０１に通知しなければならない。ここで分割サイズとして大き過ぎる値を通知してしまうと、通信装置１００でサブデータを受信する際に、取りこぼしが多発する可能性が生じる。一方、分割サイズとして小さすぎる値を通知してしまうと、ＵＤＰ通信を用いることによる通信の高速化が十分に得られなくなることが予想される。従って、取りこぼしの多発を防ぎ、かつ、通信の高速化を実現可能な最適な分割サイズを判定して通信装置１０１に通知する必要がある。しかしながら、最適な分割サイズは、通信装置１００のＣＰＵ性能や受信性能に依存しており、機器ごとに異なるものである。更には、通信環境の影響も受けるため、個々の機器においても常に最適な値が存在する訳ではない。そこで通信装置１００は、上述の各種要因を加味した上で分割サイズを決定する必要がある。この分割サイズを決定する処理は、後述する。
【００４８】
図９は、実施形態１に係る通信装置１００のデータ通信制御部３０１がＳ７０２で実行するサブデータの受信処理を説明するフローチャートである。尚、このフローチャートは、通信装置１０１が行う、図６に示したサブデータの送信処理と対になるものである。
【００４９】
まずＳ９０１で、通信装置１００のデータ通信実行部３０２は、ＵＤＰ通信部３０４を介して通信装置１０１からＵＤＰパケットデータを受信するのを待つ。ＵＤＰパケットデータを受信するとＳ９０２に進み、通信装置１００のデータ通信実行部３０２は、シーケンス番号を取り除いたデータ部分をシーケンス番号の昇順に並べて、元のサブデータに戻す。次にＳ９０３に進み、通信装置１００のデータ通信実行部３０２は、その受信したサブデータに欠落が生じしていないか（受信したＵＤＰパケットデータのシーケンス番号が不連続となっていないか）を判定する。ここで欠落が生じていると判定するとＳ９０４に進み、通信装置１００のデータ通信制御部３０１は、欠落したシーケンス番号を格納した再送要求パケットを、ＴＣＰ通信部３０３を介して通信装置１０１に送信する。そしてＳ９０１に戻り、次のＵＤＰパケットデータの受信を待ち受ける。
【００５０】
一方、Ｓ９０３で、サブデータに欠落が発生していないと判定した場合はＳ９０５に進み、通信装置１００のデータ通信実行部３０２は、サブデータを最後まで受信したか、即ち、全てのサブデータの受信を完了したかを判定する。サブデータの受信を完了していない場合はＳ９０１に戻り、次のＵＤＰパケットデータの受信を待ち受ける。一方、Ｓ９０５でサブデータの受信を完了したと判定した場合はＳ９０６に進み、通信装置１００のデータ通信制御部３０１は、サブデータを全て受け取ったことを示す到達確認パケットを、ＴＣＰ通信部３０３を介して通信装置１０１に送信する。以上の処理フローを実行した後、このサブルーチンの処理を終了する。
【００５１】
次に図１６及び図１７を参照して、上述した分割サイズを決定する処理を説明する。
【００５２】
図１６は、実施形態に係る通信装置１００のデータ通信制御部３０１が実行するデータ分割情報の決定処理を説明するフローチャートである。Ｓ１６０１〜Ｓ１６０５は各処理ステップを示し、通信装置１００のデータ通信制御部３０１が行うデータ分割情報の決定処理の流れに対応する。尚、各ステップに対応する制御手順を実行するためのプログラムは、通信装置１００のＲＯＭ２０２、ＲＡＭ２０３、ＨＤＤ２０４のいずれかに記憶されており、ＣＰＵ２０１がそのプログラムを実行することにより、この処理が達成される。
【００５３】
先ずＳ１６０１で、通信装置１００のデータ通信制御部３０１は、性能情報記憶部３０７からＣＰＵ性能情報３１０及び受信性能情報３１１を取得する。次にＳ１６０２に進み、通信装置１００のデータ通信制御部３０１は、その取得したＣＰＵ性能情報３１０及び受信性能情報３１１から、図８のＳ８０４で通信装置１０１に送信する分割サイズのデフォルト値（ＤＳ１）を決定する。
【００５４】
具体的には、まず、ＣＰＵ性能情報３１０から、通信装置１００のデータ通信実行部３０２の理論上の受信パフォーマンス（Ｐ１）を算出する。例えばＣＰＵ性能が示す周波数をＣヘルツ、通信装置１００のデータ通信実行部３０２が１パケットの受信処理を行う際の処理ステップ数をＫとする。この場合、通信装置１００のデータ通信実行部３０２が１パケットの受信処理に要する処理時間（Ｔ）は、Ｔ＝（Ｋ×１０００）／Ｃ［ミリ秒］で求められる。従って、ＵＤＰ通信処理が１秒間に受信可能なＵＤＰパケット数の理論値（Ｎ）はＮ＝１０００／Ｔとなり、理論上の通信パフォーマンスＰ１は、Ｎ×１４７８（ＢＰＳ）となる。尚、ここでは、ＵＤＰパケットの１パケットのデータグラムを１４７８バイトとして計算している。
【００５５】
こうして算出した理論上の通信パフォーマンスＰ１の値を、受信性能情報３１１に保持されたネットワークＩ／Ｆ２０７の通信速度情報の値と比較する。ここでＰ１の方が大きい場合、通信装置１００のデータ通信実行部３０２は物理層（ネットワークＩ／Ｆ２０７）の通信速度よりも高速に受信できる性能を備えていることになる。そのため、受信性能情報３１１に保持された通信装置１００のデータ通信実行部３０２の受信メモリサイズの値を、分割サイズのデフォルト値（ＤＳ１）として採用する。一方、ネットワークＩ／Ｆ２０７の通信速度の方が大きい場合、通信装置１００のデータ通信実行部３０２の受信処理が追い付かず、受信メモリサイズの容量を超えて、パケットの取りこぼしが多発してしまう可能性がある。そのため、分割サイズのデフォルト値（ＤＳ１）には、受信性能情報３１１に保持された通信装置１００のＵＤＰ通信部３０４の受信バッファサイズを採用する。
【００５６】
こうしてＳ１６０２で、分割サイズのデフォルト値ＤＳ１を決定するとＳ１６０３に進み、通信装置１００のデータ通信制御部３０１は、通信装置１０１からの受信要求が来るのを待つ。Ｓ１６０３で受信要求を受信するとＳ１６０４に進み、通信装置１００のデータ通信制御部３０１は、予め保持されていた通信装置１０１との間の通信環境診断結果を取得する。
【００５７】
図１７は、本実施形態に係る通信環境診断結果テーブルの一例を示す図である。
【００５８】
この通信環境診断結果テーブルは、通信装置１００のＲＯＭ２０２，ＲＡＭ２０３，ＨＤＤ２０４のいずれかの記憶手段に記憶されている。
【００５９】
この通信環境診断結果テーブルは、診断相手となる通信装置情報１７０１、ＲＴＴ計測結果１７０２、パケットロス率１７０３の列を含んでいる。ここで、通信装置１０１に関して、ＲＴＴ１７０２には「１０ｍｓ」が、パケットロス率１７０２には「０．１％」が格納されている。
【００６０】
この場合Ｓ１６０４では、通信装置１０１に関する係る通信環境診断結果を取得することとなる。そしてＳ１６０５に進み、通信装置１００のデータ通信制御部３０１は、取得した通信環境診断結果を基に、実際に通信装置１０１に通知する分割サイズＤＳ２を決定する。
【００６１】
ＤＳ２の決定に際しては、まず、通信環境診断結果からパケットロス率を取得し、理論上パケットロスが起こり得るデータサイズＤを算出する。この値は（１００／パケットロス率）×１４７２（ＵＤＰにおける１パケットあたりの最大ペイロード）で算出される。例えばパケットロス率の値が「０．１％」の場合は、理論上、１０００パケットに一度パケットのロスが発生し得ることとなり、Ｄの値は約１．４Ｍバイトとなる。
【００６２】
本実施形態１に係るＵＤＰ通信処理において、パケットロスの発生は極力低減させることが高速な通信を実現する上でも極めて重要である。そこで、デフォルト値ＤＳ１とＤの値を比較し、Ｄの方が小さい場合は、Ｄの値を実際に通信装置１０１に通知する分割サイズＤＳ２として採用する。一方、デフォルト値ＤＳ１の方が小さい場合は、デフォルト値ＤＳ１の値をそのまま実際に通信装置１０１に通知する分割サイズＤＳ２として採用する。また、もしもパケットロス率の値が「０％」であれば、デフォルト値ＤＳ１の値がそのまま実際に通信装置１０１に通知する分割サイズＤＳ２として採用されることとなる。
【００６３】
更には、図１７の通通信環境診断結果テーブルからＲＴＴの値を取得する。このＲＴＴの値が大きい（＝距離が遠い）場合は、分割サイズＤＳ２の値に更に任意の調整率を掛け合わせた値を通信装置１０１に通知する。これは、距離が遠い場合にはパケットロスが発生するリスクが高まるためである。これは、仮に通信環境診断時にあまりパケットロスが発生しなかったとしても、今回のＵＤＰ通信時には、パケットロスが発生する可能性があるためである。
【００６４】
以上説明した処理を行うことにより、通信装置１００では最適な分割データサイズを通信装置１０１に通知することが可能となる。それにより、取りこぼしの多発を防ぎ、かつ、通信の高速化を実現することができる。
【００６５】
以上説明したように本実施形態１によれば、送信側で、送信データを所定サイズのサブデータに分割し、そのサブデータ単位で送信することにより、ネットワーク上の帯域を過剰に占有し過ぎてしまう事態を回避することができる。
【００６６】
また、サブデータへの分割方法は、受信側の通信装置が決定するため、受信側に比べて送信側が高性能な通信装置である場合などにも、受信側が受信しきれないようなデータを一気に送信側が送りつけてしまう事態を回避できる。
【００６７】
更には、データ欠落の発生を検知した時点で送信側が速やかに再送処理を開始できるという効果もある。
【００６８】
そして、送信側が再送を要求されると、その要求されたシーケンス番号以降のサブデータを全て再送することで、例えば、データの欠落が多発する環境においても、受信側が大量の再送要求を発行する必要がなくなる。それにより、通信パフォーマンスを極力低下させずに迅速に再送できるため、ＵＤＰによる通信の高速性を活かしつつ、データの到達保障も実現することが可能となる。
【００６９】
［実施形態２］
次に、本発明に係る実施形態２について説明する。尚、実施形態２に係る通信システムの構成、及び通信装置１００，１０１の構成などは前述の実施形態１と同様であるため、その説明を省略する。
【００７０】
データを受信する通信装置１００において、再送要求パケットを送信するタイミングやその要求内容は、必ずしも前述の実施形態１に示した内容に限定されるものではなく、複数設けても良い。更には、通信装置１０１との間の通信環境を事前に診断しておき、その診断内容に応じて、複数方法の中から最適と思われるものを通信装置１００が自動的に選択しても良い。
【００７１】
図１０は、本発明の実施形態２に係る通信装置１００による再送要求方法（パターンＡ）を示すシーケンス図である。
【００７２】
このパターンＡでは、通信装置１００は受信したＵＤＰパケットデータのシーケンス番号に欠落を検知すると、その時点で直ちに当該シーケンス番号のみの再送要求パケットを通信装置１０１に送信する。
【００７３】
通信装置１０１は、サブデータを、１〜Ｎまでのシーケンス番号を付与したＵＤＰパケットデータとして通信装置１００に送信する。１００１はシーケンス番号が「１」のＵＤＰパケットデータである。１００２はシーケンス番号が「２」のＵＤＰパケットデータである。また１００３はシーケンス番号が「３」、１００４はシーケンス番号が「４」のＵＤＰパケットデータである。同様にパケットは続き、シーケンス番号が「Ｎ」のＵＤＰパケットデータ１００５まで続けて送信される。ここで、本実施形態２では、シーケンス番号が「３」のＵＤＰパケットデータ１００３が、途中の通信経路で欠落し、通信装置１００に到達しなかったものとする。
【００７４】
このとき通信装置１００は、シーケンス番号が「２」のＵＤＰパケットデータ１００２の次にシーケンス番号が「４」のＵＤＰパケットデータ１００４を受信することになり、シーケンス番号が「３」のＵＤＰパケットデータを受信できない。そこで通信装置１００は、１００６で、シーケンス番号が「３」のＵＤＰパケットデータが途中で欠落したことを検知する。そして直ちに、通信装置１０１に対してシーケンス番号が「３」のＵＤＰパケットデータの再送要求パケット１００７を送信する。
【００７５】
この再送要求パケット１００７を受信した通信装置１０１は、その要求内容に従って、シーケンス番号が「３」のＵＤＰパケットデータ１００８を再送する。
【００７６】
これにより通信装置１００は、そのシーケンス番号が「３」のＵＤＰパケットデータ１００８を受信すると、所望のサブデータの受信を全て完了したことになる（１００９）。こうして、通信装置１０１に到達確認パケット１０１０を送信する。
【００７７】
以上、パターンＡの再送要求方法は、シンプルな方法であるため、通信装置１００と通信装置１０１との間の距離が短く、パケットロスがあまり発生しない環境で、無駄なく高速な再送が行えるため有益である。
【００７８】
図１１は、本発明の実施形態２に係る通信装置１００による再送要求方法（パターンＢ）を示すシーケンス図である。
【００７９】
一般的な通信において、必ずしも送信側が送出した順序でそのまま受信側にパケットデータが届くという保証は無く、途中の通信経路でパケットの順序が入れ替わることは起こり得る。そのため、このパターンＢでは、通信装置１００は、受信したＵＤＰパケットデータのシーケンス番号に欠落を検知しても、直ちには再送要求を行わない。即ち、シーケンス番号の欠落を検知した後、更に所定数のＵＤＰパケットデータの受信を待ち受け、それらパケットデータ中にも欠落したシーケンス番号のパケットデータが存在しないと判定する。その場合には、その時点で、そのシーケンス番号のみの再送要求パケットを通信装置１０１に送信する。
【００８０】
通信装置１０１は、サブデータを、１〜Ｎまでのシーケンス番号を付与したＵＤＰパケットデータとして通信装置１００に送信する。１１０１はシーケンス番号が「１」のＵＤＰパケットデータである。１１０２はシーケンス番号が「２」のＵＤＰパケットデータである。また１１０３は、シーケンス番号「３」、１１０４はシーケンス番号が「４」、１１０５はシーケンス番号が「５」、１１０６はシーケンス番号が「６」のＵＤＰパケットデータである。同様にパケットは続き、１１０７のシーケンス番号が「Ｎ」のＵＤＰパケットデータまで続けて送信される。ここで、本実施形態２では、シーケンス番号「３」のＵＤＰパケットデータ１１０３は途中の通信経路で欠落し、通信装置１００には到達しなかったものとする。
【００８１】
このとき通信装置１００は、シーケンス番号が「２」のＵＤＰパケットデータ１１０２の次にシーケンス番号が「４」のＵＤＰパケットデータ１１０４を受信することとなり、シーケンス番号が「３」のＵＤＰパケットデータ１１０３を受信しない。そこで通信装置１００は、１１０８で、シーケンス番号「３」が途中で欠落したことを検知する。この場合は、図１０に示すパターンＡの場合とは異なり、この時点ではまだ再送要求パケットを送信しない。そしてその後、シーケンス番号が「５」のＵＤＰパケットデータ１１０５、シーケンス番号が「６」のＵＤＰパケットデータ１１０６を受信するが、その時点でもまだシーケンス番号「３」のＵＤＰパケットデータを受信しないこととなる。そのため、１１０９で、シーケンス番号が「３」のＵＤＰパケットデータの受信を待ち続けるのをあきらめ、通信装置１０１に対してシーケンス番号が「３」のＵＤＰパケットデータの再送要求パケット１１１０を送信する。この実施形態２では、１１０８で、シーケンス番号「３」のＵＤＰパケットデータの欠落を検知してから更に２つのパケットデータの受信を待っているが、この待つパケットの数は任意で良く、必ずしも２つのパケットに限定するものではない。
【００８２】
この再送要求パケット１１１０を受信した通信装置１０１は、その要求内容に従ってシーケンス番号が「３」のＵＤＰパケットデータ１１１１を再送する。これにより通信装置１００は、シーケンス番号が「３」のＵＤＰパケットデータ１１１１を受信すると、１１１２で、所望のサブデータの全てを受信したことになるため、通信装置１０１に到達確認パケット１１１３を送信する。
【００８３】
このパターンＢの再送要求方法は、通信装置１００と通信装置１０１間の距離が遠いが、パケットロスがあまり発生しない環境で、無駄な再送要求を行ってしまう事態を回避できるため、有益である。
【００８４】
図１２は、本発明の実施形態２に係る通信装置１００による再送要求方法（パターンＣ）を示すシーケンス図である。
【００８５】
このパターンＣでは、通信装置１００は、受信したＵＤＰパケットデータのシーケンス番号の欠落を検知すると、その時点で直ちに当該シーケンス番号以降の全てのサブデータの再送要求パケットを通信装置１０１に送信する。即ち、図１２は、実施形態１における図６のサブデータ送信サブルーチン及び図９のサブデータ受信サブルーチンそのものの処理フローを示すシーケンス図である。図１２において、１２０１〜１２０６までのパケット及び処理は、図１０の１００１から１２０６までとそれぞれ全く同一である。
【００８６】
図１０との差異としては、通信装置１００は、１２０６でシーケンス番号「３」のパケットデータの欠落を感知した後、通信装置１０１に対してシーケンス番号が「３」以降のＵＤＰパケットデータ全ての再送要求パケット１２０７を送信する。
【００８７】
この再送要求パケット１２０７を受信した通信装置１０１は、その要求内容に従ってシーケンス番号が「３」以降のＵＤＰパケットデータを再送する。この例では、シーケンス番号が「３」のＵＤＰパケットデータ１２０８と、残りのＵＤＰパケットデータ１２０９〜１２１０までを再送することになる。ここで、１２０９はシーケンス番号が「４」のＵＤＰパケットデータで、同様に続くパケットデータも再送され、シーケンス番号が「Ｎ」のＵＤＰパケットデータ１２１０まで再送されることとなる。
【００８８】
その後、通信装置１００は、１２１１で、所望のサブデータを全て受信すると、通信装置１０１に到達確認パケット１２１２を送信する。
【００８９】
このパターンＣの再送要求方法は、通信装置１００と通信装置１０１間の距離に拘らず、パケットロスの発生率が高い環境で、通信装置１００からの再送要求パケットの回数を最小限にして再送処理が行えるため有益である。
【００９０】
図１３は、本発明の実施形態２に係る通信装置１００による再送要求方法（パターンＤ）を示すシーケンス図である。
【００９１】
このパターンＤでは、通信装置１００は、最後のＵＤＰパケットデータを受信するまで再送要求の送信を見合わせる。最後のＵＤＰパケットデータを受信した時点で、欠落したシーケンス番号を確認し、それら欠落したシーケンス番号のパケットデータのみの再送要求パケットを通信装置１０１に送信する。
【００９２】
ここでも、通信装置１０１は、サブデータを、シーケンス番号「１」〜「Ｎ」までを付与したＵＤＰパケットデータとして通信装置１００に送信する。図１３において、１３０１〜１３０７で示すパケットデータは、図１１の１１０１〜１１０７のパケットデータと全く同一である。但し、この例では、ＵＤＰパケットデータ１３０３と１３０６とが途中の通信経路で欠落し、通信装置１００には到達しなかったものとする。
【００９３】
このとき通信装置１００は、１３０８で、シーケンス番号が「Ｎ」のＵＤＰパケットデータ１３０７まで受信した時点で、シーケンス番号の欠落が生じているか否かを判定する。この例では、シーケンス番号「３」と「６」の欠落を検知するので、通信装置１０１に対して、シーケンス番号が「３」と「６」のＵＤＰパケットデータの再送要求パケット１３０９を送信する。
【００９４】
この再送要求パケット１３０９を受信した通信装置１０１は、その要求内容に従って、シーケンス番号が「３」のＵＤＰパケットデータ１３１０とシーケンス番号が「６」のＵＤＰパケットデータ１３１１とを再送する。
【００９５】
これにより通信装置１００は、１３１２で、これらＵＤＰパケットデータ１３１０及び１３１１を受信すると、所望のサブデータを全て受信したことになるので、通信装置１０１に対して、到達確認パケット１３１３を送信する。
【００９６】
このパターンＤの再送要求方法は、通信装置１００と通信装置１０１間の距離は近いが、パケットロスがある程度の頻度で発生するような環境で有益である。
【００９７】
図１４は、実施形態２に係る通信装置１００のソフトウェア構成を説明するための機能ブロック図である。図１４に示す各機能部は、通信装置１００が有しているＣＰＵ２０１が制御プログラムを実行することにより実現される。
【００９８】
通信装置１００は、データ通信制御部１４０１、データ通信実行部１４０２、ＴＣＰ通信部１４０３、ＵＤＰ通信部１４０４、データ記憶部１４０５、通信環境診断部１４０６を有する。
【００９９】
通信環境診断部１４０６は、操作部２０６を使用して入力されるユーザの指示に従い、そのユーザにより指定された外部の通信装置との間の通信環境を診断する。ここで診断する項目は、対象となる通信装置との間のＲＴＴ（往復遅延時間：Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）とパケットロス率である。例えば、対象となる通信装置に対して応答性のある存在確認パケットを所定数送信する。これら存在確認パケットのそれぞれの送信から、それらに対する各応答パケットの受信までの時間を計測し、その平均値を算出することで、ＲＴＴを測ることができる。また、送信した存在確認パケットの数と、受信した応答パケットの数とを比較することで、パケットロス率を求めることができる。
【０１００】
例えば、存在確認パケットは、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）のＥｃｈｏ要求パケットであり、応答パケットはＩＣＭＰのＥｃｈｏ応答パケットである。また或いは、存在確認パケット及び応答パケットは、その他のプロトコルを用いた独自作成のアプリケーションであっても良い。
【０１０１】
その他の構成要素１４０１〜１４０５は、前述の実施形態１の図３に示した構成３０１〜３０５と同一であるため説明は省略する。
【０１０２】
この実施形態２に係る通信装置１００では、この通信環境診断結果に応じて、前述の図１０〜図１３で示した再送要求方法パターンのいずれを選択するかを決定するためのテーブルを保持していても良い。
【０１０３】
図１５は、実施形態２に係る再送要求方法パターンテーブルの一例を示す図である。この再送要求方法パターンテーブルは、通信装置１００のＲＯＭ２０２、ＲＡＭ２０３、ＨＤＤ２０４のいずれかの記憶手段に記憶されている。
【０１０４】
この再送要求方法パターンテーブルは、ＲＴＴとパケットロス率という項目を含み、ＲＴＴは近距離であるか遠距離であるかに分類される。パケットロス率は小、中、大の３段階に分類される。例えば、図１４に示した通信環境診断部１４０６による通信環境診断の結果、ＲＴＴが０ｍｓから５ｍｓの間であった場合は近距離と判断し、５ｍｓ以上の場合は遠距離と判断する。同様に、通信環境診断の結果、パケットロス率が０％から０．１％の間の場合はパケットロス率が小、０．１％〜０．５％ならパケットロス率が中、０．５％以上ならパケットロス率が大とそれぞれ判定する。そして、ＲＴＴ及びパケットロス率による分類の結果、図１０〜図１３で示したパターンＡ〜Ｄの再送要求方法のうちいずれを選択するかという情報が、このテーブルの各セルに設定されている。
【０１０５】
例えば、近距離で、パケットロス率もあまり発生しない場合は、再送要求方法も一番シンプルな形態で十分であるため、パケットの欠落を検知した時点で直ちに、そのパケットの再送のみを要求する図１０のパターンＡが設定されている。
【０１０６】
またパケットロス率が小または中であるが、遠距離の場合は、パケットの到達順序が入れ替わる場合が増える可能性があるため、再送要求をしばらく待ち合わせる図１１のパターンＢが設定されている。
【０１０７】
さらに、近距離であるが、それなりの頻度でパケットロスが発生する場合（パケットロス率が中）は、再送パケットの転送に時間を要さないため、直ちには再送要求を行わず、サブデータ全体を受信してから再送要求を行う図１３のパターンＤが設定されている。
【０１０８】
そして、距離に関係なく、パケットロス率が大の場合は、再送要求パケットの送信回数が増え過ぎてしまう事態を回避するため、図１２のパターンＣが設定されている。
【０１０９】
実施形態２に係る通信装置１００のデータ通信実行部１４０２は、図９に示したサブデータ受信処理を実行する前に、通信環境診断部１４０６から、通信装置１０１との間の通信環境診断結果を取得する。その結果を、図１５に示した再送要求方法パターンテーブルと照らし合わせて、パターンＡ〜Ｄのいずれの再送要求方法を採用するかを決定することになる。
【０１１０】
以上説明したように本実施形態２によれば、通信相手との間の通信環境がどのような条件であっても、その環境下で最も適切な再送要求方法を自動的に選択することが可能となる。それにより、多様な通信環境下でも常に最適な通信パフォーマンスを維持することが可能となる。
【０１１１】
尚、実施形態１のように、送信側の通信装置１０１が、シーケンス番号が欠落したＵＤＰパケットデータと、それ以降のパケットデータをまとめて再送するのは、図１１の場合に適用しても良い。
【０１１２】
以上説明した実施形態の効果をまとめると以下のようになる。
【０１１３】
送信したいデータを所定サイズのサブデータに分割し、そのサブデータ単位で送信することにより、ネットワーク上の帯域を過剰に占有し過ぎてしまう事態を回避することができる。
【０１１４】
また、サブデータへの分割方法は受信側が決定するため、受信側に比べて送信側が高性能な通信装置である場合にも、受信側が受信しきれないようなデータを一気に送信側が送りつけてしまう事態を回避できる。
【０１１５】
更には、受信側でデータの欠落を検知したとき、通信状態に応じたタイミングで送信側にその再送要求を送信するため、例えばデータの欠落が多発する環境でも受信側が大量の再送要求を発行することがなくなる。
【０１１６】
（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
2014195158.tif 000003
【図２】
2014195158.tif 000004
【図３】
2014195158.tif 000005
【図４】
2014195158.tif 000006
【図５】
2014195158.tif 000007
【図６】
2014195158.tif 000008
【図７】
2014195158.tif 000009
【図８】
2014195158.tif 000010
【図９】
2014195158.tif 000011
【図１０】
2014195158.tif 000012
【図１１】
2014195158.tif 000013
【図１２】
2014195158.tif 000014
【図１３】
2014195158.tif 000015
【図１４】
2014195158.tif 000016
【図１５】
2014195158.tif 000017
【図１６】
2014195158.tif 000018
【図１７】
2014195158.tif 000019