(57)【要約】【課題】  データ配信管理装置において、例えばＴＣＰのフロー制御におけるバッファ操作の簡略化を目的としている。【解決手段】  データ配信管理装置において、受信したデータパケットを宛先に転送するパケット転送部と、前記パケット転送部で転送されるデータパケットのセグメントをバッファに記憶し、前記宛先からの送達確認応答パケットの受信に対応して、前記バッファにおける前記セグメントの記憶領域を空きとする記憶部と、前記バッファの空きと所定のセグメントサイズに基づいて受信ウィンドウサイズを求め、この受信ウィンドウサイズを、前記パケット転送部で受信したデータパケットの送信元に返送する返送部と、を備える。【選択図】  図１
2005277704.tif 000002
【特許請求の範囲】
【請求項１】
受信したデータパケットを宛先に転送する転送部と、
前記転送部で転送されるデータパケットのセグメントをバッファに記憶し、前記宛先からの送達確認応答パケットの受信に対応して、前記バッファにおける前記セグメントの記憶領域を空きとする記憶部と、
前記バッファの空きと所定のセグメントサイズに基づいて受信ウィンドウサイズを求め、この受信ウィンドウサイズを、前記転送部で受信したデータパケットの送信元に返送する返送部と、
を備えることを特徴とするデータ配信管理装置。
【請求項２】
前記セグメントサイズは、最大セグメントサイズであることを特徴とする請求項１に記載のデータ配信管理装置。
【請求項３】
前記セグメントサイズは、平均セグメントサイズであることを特徴とする請求項１に記載のデータ配信管理装置。
【請求項４】
前記返送部は、前記バッファの空きに記憶可能なセグメント数と所定のセグメントサイズとの積に基づいて受信ウィンドウサイズを求め、この受信ウィンドウサイズを、前記転送部で受信したデータパケットの送信元に返送することを特徴とする請求項１に記載のデータ配信管理装置。
【請求項５】
前記返送部は、前記バッファの空きに記憶可能なセグメント数と所定のセグメントサイズと所定の係数との積に基づいて受信ウィンドウサイズを求め、この受信ウィンドウサイズを、前記転送部で受信したデータパケットの送信元に返送することを特徴とする請求項１に記載のデータ配信管理装置。
【請求項６】
前記記憶部は、前記転送部で転送されるデータパケットのセグメントを、複数のコネクションにより共用されるバッファの共用記憶領域に記憶し、前記宛先からの送達確認応答パケットの受信に対応して、前記バッファにおける前記セグメントの共用記憶領域を空きとすることを特徴とする請求項１に記載のデータ配信管理装置。
【請求項７】
前記返送部は、さらに、前記宛先からの送達確認応答パケットの受信に対応して、前記バッファの空きと所定のセグメントサイズに基づいて受信ウィンドウサイズを求め、この受信ウィンドウサイズを、前記転送部で受信したデータパケットの送信元に送信することを特徴とする請求項１に記載のデータ配信管理装置。
【請求項８】
前記返送部は、さらに、前記宛先からの送達確認応答パケットの受信に対応して、前記バッファの空きと所定のセグメントサイズに基づいて受信ウィンドウサイズを求め、この受信ウィンドウサイズが所定の条件を満足する場合に、この受信ウィンドウサイズを、前記転送部で受信したデータパケットの送信元に送信することを特徴とする請求項１に記載のデータ配信管理装置。
【請求項９】
受信したデータパケットを宛先に転送する転送工程と、
前記転送工程で転送されるデータパケットのセグメントをバッファに記憶し、前記宛先からの送達確認応答パケットの受信に対応して、前記バッファにおける前記セグメントの記憶領域を空きとする記憶工程と、
前記バッファの空きと所定のセグメントサイズに基づいて受信ウィンドウサイズを求め、この受信ウィンドウサイズを、前記転送工程で受信したデータパケットの送信元に返送する返送工程と、
を備えることを特徴とするデータ配信管理方法。
【請求項１０】
前記宛先からの送達確認応答パケットの受信に対応して、前記バッファの空きと所定のセグメントサイズに基づいて受信ウィンドウサイズを求め、この受信ウィンドウサイズを、前記転送工程で受信したデータパケットの送信元に送信する送信工程と、
を備えることを特徴とする請求項９に記載のデータ配信管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、例えばＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）によるデータ転送を行うデータ配信管理装置に関するものである。
【背景技術】
【０００２】
いわゆる受信ウィンドウとして知られるＴＣＰのフロー制御においては、受信端末装置が送信端末装置に対し、送達確認応答なしに受信可能な最大情報量である受信ウィンドウサイズを通知し、送信端末装置は、通知されたウィンドウサイズを超過しない情報量のデータを送ることで、受信端末装置では送信された全てのデータを溢れることなく受信することが可能である。
例えば衛星回線のような伝送遅延の大きな通信回線を介する場合に、このようなＴＣＰによるデータ転送を効率的に行うために、例えば特許文献１に開示された従来のデータ配信管理装置においては、送信元のスループット情報をもとに、受信したデータセグメントを記憶するバッファのバッファサイズを可変設定するようにしている。
【０００３】
【特許文献１】特開２００３−１２４９８４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
特許文献１に開示された従来のデータ配信管理装置においては、バッファサイズを可変設定するという複雑な制御が必要であるという問題点があった。
【０００５】
この発明は、上述のような課題を解決するためになされたもので、データ配信管理装置において、例えばＴＣＰのフロー制御におけるバッファ操作の簡略化を目的としている。
【課題を解決するための手段】
【０００６】
この発明に係るデータ配信管理装置は、受信したデータパケットを宛先に転送するパケット転送部と、前記パケット転送部で転送されるデータパケットのセグメントをバッファに記憶し、前記宛先からの送達確認応答パケットの受信に対応して、前記バッファにおける前記セグメントの記憶領域を空きとする記憶部と、前記バッファの空きと所定のセグメントサイズに基づいて受信ウィンドウサイズを求め、この受信ウィンドウサイズを、前記パケット転送部で受信したデータパケットの送信元に返送する返送部と、を備えるものである。
【発明の効果】
【０００７】
この発明は、データ配信管理装置において、バッファの空きと所定のセグメントサイズに基づいて受信ウィンドウサイズを求めるようにすることにより、例えばＴＣＰのフロー制御におけるバッファ操作の簡略化を実現することができる。
【発明を実施するための最良の形態】
【０００８】
実施の形態１．
この発明の実施の形態１によるデータ配信管理装置は、バッファの空きに記憶可能なセグメント数と所定の最大セグメントサイズとの積として受信ウィンドウサイズを求めることにより、例えば衛星回線のような伝送遅延の大きな通信回線を介する場合にも、ＴＣＰのフロー制御におけるバッファ操作の簡略化を実現することができるものである。
【０００９】
図１は、この発明の実施の形態１によるデータ配信管理装置を示す構成図である。
図１において、第１の端末装置１から第２の端末装置２に対し、ＴＣＰのデータ転送が行われ、データ配信管理装置３はその間に配置される。また、第１の端末装置１とデータ配信管理装置３の間は、ＬＡＮを用いた高速な通信回線で接続され、データ配信管理装置３と第２の端末装置２の間は、例えば衛星回線のような伝送遅延の大きな通信回線で接続される。なお、データ配信管理装置３を配置することにより、衛星回線のような伝送遅延の大きな通信回線を介する場合にも、第２の端末装置２において、第１の端末装置１から送信された全てのデータを溢れることなく受信することが可能となるのである。
【００１０】
また、データ配信管理装置３は、第１の端末装置１から送信されるＴＣＰデータパケットを受信し、第２の端末装置２に転送する転送部３１と、受信した該ＴＣＰデータパケットに対する送達確認ＴＣＰ−ＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）パケットを生成し、第１の端末装置１に返送する返送部３２、転送する該ＴＣＰデータパケットのセグメントを記憶するバッファ３４、転送した該ＴＣＰデータパケットを第２の端末装置２が受信したことにより、第２の端末装置２から返送され、受信した送達確認ＴＣＰ−ＡＣＫパケットを終端し、それまで対応するＴＣＰデータパケットのセグメントをバッファ３４が保持するように制御する保持部３３、該コネクションの最大セグメントサイズなどの情報を保持する情報管理部３５から構成される。
なお、バッファ３４と保持部３３が記憶部を構成する。
【００１１】
なお、この実施の形態１では、第１の端末装置１と第２の端末装置２間の１本のＴＣＰコネクションにおけるデータ転送として説明するが、バッファ部３４をコネクション毎に分割することにより、複数のコネクションに対応することができる。また、第１の端末装置１と第２の端末装置２以外に端末装置があっても良い。
【００１２】
次に動作について説明する。
図２において、任意の時点、この例ではデータ配信管理装置３から第１の端末装置１に受信ウィンドウサイズの通知となるパケットＡＫｏ１を送信する時点で、該コネクションのデータ保持用バッファ３４に５つのパケットバッファＢｕｆｆ１〜Ｂｕｆｆ５が空いているとする。なお、パケットＡＫｏ１は、第１の端末装置１からのＴＣＰデータパケットの受信に対応して返送されるものであるが、図２ではこの受信以前を省略している。
【００１３】
該コネクション開設時に第１の端末装置１と第２の端末装置２との間で設定される最大セグメントサイズは、情報管理部３５に記録されており、ここでは１４６０バイトとする。従って、パケットバッファが５つ空いていることから、ＡＫｏ１で通知される受信ウィンドウサイズは次式となる。
受信ウィンドウサイズ＝１４６０バイト×５個＝７３００バイト    （式１）
【００１４】
その後、ある時点で第１の端末装置１から第２の端末装置２に多量のデータ配信が発生すると、第１の端末装置１は、データ配信管理装置３からの送達確認ＴＣＰ−ＡＣＫパケットを待つことなく、７３００バイト分のデータをパケットＤＴｒ１〜ＤＴｒ５までにデータセグメント（以下セグメントと略称する）として分割し、順次送信する。
【００１５】
データ配信管理装置３では、転送部３１により、第１の端末装置１が送信したＴＣＰデータパケットＤＴｒ１〜ＤＴｒ５が受信され、バッファ３４のパケットバッファＢｕｆｆ１〜Ｂｕｆｆ５で記憶され、転送部３１により、第２の端末装置２に対しパケットＤＴｒ１〜ＤＴｒ５と同じデータが格納されるパケットＤＴｓ１〜ＤＴｓ５が送信される。また、返送部３２により、第１の端末装置１に対し送達確認ＴＣＰ−ＡＣＫパケットＡＫｓ１〜ＡＫｓ５が返送される。また、パケットＤＴｒ１〜ＤＴｒ５のセグメントが記憶されるパケットバッファＢｕｆｆ１〜Ｂｕｆｆ５が保持部３３の制御により保持される。
【００１６】
データ配信管理装置３がパケットＤＴｒ１を受信した時点で、空いているパケットバッファは４つとなるので、返送される送達確認ＴＣＰ−ＡＣＫパケットＡＫｓ１で通知される受信ウィンドウサイズは次式となる。
受信ウィンドウサイズ＝１４６０バイト×４個＝５８４０バイト    （式２）
また、同様にパケットＡＫｓ５で通知される受信ウィンドウサイズは次式となる。
受信ウィンドウサイズ＝１４６０バイト×０個＝０バイト          （式３）
【００１７】
この時点で、データ配信管理装置３がそれ以上データを受信することができないため、第１の端末装置１は、受信ウィンドウが回復するまで次のデータ送信を中断する。
【００１８】
第２の端末装置２は、データ配信管理装置３が転送したＴＣＰデータパケットＤＴｓ１〜ＤＴｓ５を順に受信すると、送達確認ＴＣＰ−ＡＣＫパケットＡＫｒ１〜ＡＫｒ５を順に返送する。データ配信管理装置３の保持部３３では、これを終端し、対応するＴＣＰデータパケットのセグメントが記憶されているパケットバッファＢｕｆｆ１〜Ｂｕｆｆ５を再利用できるように解放する（すなわち空きとする）。なお、空きとするということは、この時点で、パケットバッファを上書き可能状態とすることでも良いし、また、パケットバッファの記憶を消去することでも良い。
【００１９】
この例では、パケットＡＫｒ３を終端し、対応するＴＣＰデータパケットのセグメントが記憶されるパケットバッファＢｕｆｆ３を解放した時点で、第１の端末装置１からのウィンドウプローブパケットＡＫｏ２を受信する。データ配信管理装置３は、ウィンドウプローブパケットＡＫｏ２に対する応答として、パケットＡＫｏ３を返送する。パケットＡＫｏ３で通知される受信ウィンドウサイズは、その時点でパケットバッファが３つ空いているので次式となる。
受信ウィンドウサイズ＝１４６０バイト×３個＝４３８０バイト    （式４）
【００２０】
第１の端末装置１は、パケットＡＫｏ３の受信により、データ配信管理装置３の受信ウィンドウの回復を知り、続くデータのうち４３８０バイト分の送信を再開する。データは、ＴＣＰデータパケットＤＴｒ６〜ＤＴｒ８に分割され、順にデータ配信管理装置３に送信される。
【００２１】
データ配信管理装置３では、パケットＤＴｒ６を受信した時点で、さらにパケットバッファが解放されており、パケットＡＫｓ６により次式の受信ウィンドウサイズを第１の端末装置１に通知する。
受信ウィンドウサイズ＝１４６０バイト×４個＝５８４０バイト    （式５）
【００２２】
第１の端末装置１では、送達確認ＴＣＰ−ＡＣＫパケットＤＴｒ６の受信ウィンドウサイズとして式６に示す値を期待していたが、式５と式６との受信ウィンドウサイズの差分について、更にデータ配信管理装置３が受信可能であると判断し、最後のデータを格納するパケットＤＴｒ９を送信する。
受信ウィンドウサイズ＝１４６０バイト×２個＝２９２０バイト    （式６）
【００２３】
以上のように、この発明の実施の形態１によるデータ配信管理装置においては、データ保持用バッファのうち、空いているパケットバッファ数（すなわちバッファの空きに記憶可能なセグメント数）と最大セグメントサイズを乗算して求めた受信ウィンドウサイズを通知することにより、例えば衛星回線のような伝送遅延の大きな通信回線を介する場合にも、ＴＣＰのフロー制御におけるバッファ操作の簡略化を実現することができる。
【００２４】
実施の形態２．
実施の形態１では、第１の端末装置１に対して通知する受信ウィンドウサイズとして、該コネクションのデータ保持用バッファ３４の空きパケットバッファ数（すなわちバッファの空きに記憶可能なセグメント数）に最大セグメントサイズを乗算した値を使用したが、実施の形態２では、さらにこの値に所定の係数を乗算するようにしたものである。
【００２５】
図３は、この発明の実施の形態２によるデータ配信管理装置を示す構成図である。図３において、データ配信管理装置３は、さらに該係数を保持する設定管理部３６を有する。
【００２６】
次に動作について説明する。ここでは、該係数を０．７とする。
図４において、実施の形態１と同様に、パケットＡＫｏ１によりデータ配信管理装置３から第１の端末装置１に次式の受信ウィンドウサイズが通知される。
受信ウィンドウサイズ＝１４６０バイト×５個×０．７＝５１１０バイト  （式７）
【００２７】
その後、ある時点で第１の端末装置１から第２の端末装置２に多量のデータ配信が発生すると、第１の端末装置１では、データ配信管理装置３からの送達確認ＴＣＰ−ＡＣＫパケットを待つことなく、５１１０バイト分のデータをパケットＤＴｒ１〜ＤＴｒ４に分割し、順次送信する。それぞれのＴＣＰデータパケットに格納されるセグメントは、最大セグメントサイズであるとは限らないが、この例ではパケットＤＴｒ１で１４６０バイト、パケットＤＴｒ２で１２００バイト、パケットＤＴｒ３で１２５０バイト、パケットＤＴｒ４で１２００バイトであり、合計５１１０バイトとなる。
【００２８】
データ配信管理装置３では、転送部３１により、第１の端末装置１が送信したＴＣＰデータパケットＤＴｒ１〜ＤＴｒ４が受信され、バッファ３４のパケットバッファＢｕｆｆ１〜Ｂｕｆｆ４で記憶し、転送部３１により、第２の端末装置２に対しパケットＤＴｒ１〜ＤＴｒ４と同じデータが格納されるパケットＤＴｓ１〜ＤＴｓ４が送信される。また、返送部３２により、第１の端末装置１に対し送達確認ＴＣＰ−ＡＣＫパケットＡＫｓ１〜ＡＫｓ４が返送される。また、ＴＣＰデータパケットＤＴｒ１〜ＤＴｒ４のセグメントが記憶されるバッファ３４のパケットバッファＢｕｆｆ１〜Ｂｕｆｆ４が保持部３３の制御により保持される。
【００２９】
データ配信管理装置３がパケットＤＴｒ１を受信した時点で、空いているパケットバッファは４つとなるので、返送される送達確認ＴＣＰ−ＡＣＫパケットＡＫｓ１で通知される受信ウィンドウサイズは次式となる。
受信ウィンドウサイズ＝１４６０バイト×４個×０．７＝４０８８バイト  （式８）
また、同様にパケットＡＫｓ４で通知される受信ウィンドウサイズは次式となる。
受信ウィンドウサイズ＝１４６０バイト×１個×０．７＝１０２２バイト  （式９）
【００３０】
第１の端末装置１は、データ配信管理装置３が次のデータを受信することができると分かるので、さらにパケットＤＴｒ５を送信する。データ配信管理装置３は、パケットＤＴｒ５を受信すると空きパケットバッファが枯渇するので、送達確認ＴＣＰ−ＡＣＫパケットのウィンドウサイズ値として次式の値を通知する。
受信ウィンドウサイズ＝１４６０バイト×０個×０．７＝０バイト    （式１０）
データ配信管理装置３がそれ以上データを受信することができないため、第１の端末装置１では、受信ウィンドウが回復するまで、続くデータの送信を待つ。
【００３１】
第２の端末装置２は、データ配信管理装置３が転送したパケットＤＴｓ１〜ＤＴｓ５を順に受信すると、送達確認ＴＣＰ−ＡＣＫパケットＡＫｒ１〜ＡＫｒ５を順に返送する。データ配信管理装置３の保持部３３では、これを終端し、対応するデータパケットのセグメントが記憶されるパケットバッファを再利用できるように解放する（すなわち空きとする）。
【００３２】
この例では、パケットＡＫｒ４を受信し、対応するＴＣＰデータパケットのセグメントが記憶されるパケットバッファＢｕｆｆ４を解放した時点で、第１の端末装置１からのウィンドウプローブパケットＡＫｏ２を受信する。データ配信管理装置３は、ウィンドウプローブＡＫｏ２に対する応答として、パケットＡＫｏ３を返送する。パケットＡＫｏ３で通知される受信ウィンドウサイズは、その時点でパケットバッファが４つ空いているので次式となる。
受信ウィンドウサイズ＝１４６０バイト×４個×０．７＝４０８８バイト  （式１１）
【００３３】
第１の端末装置１は、パケットＡＫｏ３の受信により、データ配信管理装置３の受信ウィンドウの回復を知り、続くデータのうち、４０８８バイト分の送信を再開する。データは、ＴＣＰデータパケットＤＴｒ６〜ＤＴｒ８に分割され、順にデータ配信管理装置３に送信される。
【００３４】
データ配信管理装置３では、パケットＤＴｒ６を受信した時点で、さらにパケットバッファが解放されており、パケットＤＴｒ８に対する送達確認ＴＣＰ−ＡＣＫパケットにより次式のウィンドウサイズが第１の端末装置１に通知される。
受信ウィンドウサイズ＝１４６０バイト×２個×０．７＝２０４４バイト  （式１２）
第１の端末装置１は、データ配信管理装置３がさらに次のデータを受信可能と分かるので、最後のデータを格納するパケットＤＴｒ９を送信する。
【００３５】
以上のように、この発明の実施の形態２によるデータ配信管理装置においては、データ保持用バッファのうち、空いているパケットバッファ数（すなわちバッファの空きに記憶可能なセグメント数）と最大セグメントサイズと所定の係数を乗算して求めた受信ウィンドウサイズを通知することにより、最大セグメントサイズに満たないデータパケットが混在する場合においても、ＴＣＰのフロー制御におけるバッファ操作の簡略化を実現することができる。
【００３６】
実施の形態３．
実施の形態１では、第１の端末装置１に対して通知する受信ウィンドウサイズとして、該コネクションのデータ保持用バッファ３４の空きパケットバッファ数（すなわちバッファの空きに記憶可能なセグメント数）に最大セグメントサイズを乗算した値を使用したが、実施の形態３では、最大セグメントサイズに代わり、平均セグメントサイズを使用するようにしたものである。
【００３７】
図５は、この発明の実施の形態３によるデータ配信管理装置を示す構成図である。図５において、平均長算出部３７は、複数個の最新のデータパケットについて、それらのセグメントサイズを保持し、平均セグメントサイズを算出する。
【００３８】
次に動作について説明する。
基本的な動作は実施の形態１の動作と同様であるが、第１の端末装置１からＴＣＰデータパケットを受信する際、そのセグメントサイズを、該パケットの受信用に使用したパケットバッファの番号に対応する平均長算出部３７のセグメントサイズ記憶位置に記憶する。例えば、セグメントをパケットバッファＢｕｆｆ３で受信した場合、そのセグメントサイズを平均算出部３７のセグメントサイズ記憶位置Ｂｕｆｆ３ｓｉｚｅに記憶する。
【００３９】
第１の端末装置１に送達確認ＴＣＰ−ＡＣＫパケットとして受信ウィンドウサイズを通知する際、平均長算出部に保持される各セグメントサイズを合算し、保持数で除算した値を平均セグメントサイズとして使用する。
【００４０】
以上のように、この発明の実施の形態３によるデータ配信管理装置においては、データ保持用バッファのうち、空いているパケットバッファ数（すなわちバッファの空きに記憶可能なセグメント数）と平均セグメントサイズを乗算して求めた受信ウィンドウサイズを通知することにより、コネクション開設時に設定された最大セグメントサイズに比べて、ＴＣＰデータパケットの実際のセグメントサイズが小さい場合にも、受信データを溢れさせることなく、ＴＣＰのフロー制御におけるバッファ操作の簡略化を実現することができる。
【００４１】
実施の形態４．
実施の形態３では、第１の端末装置１に対して通知する受信ウィンドウサイズとして、該コネクションのデータ保持用バッファ３４のうち空きパケットバッファ数に平均セグメントサイズを乗算した値を使用したが、実施の形態４では、さらに所定の係数を乗算して使用するようにしたものである。
【００４２】
図６は、この発明の実施の形態４によるデータ配信管理装置を示す構成図である。図６において、データ配信管理装置３は、該係数を保持するため、設定管理部３６を有する。
【００４３】
次に動作について説明する。
図６において、基本的な動作は実施の形態３の動作と同様であるが、第１の端末装置１に送達確認ＴＣＰ−ＡＣＫパケットとして受信ウィンドウサイズを通知する際、空きパケットバッファ数に平均セグメントサイズを乗算した値に、さらに設定管理部３７に保持される係数を乗算して使用する。
【００４４】
以上のように、この発明の実施の形態４によるデータ配信管理装置においては、データ保持用バッファのうち、空いているパケットバッファ数（すなわちバッファの空きに記憶可能なセグメント数）と平均セグメントサイズと所定の係数を乗算して求めた受信ウィンドウサイズを通知することにより、コネクション開設時に折衝された最大セグメントサイズに比べ、ＴＣＰデータパケットのセグメントサイズが比較的小さく、かつパケット毎にセグメントのサイズにばらつきが多い場合にも、受信データを溢れさせることなく、ＴＣＰのフロー制御におけるバッファ操作の簡略化を実現することができる。
【００４５】
実施の形態５．
実施の形態１では、複数のコネクションに対応する場合には、第１の端末装置１が送信するデータパケットを記憶するパケットバッファをコネクション毎に予め割当てるようにするが、実施の形態５では、各コネクションが共用するパケットバッファを設ける。
【００４６】
図７は、この発明の実施の形態５によるデータ配信管理装置を示す構成図である。図７おいて、バッファ３４において、３４１、３４２、３４３は、コネクション毎に予めパケットバッファを割当てたプール１、プール２、プール３、３４４は、各コネクションのＴＣＰデータパケットの受信が可能な共用プールである。
なお、共用プール３４４が共用記憶領域に該当する。
【００４７】
次に動作について説明する。
図７おいて、第１の端末装置１と第２の端末装置２の間に複数のコネクションが開設され、それぞれ第１の端末装置１から第２の端末装置２にデータが送信される。ここでは同一端末間でのコネクションとして説明するが、同一端末間ではなく複数の端末による複数のコネクションでも良い。また、コネクションが開設される際、使用するプールが設定されるものとする。
【００４８】
各コネクションのデータ転送は、まず、コネクション毎に割当てられたプールのパケットバッファを使用する。パケットバッファが枯渇すると、共用プール３４４から１つまたは複数の空きパケットバッファを獲得し、自プールの空きパケットバッファとして使用する。
【００４９】
図８に一例を示す。あるコネクションのデータ転送用にプール３  ３４３が使用され、さらに共用プール３４４のパケットバッファＢｕｆｆ０−１〜Ｂｕｆｆ０−６が使用される。なお、パケットバッファＢｕｆｆ０−７〜Ｂｕｆｆ０−９は、プール３  ３４３で追加使用することもできるし、プール１  ３４１およびプール２  ３４２で使用することもできる。また、第２の端末装置２からの送達確認ＴＣＰ−ＡＣＫパケットの応答により、該パケットバッファが解放されるとき、共用プール３４４に返却するようにしても良い。
【００５０】
以上のように、この発明の実施の形態５によるデータ配信管理装置においては、各コネクションで共用するパケットバッファを設けることにより、各コネクションの通信条件に柔軟に対応することができる。例えば、データ量またはパケット量の多いコネクション、および送達確認ＴＣＰ−ＡＣＫパケットのレスポンスに時間がかかるコネクションに対しては、データ配信管理装置内でデータ量を多く保持するようにできるので、データ転送性能を改善することができる。
【００５１】
実施の形態６．
実施の形態１〜５では、パケットバッファが枯渇後、第２の端末装置からの送達確認ＴＣＰ−ＡＣＫパケットの受信によりパケットバッファが回復しても、第１の端末装置１からのパケット受信がない場合には、第１の端末装置１に対してウィンドウの回復を通知しないが、実施の形態６では、第１の端末装置１からのパケット受信がない場合にも、第２の端末装置からの送達確認ＴＣＰ−ＡＣＫパケットの受信に対応して、これを通知するようにする。
【００５２】
図９は、この発明の実施の形態６によるデータ配信管理装置の動作を説明するための説明図である。図９において、データ配信管理装置３は、第１の端末装置１からのパケットＤＴｒ５を受信すると、最後の空きパケットバッファであるパケットバッファＢｕｆｆ５でこれを記憶し、パケットバッファが枯渇したことを受信ウィンドウサイズ＝０としてパケットバッファＡＫｓ５により通知する。
【００５３】
データ配信管理装置３では、パケットＤＴｓ１を受信したことを示す第２の端末装置からのパケットＡＫｒ１を受信すると、該ＴＣＰデータパケットを保持するパケットバッファＢｕｆｆ１が解放される（すなわち空きとされる）ので、バッファ３４が回復する。データ配信管理装置３は、パケットＡＫｒ１の受信に対応して回復した受信ウィンドウサイズ値を格納したパケットＡＫｓ６を第１の端末装置１に通知する。
【００５４】
第１の端末装置１では、パケットＡＫｓ６の受信により受信ウィンドウが回復したことが分かるので、続くデータをパケットＤＴｒ６として送信する。
【００５５】
以上のように、この発明の実施の形態６によるデータ配信管理装置においては、第２の端末装置からの送達確認ＴＣＰ−ＡＣＫパケットの受信に対応して、受信ウィンドウの回復を通知するようにしたことにより、第１の端末装置１によるウィンドウプローブパケットを受信しなくても、データ配信管理装置３がデータ転送を再開可能となった直後に、第１の端末装置１からデータの送信が可能となり、転送時間を短縮することができる。
【００５６】
実施の形態７．
実施の形態６では、パケットバッファが枯渇後、回復を契機として第１の端末装置１に受信ウィンドウの回復通知を行うが、実施の形態７では、パケットバッファの回復量が所定の閾値に達したことを契機として受信ウィンドウの回復通知を行う。
【００５７】
図１０は、この発明の実施の形態７によるデータ配信管理装置の動作を説明するための説明図である。この例では、受信ウィンドウの回復通知の契機として、パケットバッファが４つ以上回復したときを閾値とする。パケットＡＫｒ４の受信により、パケットバッファＢｕｆｆ１〜Ｂｕｆｆ４の４つが解放される。データ配信管理装置３は、第１の端末装置１に受信ウィンドウの回復をパケットＡＫｓ６により通知する。受信ウィンドウの回復通知を受けた第１の端末装置１は、続くデータの送信を再開し、パケットＤＴｒ６〜ＤＴｒ９を送信する。
【００５８】
以上のように、この発明の実施の形態７によるデータ配信管理装置においては、パケットバッファの空きが所定の閾値以上に回復したとき受信ウィンドウの回復を通知するようにしたことにより、第１の端末装置は、ある程度まとまったデータ量を送信再開することができるようになり、さらに転送時間を短縮することができる。
【００５９】
実施の形態８．
実施の形態６および７では、受信ウィンドウの回復通知を一旦パケットバッファが枯渇した後としたが、パケットバッファの空きが一旦所定の閾値以下に縮小した後、回復したとき、これを通知するようにしても良い。これにより、例えば第１の端末装置１が、データ配送管理装置３の受信ウィンドウサイズの枯渇ではなく、ある程度小さくなったらデータ送信を中断するような場合に、その回復をすばやく通知することができる。
【００６０】
なお、上述のように、この発明の実施の形態１〜８では、通信プロトコルとしてＴＣＰを用いる場合を示したが、通信プロトコルがこれに限られるものでないことは言うまでもなく、ＴＣＰと同様のフロー制御に対応したものであれば良い。
【図面の簡単な説明】
【００６１】
【図１】この発明の実施の形態１によるデータ配信管理装置を示す構成図
【図２】この発明の実施の形態１によるデータ配信管理装置の動作を説明するための説明図
【図３】この発明の実施の形態２によるデータ配信管理装置を示す構成図
【図４】この発明の実施の形態２によるデータ配信管理装置の動作を説明するための説明図
【図５】この発明の実施の形態３によるデータ配信管理装置を示す構成図
【図６】この発明の実施の形態４によるデータ配信管理装置を示す構成図
【図７】この発明の実施の形態５によるデータ配信管理装置を示す構成図
【図８】この発明の実施の形態５によるデータ配信管理装置を示す構成図
【図９】この発明の実施の形態６によるデータ配信管理装置の動作を説明するための説明図
【図１０】この発明の実施の形態７によるデータ配信管理装置の動作を説明するための説明図
【符号の説明】
【００６２】
３  データ配信管理装置
３１  転送部
３２  返送部
３３  保持部
３４  バッファ
３４４  共用プール
【図１】
2005277704.tif 000003
【図２】
2005277704.tif 000004
【図３】
2005277704.tif 000005
【図４】
2005277704.tif 000006
【図５】
2005277704.tif 000007
【図６】
2005277704.tif 000008
【図７】
2005277704.tif 000009
【図８】
2005277704.tif 000010
【図９】
2005277704.tif 000011
【図１０】
2005277704.tif 000012