特許 5816718 通信装置、通信システム、およびデータ通信の中継方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5816718

(24)【登録日】2015年10月2日

(45)【発行日】2015年11月18日

(54)【発明の名称】通信装置、通信システム、およびデータ通信の中継方法

(51)【国際特許分類】

   H04L 12/893 20130101AFI20151029BHJP

   H04L 12/879 20130101ALI20151029BHJP

   H04L 12/66 20060101ALI20151029BHJP

【ＦＩ】

   H04L12/893

   H04L12/879

   H04L12/66 A

【請求項の数】15

【全頁数】51

(21)【出願番号】特願2014-98260(P2014-98260)

(22)【出願日】2014年5月12日

(62)【分割の表示】特願2012-544129(P2012-544129)の分割

【原出願日】2011年7月28日

(65)【公開番号】特開2014-143760(P2014-143760A)

(43)【公開日】2014年8月7日

【審査請求日】2014年5月12日

(31)【優先権主張番号】特願2010-255521(P2010-255521)

(32)【優先日】2010年11月16日

(33)【優先権主張国】JP

(73)【特許権者】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】100100310

【弁理士】

【氏名又は名称】井上 学

(74)【代理人】

【識別番号】100098660

【弁理士】

【氏名又は名称】戸田 裕二

(74)【代理人】

【識別番号】100091720

【弁理士】

【氏名又は名称】岩崎 重美

(72)【発明者】

【氏名】磯部 隆史

(72)【発明者】

【氏名】矢崎 武己

(72)【発明者】

【氏名】森 拓郎

【審査官】 衣鳩 文彦

(56)【参考文献】

【文献】 特開２００６−０７４１０４（ＪＰ，Ａ）

【文献】 特開２００２−２１７９６３（ＪＰ，Ａ）

【文献】 特開平１１−１１２５７６（ＪＰ，Ａ）

【文献】 特開２００４−３２８７８６（ＪＰ，Ａ）

【文献】 特開２００１−３３３１１０（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／００〜１２／９５５

(57)【特許請求の範囲】

【請求項1】

データ通信を中継する通信装置において、
確認応答待ちの送信中データが記憶され、前記通信装置とネットワークとの第一のデータ通信に対する送信バッファと、
受信したデータの先頭を示す第一のポインタ、整列済みデータと未整列データとの境界を示す第二のポインタ、及び前記第二のポインタの直近の値を記録する第三のポインタを有し、整列待ちの受信中データが記憶され、送信端末と前記通信装置との第二のデータ通信に対する受信バッファと、
前記第二のデータ通信においてデータパケットを受信した場合は、少なくともひとつ前に受信したデータパケット、又は、最後尾データパケットより手前のデータパケットに対し、前記受信バッファの前記第三のポインタに記録された値を受信シーケンス番号とした確認応答を返信する演算部と、
を備えることを特徴とする通信装置。

【請求項2】

前記演算部は、
前記第一のデータ通信において確認応答待ちの送信中データが有り、又は、前記第二のデータ通信において整列待ちの受信中データが有る状態で前記第二のデータ通信においてデータパケットを受信した場合に、前記少なくともひとつ前に受信したデータパケット、又は、前記最後尾データパケットより手前のデータパケットに対し、前記受信バッファの前記第三のポインタに記録された値を受信シーケンス番号とした確認応答を返信することを特徴とする請求項１に記載の通信装置。

【請求項3】

前記演算部は、
前記第一のデータ通信において確認応答待ちの送信中データが無く、かつ、前記第二のデータ通信において整列待ちの受信中データも無い状態で、前記第二のデータ通信においてデータパケットを受信した場合は確認応答の返信を行わないことを特徴とする請求項２に記載の通信装置。

【請求項4】

前記演算部は、
前記送信バッファを参照して、前記第一のデータ通信において確認応答待ちの送信中データが有るか否か判定し、前記受信バッファを参照して前記第二のデータ通信において整列待ちの受信中データが有るか否かを判定することを特徴とする請求項１に記載の通信装置。

【請求項5】

前記演算部は、
前記第一のデータ通信において確認応答待ちの送信中データが有り、又は、前記第二のデータ通信において整列待ちの受信中データが有る状態で、前記第二のデータ通信において、前回受信したデータパケットと同じデータパケットを受信した場合は、前回確認応答を返信したデータパケットよりも後ろで、かつ、最後尾データパケットより手前のデータパケットに対する確認応答を返信することを特徴とする請求項２に記載の通信装置。

【請求項6】

前記演算部は、
前記第一のデータ通信において確認応答待ちの送信中データが有り、かつ、前記第二のデータ通信において整列待ちの受信中データが無い状態で前記第一のデータ通信において確認応答を受信して確認応答待ちの送信中データが無くなったタイミングで、前記第二のデータ通信において受信した最後尾データパケットに対する確認応答を返信することを特徴とする請求項１に記載の通信装置。

【請求項7】

前記演算部は、
前記第二のデータ通信において、ＰＳＨフラグのデータパケットを受信した後、前記第一のデータ通信において、確認応答を受信して確認応答待ちの送信中データが無くなった状態になったタイミングで、前記第二のデータ通信において受信したデータパケットのうち、最後尾に位置するデータパケットに対する確認応答を返信することを特徴とする請求項１に記載の通信装置。

【請求項8】

前記データ通信は、ＴＣＰ通信であることを特徴とする請求項１記載の通信装置。

【請求項9】

データ通信を中継する通信装置を備える通信システムであって、
第一の通信装置は、
確認応答待ちの送信中データが記憶され、前記第一の通信装置とネットワークとの第一のデータ通信に対する送信バッファと、
受信したデータの先頭を示す第一のポインタ、整列済みデータと未整列データとの境界を示す第二のポインタ、及び前記第二のポインタの直近の値を記録する第三のポインタを有し、整列待ちの受信中データが記憶され、送信端末と前記第一の通信装置との第二のデータ通信に対する受信バッファと、
前記第二のデータ通信においてデータパケットを受信した場合は、少なくともひとつ前に受信したデータパケット、又は、最後尾データパケットより手前のデータパケットに対し、前記受信バッファの前記第三のポインタに記録された値を受信シーケンス番号とした確認応答を返信する演算部と、
を備えることを特徴とする通信システム。

【請求項10】

前記第一の通信装置の演算部は、
前記第一のデータ通信において確認応答待ちの送信中データが有り、又は、前記第二のデータ通信において整列待ちの受信中データが有る状態で前記第二のデータ通信においてデータパケットを受信した場合に、前記少なくともひとつ前に受信したデータパケット、又は、前記最後尾データパケットより手前のデータパケットに対し、前記受信バッファの前記第三のポインタに記録された値を受信シーケンス番号とした確認応答を返信することを特徴とする請求項９に記載の通信システム。

【請求項11】

前記第一の通信装置の演算部は、
前記第一のデータ通信において確認応答待ちの送信中データが無く、かつ、前記第二のデータ通信において整列待ちの受信中データも無い状態で、前記第二のデータ通信においてデータパケットを受信した場合は確認応答の返信を行わないことを特徴とする請求項９に記載の通信システム。

【請求項12】

前記第一の通信装置の演算部は、
前記送信バッファを参照して、前記第一のデータ通信において確認応答待ちの送信中データが有るか否か判定し、前記受信バッファを参照して前記第二のデータ通信において整列待ちの受信中データが有るか否かを判定することを特徴とする請求項９に記載の通信システム。

【請求項13】

前記通信システムは、
前記第一の通信装置と前記ネットワークを介して接続される第二の通信装置を備え、
前記第一の通信装置は、送信端末との間の前記第二のデータ通信を中継し、
前記第二の通信装置は、前記第一の通信装置との間の前記第一のデータ通信を中継することを特徴とする請求項９に記載の通信システム。

【請求項14】

データ通信を中継する通信装置における中継制御方法であって、
前記通信装置は、
演算部と、
確認応答待ちの送信中データが記憶され、前記通信装置とネットワークとの第一のデータ通信に対する送信バッファと、
受信したデータの先頭を示す第一のポインタと、整列済みデータと未整列データとの境界を示す第二のポインタと、前記第二のポインタの直近の値を記録する第三のポインタとを有し、整列待ちの受信中データが記憶され、送信端末と前記通信装置との第二のデータ通信に対する受信バッファとを備え、
前記第二のデータ通信においてデータパケットを受信した場合は、少なくともひとつ前に受信したデータパケット、又は、最後尾データパケットより手前のデータパケットに対し、前記受信バッファの前記第三のポインタに記録された値を受信シーケンス番号とした確認応答を返信する
ことを特徴とする通信装置におけるデータ通信の中継制御方法。

【請求項15】

前記第一の通信装置の演算部は、
前記第一のデータ通信において確認応答待ちの送信中データが有り、かつ、前記第二のデータ通信において整列待ちの受信中データが無い状態で前記第一のデータ通信において確認応答を受信して確認応答待ちの送信中データが無くなったタイミングで、前記第二のデータ通信において受信した最後尾データパケットに対する確認応答を返信することを特徴とする請求項９に記載の通信システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、通信装置および通信システムに係り、特に、端末間の通信を中継する通信装置及び通信システムに関する。

【背景技術】

【0002】

グローバル拠点間の通信網として、ＩＰ−ＶＰＮ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ−Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）技術等を用いたＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）を用いることが、一般的になっている。ある拠点にある端末が、別の海外の拠点にある端末と通信する場合は、自拠点ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）と国内ＷＡＮを接続する回線と、国内ＷＡＮと海外ＷＡＮを接続する回線と、海外ＷＡＮと別拠点ＬＡＮを接続する回線と、を経由して通信が行われる。これらの回線は、契約帯域によって、使用可能な帯域幅が制限されている。

【0003】

端末間の通信では、ＴＣＰ（Ｔｒａｎｓｐｏｒｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を用いるのが一般的である。ＴＣＰ通信では、送信端末が送ったデータに対して、受信端末が受信済みデータ量を送信端末にフィードバック通知する。送信端末は、フィードバック通知される受信済みデータ量が増加しなくなると、廃棄検出と判定する。さらに、送信端末は、ウィンドウサイズ（受信したことを受信端末から通知されなくても送信可能なデータサイズ）と呼ばれるパラメータを管理しており、ＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）や廃棄検出の有無に応じて、ウィンドウサイズを変化させる。

【0004】

送信端末は、ＲＴＴ増加時や廃棄検出時にネットワークが混雑していると判定して、ウィンドウサイズを減少させることで、送信帯域を間接的に減少させて、ネットワークの混雑を回避する。また、ＲＴＴ減少時や廃棄が無い時にネットワークが空いていると判定して、ウィンドウサイズを増加させることで、送信帯域を間接的に増加させて、ネットワークの回線帯域を有効利用する。以上のように、ＴＣＰを用いた通信では、送信帯域がＲＴＴと廃棄率に大きく左右される。ＴＣＰ通信と同様の送信帯域制御技術として、非特許文献１に記載のＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）のＡＢＲ（Ａｖａｉｌａｂｌｅ Ｂｉｔ Ｒａｔｅ）や、特許文献１に記載の技術を用いた通信がある。本通信では、受信端末から送信端末へ、受信帯域や輻輳有無の情報がフィードバック通知され、送信端末は、フィードバック通知された情報に基づいて、送信帯域を制御する。

【0005】

他に、ＴＣＰ通信と同様の送信帯域制御技術として、特許文献２に記載の技術がある。本技術を用いた通信では、データ本体の送信帯域、誤り符号データの送信帯域、廃棄したデータの再送帯域の総和が一定値となるように制御を行う。再送帯域が増加したときは、誤り符号データの送信帯域を減少させる。更に、ＴＣＰ通信と同様の送信帯域制御技術として、特許文献３に記載の技術がある。本技術では、帯域制限を行う通信装置における、入力前の帯域と、出力後の帯域を比較し、帯域制限によるパケット廃棄に係るパケット廃棄帯域が一定値を超過したときに、帯域制限値を変化させる。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特開２００４−０８００７０号公報

【特許文献2】特開２００５−０６４６４８号公報

【特許文献3】特開２００８−１４１７３６号公報

【非特許文献】

【0007】

【非特許文献1】ＡＴＭ Ｆｏｒｕｍ、Ｔｒａｆｆｉｃ Ｍａｎａｇｅｍｅｎｔ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ ４．０、ａｆ−ｔｍ−００５６．００、ｐｐ．７−１０ Ａｐｒｉｌ １９９６．

【発明の概要】

【発明が解決しようとする課題】

【0008】

ＴＣＰを用いた通信では、ＲＴＴや廃棄検出の有無に応じて、送信帯域を制御するため、送信帯域がＲＴＴと廃棄率に大きく影響を受ける。このため、ＷＡＮのようなＲＴＴが大きく、ホップ数が大きく廃棄発生箇所が多い環境では、契約帯域を大幅に下回る送信帯域しか得られない場合があるという課題がある。

【0009】

また、非特許文献１や特許文献１に記載の技術では、受信側からフィードバック通知された受信帯域や輻輳有無の情報を用いて送信帯域を制御する。輻輳有無は通知されるが、輻輳の大きさが分からないため、どの程度、送信帯域を増減させればよいか分からない、という課題がある。

【0010】

また、特許文献２に記載の技術では、データ本体の送信帯域、誤り符号データの送信帯域、廃棄したデータの再送帯域の総和が一定値となるように制御を行う。制御帯域の総和が一定であるため、１つの回線を複数の通信が共有するケースなど、他の通信と競合して使用可能な帯域が減ったときに、再送帯域が制御帯域を超過して、データが全く送信できなくなってしまう、という課題がある。

【0011】

また、特許文献３に記載の技術は、装置の入力帯域と出力帯域の差分であるパケット廃棄帯域が一定値を超過したときに、帯域制限値を変化させることができるが、装置から受信端末までの通信経路上の輻輳状態・廃棄帯域を考慮した帯域制限をすることができない、という課題がある。

【0012】

しかし、通信装置が、ＴＣＰプロトコルに基づいて、送信端末から末尾のデータを受信して確認応答のＡＣＫパケットを返信し、その直後に故障した場合、送信端末では送信が完了している一方で、受信端末では受信が完了していない、というケースが発生し得る。このケースでは、受信端末側のデータが更新されないまま、送信端末側のアプリケーションが終了してしまい、受信端末に書き込むはずだったデータが書き込まれないまま消えてしまう、という課題が発生する。

【0013】

本発明は、以上の点に鑑み、送信端末では送信が完了している一方で、受信端末では受信が完了していない、というケースの発生を防ぐことを目的とする。また、本発明は、通信装置が、送信端末から末尾のデータを受信し、その直後に故障した場合でも、送信端末との通信の状態と、受信端末との通信の状態を一致するようにすることを目的の一つとする。

【課題を解決するための手段】

【0014】

上記課題を解決するために、本願発明の一態様では、受信端末側からの第一のデータパケットに対するＡＣＫパケット待ち状況に応じて、第一のデータパケットより後に送信端末から送信された第二のデータパケットに対するＡＣＫパケットを、送信端末に送信する、送信端末と受信端末とのパケット送受信を仲介する通信装置である。特に、通信装置内にＡＣＫ待ちの送信中データも整列待ちの受信中データも無い状態でデータパケットを受信した場合はＡＣＫ返信を行わず、通信装置内にＡＣＫ待ちの送信中データ、或いは整列待ちの受信中データが有る状態でデータパケットを受信した場合は１つ前に受信したデータパケットに対するＡＣＫを返信し、受信端末側からＡＣＫを受信してＡＣＫ待ちの送信中データも整列待ちの受信中データも無い状態になったタイミングで通常のＡＣＫを返信するための手段を備える。本発明の別の態様によると、２つの端末間に位置し、端末間のＴＣＰ通信を中継する第一の通信装置と第二の通信装置を備え、前記第二の通信装置が、通信中に受信できなかったデータの箇所を検出すると、未受信箇所の識別情報を確認応答パケットに含めて、前記第一の通信装置に対してフィードバック通知し、前記第一の通信装置は、フィードバック通知された確認応答パケットに含まれる未受信箇所のデータを含む再送パケットを前記第二の通信装置に送信し、前記第二の通信装置は、前記未受信箇所のデータを含む再送パケットを受信するまで、前記未受信箇所の識別情報を含む確認応答パケットを、前記第一の通信装置に対して、定期的にフィードバック通知する通信システムが提供される。また、本発明の別の態様によると、第一のデータ通信と第二のデータ通信の２つのデータ通信を中継する通信装置において、第二のデータ通信においてデータ付パケットを受信した場合は、少なくともひとつ前に受信したデータ付パケットに対する確認応答、又は、最後尾データより手前のデータに対する確認応答を返信し、第一のデータ通信において確認応答待ちの送信中データが有り、かつ、第二のデータ通信において整列待ちの受信中データが無い状態で第一のデータ通信において確認応答を受信して確認応答待ちの送信中データが無くなったタイミングで、第二のデータ通信において受信した最後尾データに対する確認応答を返信する通信装置が提供される。

【0015】

本発明の第１の解決手段によると、第一のＴＣＰ通信と第二のＴＣＰ通信の２つのＴＣＰ通信を中継する通信装置において、第二のＴＣＰ通信においてデータ付パケットを受信した場合は、少なくともひとつ前に受信したデータ付パケットに対する確認応答、又は、最後尾データより手前のデータに対する確認応答を返信し、第一のＴＣＰ通信において確認応答待ちの送信中データが有り、かつ、第二のＴＣＰ通信において整列待ちの受信中データが無い状態で第一のＴＣＰ通信において確認応答を受信して確認応答待ちの送信中データが無くなったタイミングで、第二のＴＣＰ通信において受信した最後尾データに対する確認応答を返信する通信装置が提供される。この通信装置によると、通信装置が故障しても、送信端末では送信が完了している一方で、受信端末では受信が完了していない、というケースの発生を防ぐ効果がある。

【0016】

本発明の第２の解決手段によると、２つの端末間に位置し、端末間のＴＣＰ通信を３つのＴＣＰ通信に分割して中継する第一の通信装置と第二の通信装置を備え、前記第一の通信装置がデータ送信端末との第一のＴＣＰ通信を実施し、前記第二の通信装置がデータ受信端末との第二のＴＣＰ通信を実施し、前記第一の通信装置と前記第二の通信装置の間で第三のＴＣＰ通信を実施し、各ＴＣＰ通信が送信データの再送と受信データの整列を独立して実施する通信システムであって、前記第二の通信装置が、通信中に受信できなかったデータの箇所を検出すると、未受信箇所の識別情報を確認応答パケットに含めて、前記第一の通信装置に対してフィードバック通知し、前記第一の通信装置は、フィードバック通知された確認応答パケットに含まれる未受信箇所のデータを含む再送パケットを前記第二の通信装置に送信し、前記第二の通信装置は、前記未受信箇所のデータを含む再送パケットを受信するまで、前記未受信箇所の識別情報を含む確認応答パケットを、前記第一の通信装置に対して、定期的にフィードバック通知する前記通信システムが提供される。この通信システムによると、ＲＴＴ毎の送信量を定めたウィンドウサイズ２６０５を制御することにより、帯域制御を行うＴＣＰ通信しかできない端末間でも、ＲＴＴや廃棄率に依存しない通信を実現することができる。

【発明の効果】

【0017】

本発明によると、通信装置が、送信端末から末尾のデータを受信し、その直後に故障した場合でも、送信端末との通信の状態と、受信端末との通信の状態が一致するため、送信端末では送信が完了している一方で、受信端末では受信が完了していない、というケースが発生しなくなる。

【図面の簡単な説明】

【0018】

【図1】通信装置９１０／９２０をＷＡＮとＬＡＮの境界に設置したシステム図。

【図2】パケットのフォーマット図。

【図3】通信装置のブロック図。

【図4】通信装置内部の標準ＴＣＰ部１００７のブロック図。

【図5】送信バッファ、受信バッファの管理用ポインタの説明図。

【図6】送受信共用バッファの管理用ポインタの説明図。

【図7】送信バッファ、受信バッファに追加した管理用ポインタの説明図。

【図8】通信装置１００、１０１が１パケット分ずらしてＡＣＫ返信するシーケンス 図。

【図9】送信端末１０３と通信装置１００の間で再送が発生した場合の問題点を説明するためのシーケンス図。

【図10】送信端末１０３と通信装置１００の間で再送が発生した場合のＡＣＫ返信方法を説明するためのシーケンス図。

【図11】送信端末１０３と通信装置１００の間で再送が発生した場合のＡＣＫ返信方法を説明するためのシーケンス図。

【図12】通信装置６００が次に来るコマンドを予測して予めコマンドをサーバ側へ送信する場合のＡＣＫ返信方法を説明するためのシーケンス図。

【図13】通信装置６００が次に来るコマンドを予測して予めコマンドをサーバ側へ送信する場合のＡＣＫ返信方法を説明するためのシーケンス図。

【図14】バッファ管理ポインタ更新と通信装置の送受信パケットのシーケンス図。

【図15】バッファ管理ポインタ更新と通信装置の送受信パケットのシーケンス図。

【図16】バッファ管理ポインタ更新と通信装置の送受信パケットのシーケンス図。

【図17】通信装置の送受信パケットとバッファのデータ有無のシーケンス図。

【図18】ＮＩＦ０ ＴＣＰモジュール１００７の受信履歴更新部３１０６の処理フローチャート。

【図19】ＮＩＦ０ ＴＣＰモジュール１００７のＴＸパケット再送部３１０４の処理フローチャート。

【図20】バッファ管理ポインタ更新のフローチャート図。

【図21】ＡＣＫ返信のフローチャート図。

【図22】ロストセグメント更新のフローチャート図。

【図23】受信履歴更新部３１０６がペイロード付きデータを受信した時の処理手順を示したフローチャート図。

【図24】ＴＸパケット再送部３１０４がＡＣＫパケットを受信した時の処理手順を示したフローチャート図。

【図25】通信装置８００がＰＳＨフラグ付パケットを受信した場合にＡＣＫ返信しないことを説明するためのシーケンス図。

【図26】通信装置９１０／９２０をＷＡＮとＬＡＮの境界に設置して、通信装置間で独自ＴＣＰを用いて通信するシステム図。

【図27】帯域制御方式の説明図。

【図28】再送制御方式の説明図。

【図29】部分的未確認応答ＮＡＣＫパケットの再送方法の説明図。

【図30】輻輳制御方式の説明図。

【図31】通信装置内部の独自ＴＣＰ部１００８のブロック図。

【図32】ＴＸ経路・シェーパテーブルのフォーマット図。

【図33】送信帯域制御部３２０６が制御帯域を更新する際の概念的なフローチャート。

【図34】シェーパ毎の送信・再送帯域テーブルのフォーマット図。

【図35】シェーパ毎の送信・再送帯域テーブル３２０５が保持する値の意味を説明するための概念図。

【図36】制御帯域の更新のフローチャート図。

【図37】実施例４におけるＮＩＦ０ ＴＣＰモジュール１００７の受信履歴更新部３１０６の処理フローチャート。

【図38】実施例４におけるＮＩＦ０ ＴＣＰモジュール１００７のＴＸパケット再送部３１０４の処理フローチャート。

【図39】実施例４を用いた場合に、通信装置間の独自ＴＣＰを用いた通信において、ロスセグメントが発生したときに、どのようにポインタが移動し、どのようなＡＣＫパケットが返信されるかの一例を示したシーケンス図。

【図40】実施例４を用いた場合に、通信装置＃１（３６００）が通信装置＃２（３６０２）からＮＡＣＫを受信したときに、どのようにポインタが移動するかを示したシーケンス図。

【図41】従来のプロキシ装置２００、２０１の問題点を説明するためのシーケンス図。

【図42】シェーパ毎の送信・再送帯域テーブル３２０５が保持する値の意味を説明するための概念図である。

【図43】送信帯域制御部３２０６が再送帯域の情報を用いて制御帯域を更新するフローチャート。

【図44】図４３の具体的な制御帯域の更新のフローチャート図。

【図45】送信帯域制御部３２０６が再送率の変化率を用いて制御帯域を更新するフローチャート。

【図46】送信帯域制御部３２０６が再送率の変化率を用いて、制御帯域を増加あるいは減少をさせ、制御帯域を更新するフローチャート。

【図47】図４６の具体的な制御帯域の更新のフローチャート図。

【図48】図９に示すデータ通信を行う前に、ＴＣＰコネクションを確立するためのシーケンス図。

【図49】図９に示すデータ通信を行う前に、ＴＣＰコネクションを確立するためのシーケンス図。

【図50】図９に示すデータ通信を行う前に、ＴＣＰコネクションを確立するためのシーケンス図。

【図51】図９に示すデータ通信を行った後に、ＴＣＰコネクションを切断するためのシーケンス図。

【図52】図９に示すデータ通信を行った後に、ＴＣＰコネクションを切断するためのシーケンス図。

【図53】図９に示すデータ通信を行った後に、ＴＣＰコネクションを切断するためのシーケンス図。

【発明を実施するための形態】

【0019】

本発明を実施するための代表的な形態は、以下のとおりである。まず、第一のＴＣＰ通信と第二のＴＣＰ通信の２つのＴＣＰ通信を中継する通信装置が、各ＴＣＰ通信に対して送信バッファと受信バッファを持ち、（１）第一のＴＣＰ通信の送信バッファ内にＡＣＫ待ちの送信中データが無く、尚且つ、第二のＴＣＰ通信の受信バッファ内に整列待ちの受信中データも無い状態で、第二のＴＣＰ通信においてデータパケットを受信した場合はＡＣＫ返信を行わず、（２）第一のＴＣＰ通信の送信バッファ内にＡＣＫ待ちの送信中データが有り、或いは、第二のＴＣＰ通信の受信バッファ内に整列待ちの受信中データが有る状態で、第二のＴＣＰ通信においてデータパケットを受信した場合は少なくとも１つ前に受信したデータパケットに対するＡＣＫを返信し、（３）第一のＴＣＰ通信の送信バッファ内にＡＣＫ待ちの送信中データが有り、尚且つ、第二のＴＣＰ通信の受信バッファ内に整列待ちの受信中データが無い状態で、第一のＴＣＰ通信においてＡＣＫを受信してＡＣＫ待ちの送信中データが無くなった状態になったタイミングで、第二のＴＣＰ通信において受信したデータパケットのうち、最後尾に位置するデータパケットに対するＡＣＫを返信するための手段を備える態様とした。この態様により、受信端末が、送信端末から送信した末尾データを受信するまで、送信端末は末尾データに対するＡＣＫを受け取ることができないため、通信装置が故障しても、送信端末では送信が完了している一方で、受信端末では受信が完了していない、というケースの発生を防ぐ効果がある。本態様の詳細は、実施例１を中心に後述する。

【0020】

別の様態として、ＴＣＰフラグとしてＰＳＨフラグを持つデータパケットを受信したときのみ、実施例１に記載のＡＣＫ返信方法を実施する態様とした。この態様により、送信端末が末尾データ送信時にＰＳＨフラグを付加するケースでは、実施例１と同等の効果が得られる。本態様の詳細は、実施例２を中心に後述する。

【0021】

更に、別の態様として、通信装置を端末間に２台設置し、端末間のＴＣＰ通信を３つのＴＣＰ通信に分割して、通信装置が中継する２つのＴＣＰ通信のうち、端末と通信装置間のＴＣＰ通信では、標準ＴＣＰを、通信装置間のＴＣＰ通信では特許出願１に記載の技術を用いる態様とした。この態様により、標準的なＴＣＰ通信しかできない端末間でも、ＲＴＴや廃棄率に依存しない通信を実現することができる。本態様の詳細は、実施例３を中心に後述する。

【0022】

更に、別の態様として、通信装置を端末間に２台設置し、端末間のＴＣＰ通信を３つのＴＣＰ通信に分割して、通信装置が中継する２つのＴＣＰ通信のうち、端末と通信装置間のＴＣＰ通信では、ＲＴＴ毎の送信量を制御することによる標準的なＴＣＰ（図２７参照）を、通信装置間のＴＣＰ通信では、特許出願１（特願２００９−２１４０１５号、ＰＣＴ／ＪＰ２０１０／０６３９７３）に記載の技術を用いつつ、さらに、実施例１に記載のＡＣＫ返信方法を用いる態様とした。この態様により、ＴＣＰ通信しかできない端末間でも、ＲＴＴや廃棄率に依存しない通信を実現することが出来、尚且つ、通信装置のいずれか一方が故障しても、送信端末では送信が完了している一方で、受信端末では受信が完了していない、というケースの発生を防ぐ効果がある。本態様の詳細は、実施例４を中心に後述する。

【0023】

他の本発明の態様は、以下に述べる種々の実施例で説明される。以下、本発明の態様を詳細に説明するべく、通信の中継を行う通信装置の構成や処理シーケンスや、当該装置がネットワークを介して接続されることにより構成されるシステム等の詳細について実施例を用いて述べる。

【実施例1】

【0024】

図１〜図２２を用いて、２つのＴＣＰ通信を中継中に故障した場合でも、送信端末では送信が完了している一方で、受信端末では受信が完了していない、というケースを発生させない通信装置の実施例を示す。図１には、通信装置＃１（９１０）と通信装置＃２（９２０）をネットワーク０（９００）とネットワーク１、２（９０１、９０２）の境界に設置して、ネットワーク１（９０１）に接続している端末（９０３・９０４）と、ネットワーク２（９０２）に接続している端末（９０５・９０６）の間で、３つのＴＣＰ通信を経由して通信が行われる様子を示す。通信装置＃１（９１０）は、ネットワークインターフェースＮＩＦ０／１（９１５／９１６）と、演算部９１１を備える。演算部９１１は、ＴＣＰ通信を行うＴＣＰモジュール９１３／９１４と、データの乗せ換えを行うＰｒｏｘｙモジュール９１２を実行する。なお、本実施例では、通信装置（９１０、９２０）はひとつでもよい。また、通信装置（９１０、９２０）は、例えば、プロキシ装置でもよい。

【0025】

図２には、本実施例でやりとりされるパケットのフォーマット図を表す。パケットは、ＭＡＣヘッダ２９００、ＩＰヘッダ２９０４、ＴＣＰヘッダ２９０９、ＴＣＰオプションヘッダ２９１６、ペイロード２９２７を含む。ＭＡＣヘッダ２９００は、宛先ＭＡＣアドレスを表すＤＭＡＣ２９０１と、送信元ＭＡＣアドレスを表すＳＭＡＣ２９０２と、ＭＡＣフレームタイプを表すＴｙｐｅ２９０３を含む。ＩＰヘッダ２９０４は、ＭＡＣヘッダを除くパケット長を表すＩＰ ｌｅｎｇｔｈ２９０５と、プロトコル番号を表すｐｒｏｔｏｃｏｌ２９０６と、送信元ＩＰアドレスを表すＳＩＰ２９０７と、宛先ＩＰアドレスを表すＤＩＰ２９０８とを含む。ＴＣＰヘッダ２９０９は、送信元ポート番号を表すｓｒｃ．ｐｏｒｔ２９１０と、宛先ポート番号を表すｄｓｔ．ｐｏｒｔ２９１１と、送信シーケンス番号を表すＳＥＱ２９１２と、受信シーケンス番号を表すＡＣＫ２９１３と、ＴＣＰフラグ番号を表すｆｌａｇ２９１４と、ＴＣＰのヘッダ長を表すｔｃｐ ｈｌｅｎ２９１５とを含む。ＴＣＰオプションヘッダ２９１６は、オプション種別を表すｏｐｔｉｏｎ ｋｉｎｄ２９１７と、オプション長を表すｏｐｔｉｏｎ ｌｅｎｇｔｈ２９１８と、どこからどこまで部分的に受信できたかを記載するｌｅｆｔ＿ｅｄｇｅ＿１〜４（２９１９、２９２１、２９２３、２９２５）、ｒｉｇｈｔ＿ｅｄｇｅ＿１〜４（２９２０、２９２２、２９２４、２９２６）を含む。

【0026】

図４１には、従来のプロキシ装置の課題を説明するためのシーケンス図を表す。送信端末１０３から受信端末１０４に向けて、従来のプロキシ＃１（２００）と従来のプロキシ＃２（２０１）とを経由して、４３８０バイトから構成されるファイルデータを１４６０バイトのデータを含むパケット３個（１１０、１１３、１１６）に分割して送信する場合（１０５）にやりとりされるパケットを示している。

【0027】

図４１の送信端末１０３のパケット３個（１１０、１１３、１１６）には、送信シーケンス番号として０、１４６０、２９２０の値が記載される。プロキシ＃１（２００）は、パケット（１１０、１１３、１１６）を受け取ると、受信パケット記載の送信シーケンス番号にペイロード長１４６０を加算して、その値を受信シーケンス番号ＡＣＫにした確認応答用のＡＣＫパケット（１２１、１２２、１２７）を送信端末１０３に返信する。送信端末１０３は、末尾データに対するＡＣＫパケット（１２７）を受信すると、送信が完了したと判断する（２３０）。その後で、プロキシ＃１（２００）に障害が発生したとする（２３２）。この場合、パケット（１１０、１１３）に記載されていたデータについては、プロキシ＃２に向けてパケット（１１１、１１４）として送信され、プロキシ＃２経由でパケット（１１２、１１５）として受信端末１０４に送り届けられる。それぞれのパケットに対するＡＣＫパケット（１２０、１２４、１１９、１２３）も返信される。一方、パケット（１１６）に記載されていたデータは、障害発生（２３２）と共に消滅してしまい、プロキシ＃１（２００）からは送信されなくなる。このため、受信端末１０４は、受信が未完了のままである（２３１）。すると、送信端末１０３では、送信が完了したと判断しているのにもかかわらず（２３０）、受信端末１０４では、受信が完了していないと判断している状態の不一致が発生することとなる。これは、プロキシ＃２（２０１）の障害発生でも起こりうる。

【0028】

上記の状態の不一致が発生した状態で、例えば、送信端末１０３でアプリケーションを使って編集したデータを受信端末１０４に送信完了してから、アプリケーションを終了するケースでは、受信端末１０４が編集データを受け取れないまま、送信端末のアプリケーションが終了してしまい、編集データが消滅してしまう、といった事態が起こる。以下、上述の状態の不一致を防ぐための構成・処理を詳細に説明する。

【0029】

（装置構成）
図３には、ハードウェアで実装した、本実施例の通信装置９１０のブロック図を表す。通信装置９２０も同様の構成である。通信装置９１０は、外部ネットワークとのパケットの送受信を行うネットワークインターフェースＮＩＦ０／１（１０１１／１０１２）と、ＴＣＰ以外のＵＤＰパケット等を素通しさせるためのフィルタ（１００９／１０１０）と、ＴＣＰ通信のための制御を行うＮＩＦ０／１向けＴＣＰモジュール１００７／１００８と、ＮＩＦ０向けＴＣＰモジュール１００７の管理するＮ個（Ｎは１以上の整数）の送信バッファ１０１３およびＮ個の受信バッファ１０１５と、ＮＩＦ１向けＴＣＰモジュール１００８の管理するＮ個の送信バッファ１０１６およびＮ個の受信バッファ１０１４と、送受信バッファ間でデータの乗せ換えを行うプロキシモジュール１０００と、Ｎ個のエントリを備えた状態テーブル１００１を有する。ソフトウェアで実装する際は、状態テーブル１００１と送受信バッファ（１０１３〜１０１６）を記憶部に持ち、フィルタ（１００９／１０１０）とＴＣＰモジュール１００７／１００８とプロキシモジュール１０００の部分をモジュールとして演算部（図１の演算部９１２に対応）に持たせる。

【0030】

状態テーブル１００１は、Ｎ個のエントリを持ち、各エントリは、ＩＰアドレス、ＴＣＰのポート番号等を含むコネクション特定のための情報１００２と、ＮＩＦ０側のＴＣＰのＯＰＥＮ／ＣＬＯＳＥ等の状態情報１００３と、ＮＩＦ１側のＴＣＰのＯＰＥＮ／ＣＬＯＳＥ等の状態情報１００４と、ＮＩＦ０側の送受信バッファ管理用のポインタ情報１００５と、ＮＩＦ１側の送受信バッファ管理用のポインタ情報１００６とを登録する。

【0031】

図４には、ＴＣＰモジュール１００７／１００８のブロック図を表す。標準ＴＣＰを実現するＴＣＰブロック１００７は、受信処理を行うＲＸ部（受信処理部）３１０２と、送信処理を行うＴＸ部（送信処理部）３１０１を有する。ＲＸ部３１０２は、受信パケットをＴＣＰ制御パケットとデータ付パケットとＡＣＫ／部分的確認応答用ＳＡＣＫパケットに分離するパケット解析部３１０８と、受信したＴＣＰ制御パケットに基づいて状態テーブル１００１内のＴＣＰ状態１００３を変更するＴＣＰ制御部３１０７と、受信したデータパケットの送信シーケンス番号ＳＥＱ２９１２と受信シーケンス番号ＡＣＫ２９１３とに基づいて、状態テーブル１００１内のバッファ管理ポインタ１００５を変更してＡＣＫパケットや部分的確認応答ＳＡＣＫ付ＡＣＫパケットを返信する受信履歴更新部３１０６、とを有する。受信履歴更新部３１０６のバッファ管理ポインタ１００５の変更については、後述する。ＴＸ部３１０１は、状態テーブル１００１内のＴＣＰ状態１００４を用いてＴＣＰ制御パケットを送信するＴＣＰ制御部３１０３と、受信したＡＣＫパケットに基づいて状態テーブル１００１内のバッファ管理ポインタ１００５を変更し、受信した部分的確認応答ＳＡＣＫ付ＡＣＫパケットを用いて送信バッファ１０１５からデータを読み出してパケットを再送するＴＸパケット再送部３１０４と、送信バッファ１０１５からデータを読み出してパケットを送信して、状態テーブル１００１内のバッファ管理ポインタ１００５を変更する送信履歴更新部３１０５と、ＡＣＫ／ＳＡＣＫパケット、ＴＣＰ制御パケット、再送パケット、データパケットをＦＩＦＯで集約して出力するマルチプレクサ（集約部）３１０９およびバッファ３１１０〜３１１３とを有する。なお、実施例１、２において、ＴＣＰ１００７／１００８は同様の構成としてもよい。

【0032】

（ポインタの説明）
図５には、送受信バッファ管理用のポインタの説明図を表す。本図では、データを左から右に書き込んでいき、左から右に読み出していくものとする。受信バッファ１０１３／１０１４は、受信したデータの先頭（受信右端、データを書き込む先頭位置）を示すポインタｒｉｇｈｔ＿ｒｅｃｖ１１０３と、整列済みデータと未整列データの境界を示すポインタｌｅｆｔ＿ｒｅｃｖ１１０２と、プロキシモジュール１０００による読出し済データと未読出しデータの境界を示すｌｅｆｔ＿ｒｂｕｆ１１０１と、受信できずに歯抜けになっているデータ箇所（ロスセグメント）の左端と右端を表すポインタｌｅｆｔ／ｒｉｇｈｔ＿ｌｏｓｓ１１０７−１〜ＳＥＧ＿ＳＩＺＥ（最大ＳＥＧ＿ＳＩＺＥ個）を管理する。

【0033】

受信したデータの先頭を示すポインタｒｉｇｈｔ＿ｒｅｃｖ１１０３は、ロスの発生が無く、前から順番にデータを受信すると、受信したデータサイズ分増えて、右へ移動する。受信できずに歯抜けになっているデータ箇所（ロスセグメント）が存在する状態で、再送パケットを受信して、ロスセグメントが消滅すると、整列済みデータと未整列データの境界を示すポインタｌｅｆｔ＿ｒｅｃｖ１１０２は、最も小さなロスセグメントの左端まで移動する。プロキシモジュールは、読出し済データと未読出しデータの境界を示すｌｅｆｔ＿ｒｂｕｆ１１０１から順番にデータを読み出し、読み出したデータサイズ分、ｌｅｆｔ＿ｒｂｕｆ１１０１を右へ移動させる。読み出せるデータサイズの最大値は、ｌｅｆｔ＿ｒｅｃｖ１１０２とｌｅｆｔ＿ｒｂｕｆ１１０１の差である。

【0034】

送信バッファ１０１５／１０１６は、プロキシモジュール１０００が書き込み済みで送信可能状態となっているデータの先頭（送信右端）を表すポインタｒｉｇｈｔ＿ｓｂｕｆ１１０６と、送信済みデータの先頭を示すポインタｒｉｇｈｔ＿ｓｅｎｄ１１０５と、受信側から確認応答を受信済みのデータの先頭を示すポインタｌｅｆｔ＿ｓｅｎｄ１１０４と、再送中のデータ箇所の左端と右端を表すポインタｌｅｆｔ／ｒｉｇｈｔ＿ｒｔｓ１１０８−１〜ＳＥＧ＿ＳＩＺＥ（最大ＳＥＧ＿ＳＩＺＥ個）を管理する。

【0035】

プロキシモジュールが書き込み済みで送信可能状態となっているデータの先頭を表すポインタｒｉｇｈｔ＿ｓｂｕｆ１１０６は、プロキシモジュールがデータを書き込む毎に、書き込んだデータサイズ分増加し、右へ移動する。送信したデータの先頭を示すポインタｒｉｇｈｔ＿ｓｅｎｄ１１０５を始点として、新たなデータが送信され、ｒｉｇｈｔ＿ｓｅｎｄ１１０５は、送信されたデータサイズ分増加し、右へ移動する。受信側から、ｌｅｆｔ＿ｓｅｎｄ１１０４よりも大きな受信シーケンス番号を持つ確認応答パケットを受信すると、ｌｅｆｔ＿ｓｅｎｄ１１０４は、確認応答パケットに記載された受信シーケンス番号へと増加し、右へ移動する。同一の受信シーケンス番号を持つ確認応答パケットを重複して受信するなど、再送が発生するケースでは、再送すべき箇所がｌｅｆｔ／ｒｉｇｈｔ＿ｒｔｓ１１０８に記載され、実際に再送されるとｌｅｆｔ／ｒｉｇｈｔ＿ｒｔｓ１１０８に０が代入され、再送済みとなる。

【0036】

図６には、ＮＩＦ０向けＴＣＰモジュール１００７の送信バッファ１０１５と、ＮＩＦ１向けＴＣＰモジュール１００８の受信バッファ１０１４を共有するケース、或いは、ＮＩＦ１向けＴＣＰの送信バッファ１０１６と、ＮＩＦ０向けＴＣＰの受信バッファ１０１３を共有するケースを示す。送信バッファ１０１６と受信バッファ１０１３間で、データを共有するために、プロキシモジュール１０００は、受信したデータを受信バッファ領域から送信バッファ領域に移動する場合である。送信バッファと受信バッファの２つのバッファを、１つの送受信共用バッファとし、送信バッファ用のポインタｒｉｇｈｔ＿ｓｂｕｆ１１０６と、受信バッファ用のポインタｌｅｆｔ＿ｒｂｕｆ１１０１が同一の値となる。この同一の値により、送信バッファ領域か、受信バッファ領域かが区別される。

【0037】

図７には、状態の不一致を防ぐための後述する図８に記載の通信装置（１００、１０１）のＡＣＫ返信方法を実現するために追加で必要となるバッファ管理用ポインタの説明図を示す。図５に示したポインタに加えて、直近のｌｅｆｔ＿ｒｅｃｖ１１０２の値を記録するためのポインタｐｒｅｖ＿ｌｅｆｔ＿ｒｅｃｖ１９００をさらに有する。なお、図６のようにバッファを構成した場合も同様である。

【0038】

（基本シーケンス）
図８には、本実施例における通信装置（１００、１０１）のＡＣＫ返信方法を記載したシーケンス図を表す。図４１と同様に、送信端末１０３から受信端末１０４に向けて４３８０バイトから構成されるファイルデータを１４６０バイトのデータを含むパケット３個（１１０、１１３、１１６）に分割して送信する例を示している。送信端末１０３からの１つ目のパケット（１１０−１１２）には、送信シーケンス番号として０、パケット長として１４６０が記載される（０番目のバイトから１４５９番目のバイトが送信される）。２つ目のパケット（１１３−１１５）には、送信シーケンス番号として先頭データを表す１４６０、パケット長として１４６０が記載される（１４６０番目のバイトから２９１９番目のバイトが送信される）。同様に、３つ目のパケット（１１６−１１８）には、送信シーケンス番号として先頭データを表す２９２０、パケット長として１４６０が記載される（２９２０番目のバイトから４３７９番目のバイトが送信される）。
通信装置＃１（１００）・通信装置＃２（１０１）（図１の通信装置９１０、９２０に相当）は、先頭パケット（１１０・１１１）を受け取ってもＡＣＫを返信しない。通信装置＃１（１００）・通信装置＃２（１０１）は、２つ目のパケット（１１３・１１４）を受け取ってから、１つ目のパケットに対するＡＣＫパケット（１２１、１２０）を返信する。更に、３つ目のパケット（１１６・１１７）を受け取ると、２つ目のパケットに対するＡＣＫパケット（１２２、１２４）を返信する。送信端末１０３は、３つ目のパケット（１１６）を送信しても、２つ目のパケットに対するＡＣＫパケット（１２２）しか受信しないので、送信が完了していないと判断したままである（１２８）。通信装置＃２（１０１）から３つ目のパケット（１１８）が受信端末１０４に到達して初めて、３つ目のパケットに対する末尾のＡＣＫパケット（１２５）が受信端末１０４から返信され、受信端末１３０は受信が完了したと判断する（１３０）。通信装置＃２（１０１）・通信装置＃１（１００）は、末尾のＡＣＫパケット（１２５・１２６）を受け取ると、３つ目のパケットに対する末尾のＡＣＫパケット（１２６・１２７）を送信側へ送信する。送信端末１０３は、末尾のＡＣＫパケット１２７を受け取り、送信が完了したと判断する（１２９）。受信端末１３０で受信が完了したと判断されない限り（１３０）、末尾のＡＣＫパケット（１２５、１２６、１２７）が送信端末１０３に返信されず、送信端末１２９が送信完了と判断しないため、受信端末１０４が編集データを受け取れないまま、送信端末のアプリケーションが終了してしまい、編集データが消滅してしまう、といった事態を防ぐことができる。なお、上述のように、ひとつ前に受信したデータパケットに対するＡＣＫを送信する以外にも、２つ前、３つ前など少なくともひとつ前のデータパケットに対するＡＣＫを送信してもよい。また、先頭パケット１１０に対しては、ＡＣＫを送信しない以外にも、先頭パケットの最後尾データに対応する受信シーケンス番号を含まないような（例えば、０〜１４５９）ＡＣＫを返送し、先頭パケットの最後尾データに対応する受信シーケンス番号を含むＡＣＫは返送しないようにしてもよい。

【0039】

（再送への対処）
図９には、通信装置間の回線帯域が狭いなど、受信端末１０４からの末尾のＡＣＫパケット（１２５）の返信が遅れた場合のシーケンス図を示す。この場合、送信端末１０３は、３つ目のパケット（１１６）が途中で廃棄したと判断して、パケットの再送を行う（５００）。通信装置＃１（１００）は、再送パケット（５０１）を受信すると、２つ目のパケット（１１３）に対するＡＣＫパケット（５０２）を重複して返信する。すると、送信端末１０３は、再びパケット廃棄が生じたと判断して、再度送信を行う（５０３）。通信装置＃１（１００）は、再送パケット（５０４）を受信すると、２つ目のパケットに対するＡＣＫパケット（５０５）を重複して返信する。すると、送信端末１０３は、再三パケット廃棄が生じたと判断して、再度送信を行う（５０６）。通信装置＃１（１００）は、再送パケット（５０７）を受信すると、２つ目のパケットに対するＡＣＫパケット（５０８）を重複して返信する。このように、何度も再送をした後に、３つ目のパケット（１１６）に対するＡＣＫパケット（１２７）を受け取ると、送信端末（１０３）がＴＣＰフラグ番号をＲＳＴ（reset）にセットしたパケット（５０９）を送信して、受信側では、強制的にＴＣＰコネクションを切断しなければならなくなる。

【0040】

図１０には、上記のＲＳＴパケット送信を防ぐための通信装置（１００、１０１）のＡＣＫ返信方法を記載したシーケンス図を表す。受信端末１０４からの末尾のＡＣＫパケット（１２５）の返信が遅れた場合、送信端末１０３は、３つ目のパケット（１１６）が途中で廃棄したと判断して、上述のようにパケットの再送を行う（３００）。通信装置＃１（１００）は、再送パケット（３０１）を受信すると、受信シーケンス番号を、２つ目のパケットに対するＡＣＫパケット（１２２）よりも大きく、３つ目のパケットに対するＡＣＫパケット（１２７）よりも小さく設定した、ＡＣＫパケット（３０２）を返信する。

【0041】

送信端末は、戻ってくるＡＣＫパケットの受信シーケンス番号がインクリメントしている間は、送信したパケット３０１の一部のデータが受信端末に届いており、送信端末１０３は通信回線がまだ繋がっていると判断するため、ＲＳＴを送信しなくなる。通信装置は、強制的にＴＣＰコネクション切断する制御をする必要がなくなる。

【0042】

図１１のように、送信端末１０３が、３つ目のパケット（１１６）が途中で廃棄したと判断してパケットを再送するケース（４００、４０３、４０６）が多い場合、受信シーケンス番号を１ずつ増加させてＡＣＫパケットを返信してもよい（４０２、４０５、４０８）。この場合、再送パケット（４０１、４０２、４０３）の送信シーケンス番号は１ずつ増加し、ペイロード長は１ずつ減少する。

【0043】

（予測コマンドへの対処）
図１２には、通信装置＃１（１００）と同一のＡＣＫ返信を行う通信装置＃１（６００）が、アプリケーション内部でウィンドウサイズを持っているＣＩＦＳ（Ｃｏｍｍｏｎ Ｉｎｔｅｒｎｅｔ Ｆｉｌｅ Ｓｙｓｔｅｍ）等のアプリケーションを高速化させるために、次に来るコマンドを予測して送信する機能を持っている場合に、本実施例の処理により不具合が発生することを説明するためのシーケンス図を示す。クライアント（クライアント装置）６０３が、サーバ６０４に向けて、ファイルの０バイト目から０ｘｆ０００（６１４４０）バイト読み出すｒｅａｄコマンドを記載したパケット６１０を送信したとする。通信装置＃１（６００）は、パケット６１０を中継してパケット６１１としてサーバ６０４に向けて送信すると共に、次にやって来るパケットには、ファイルの０ｘｆ０００バイト目から０ｘｆ０００（６１４４０）バイト読み出すｒｅａｄコマンドが記載されていると予測して、予め予測したｒｅａｄコマンドを記載したパケット６１３をサーバに向けて送信する。クライアントの発行したコマンドを記載したパケット６１１と、予測したコマンドを記載したパケット６１３は、通信装置＃２（６０１）経由で、パケット（６１２、６１４）としてサーバ６０４に届けられる。サーバ６０４は、コマンド記載パケットに対するＡＣＫパケット６１５を返信すると共に、コマンド記載の、ファイルの０バイト目から０ｘｆ０００（６１４４０）バイトのデータ（６１８）と、ファイルの０ｘｆ０００バイト目から０ｘｆ０００（６１４４０）バイトのデータ（６２１）をクライアント（６０３）に向けて送信する。これらのデータ（６１８、６２１）は、通信装置＃２（７０１）経由で通信装置＃１（７００）へデータ（６１９、６２２）として送られる。通信装置＃１（７００）は、クライアントの要求してきたデータ（６１９）を受信端末６０３へ送信する（６２０）一方で、後続データ（６２２）については、受信端末６０３への送信と末尾データに対するＡＣＫの受信が完了していないため、受け取ったデータサイズ０ｘ１ｅ０００よりも少ないサイズを受信シーケンス番号に記載したＡＣＫパケット６２４をサーバ側に返信する。クライアント６０３は、コマンドで要求したデータ（６２３）を受け取ると、受信が完了したと判断して（６２９）、再びコマンドを発行できるようになる。ここで、クライアント６０３が、通信装置＃１（６００）が予測したコマンド６１３とは異なるコマンド（例えば、ｔｒａｎｓ、ｃｒｅａｔｅ）を記載したパケット６２６を送信したとする。この場合、サーバ６０４は、送信したデータサイズよりも小さな受信シーケンス番号を持つＡＣＫパケット（６２５）が来て、送信が未完了だと判断している状態で（６３０）、次のコマンドを記載したパケット６２８を受信することになり、前のコマンドに対する処理が終わっていないため、次のコマンドに対する処理が行われず、アプリケーションが停止してしまう。

【0044】

図１３には、前記のアプリケーションの停止を防ぐためのシーケンス図を示す。通信装置＃１（７００）が、予測コマンドを発行している状態では、受け取ったデータサイズ０ｘ１ｅ０００と同一のサイズを受信シーケンス番号に記載したＡＣＫパケット７２４をサーバ側に返信する。自身が予測コマンドを発行している状態で、通常通りのＡＣＫ返信を行うことで、サーバ６０４は、送信したデータサイズと同一の受信シーケンス番号を持つＡＣＫパケット（７２５）を受け取ることによって、送信が完了したと判断することができ（７３０）、次のコマンド（６２８）がやって来たときに、次のコマンドに対する処理を続けて実行することが可能となる。アプリケーションが、次のコマンドに対する処理を行わずに、停止することが無くなる。予測コマンドを発行している状態か否かは、装置内に予測コマンドを発行することが予め設定されてもよいし、予測コマンドを発行した際にフラグを立ててそれを参照するなど、適宜の手法で判断できる。図８、図１０、図１１、図１３に示す通信装置の動作シーケンスは、図１に示すシステム、図３、図４のブロックを持つ装置によって実現される。

【0045】

図１４には、状態の不一致を防ぐために１パケット／１バイトずらしでＡＣＫ返信を行う通信装置２０００が、先頭データ２００５を受信したときに、どのようにポインタが移動するかを示したシーケンス図を示す。ここで、通信装置２０００は、通信装置９１０、９２０である。通信装置２０００が送信端末２００１との間のＴＣＰ通信に用いる受信バッファ２００３のポインタ移動と、通信装置２０００が受信端末２００２との間のＴＣＰ通信に用いる送信バッファ２００４のポインタ移動を示す。

【0046】

通信装置２０００が、送信端末２００１から送信シーケンス番号がｒｉｇｈｔ＿ｒｅｃｖ１１０３と等しい先頭データ付パケット２００５を受信すると、ｌｅｆｔ＿ｒｅｃｖ１１０２とｒｉｇｈｔ＿ｒｅｃｖ１１０３を、受信したデータサイズ分、右側へ移動させる（２００６）。ｐｒｅｖ＿ｌｅｆｔ＿ｒｅｃｖ１９００は不変である。受信シーケンス番号をｌｅｆｔ＿ｒｅｃｖ１１０２にした確認応答用のＡＣＫパケット１３０９を送信端末１３０１へ送る。ｌｅｆｔ＿ｒｅｃｖ１１０２がｌｅｆｔ＿ｒｂｕｆ１１０１よりも大きくなると、ｌｅｆｔ＿ｒｂｕｆ１１０１からｌｅｆｔ＿ｒｅｃｖ１１０２まで書かれているデータを、ｒｉｇｈｔ＿ｓｂｕｆ１１０６を先頭に送信バッファ２００７へ移動させて（２０１３）、ｌｅｆｔ＿ｒｂｕｆ１１０１とｒｉｇｈｔ＿ｓｂｕｆ１１０６を、移動させたデータサイズ分、右側へ移動させる（２００８、２００９）。ｒｉｇｈｔ＿ｓｂｕｆ１１０６がｒｉｇｈｔ＿ｓｅｎｄ１１０５よりも大きくなると、ｒｉｇｈｔ＿ｓｅｎｄ１１０５からｒｉｇｈｔ＿ｓｂｕｆ１１０６までのデータを受信端末２００２へ送信して（２０１１）、ｒｉｇｈｔ＿ｓｅｎｄ１１０５を、送信したデータサイズ分、右側へ移動させる（２０１２）。上記のシーケンスにより、通信装置内にＡＣＫ待ちの送信中データも整列待ちの受信中データも無い状態でデータパケットを受信した場合はＡＣＫ返信を行わない手段が実現される。

【0047】

図１５には、この状態から、更に、通信装置２０００が、送信端末２００１から送信シーケンス番号がｒｉｇｈｔ＿ｒｅｃｖ１１０３と等しい先頭データ付パケット２１０１を受信した場合のシーケンス図を示す。

【0048】

通信装置２０００が、パケット２１０１を受信すると、ｐｒｅｖ＿ｌｅｆｔ＿ｒｅｃｖ１９００にｌｅｆｔ＿ｒｅｃｖ１１０２の値を代入してから、ｌｅｆｔ＿ｒｅｃｖ１１０２とｒｉｇｈｔ＿ｒｅｃｖ１１０３を、受信したデータサイズ分、右側へ移動させて（２１０３）、受信シーケンス番号ＡＣＫ２９１３をｐｒｅｖ＿ｌｅｆｔ＿ｒｅｃｖ１９００にした確認応答用のＡＣＫパケット２１０４を送信端末２００１へ送る。なお、受信したパケットに対してＡＣＫを返信する場合は、受信シーケンス番号をｌｅｆｔ＿ｒｅｃｖ１１０２にした確認応答用のＡＣＫパケット１３１８を送信端末１３０１へ送ることになるが、本実施例では、１つ前のパケットに対するＡＣＫが送信される。ｌｅｆｔ＿ｒｅｃｖ１１０２がｌｅｆｔ＿ｒｂｕｆ１１０１よりも大きくなると、ｌｅｆｔ＿ｒｂｕｆ１１０１からｌｅｆｔ＿ｒｅｃｖ１１０２まで書かれているデータを、ｒｉｇｈｔ＿ｓｂｕｆ１１０６を先頭に送信バッファ２１０２へ移動させて（２１１０）、ｌｅｆｔ＿ｒｂｕｆ１１０１とｒｉｇｈｔ＿ｓｂｕｆ１１０６を、移動させたデータサイズ分、右側へ移動させる（２１０６、２１０５）。ｒｉｇｈｔ＿ｓｂｕｆ１１０６がｒｉｇｈｔ＿ｓｅｎｄ１１０５よりも大きくなると、ｒｉｇｈｔ＿ｓｅｎｄ１１０５からｒｉｇｈｔ＿ｓｂｕｆ１１０６までのデータを受信端末２００２へ送信して（２１０７）、ｒｉｇｈｔ＿ｓｅｎｄ１１０５を、送信したデータサイズ分、右側へ移動させる（２１０９）。なお、ｌｅｆｔ＿ｓｅｎｄ１１０４は、確認応答用のＡＣＫパケットを受信端末から受信していないので移動しない。上記のシーケンスにより、通信装置内にＡＣＫ待ちの送信中データ、或いは整列待ちの受信中データが有る状態でデータパケットを受信した場合は１つ前に受信したデータパケットに対するＡＣＫを返信する手段が実現される。

【0049】

図１６には、状態の不一致を防ぐために１パケット／１バイトずらしでＡＣＫ返信を行う通信装置２０００が、末尾データ２０１３を受信したときに、どのようにポインタが移動するかを示したシーケンス図を示す。通信装置２０００が送信端末２００１との間のＴＣＰ通信に用いる受信バッファ２０１０のポインタ移動と、通信装置２０００が受信端末２００２との間のＴＣＰ通信に用いる送信バッファ２０１２のポインタ移動を示す。

【0050】

通信装置２０００が末尾データを受信端末２００２に送信した後、送信バッファ２０１２では、ｒｉｇｈｔ＿ｓｅｎｄ１１０５とｒｉｇｈｔ＿ｓｂｕｆ１１０６が同じ値となり、ｒｉｇｈｔ＿ｓｅｎｄ１１０５はｌｅｆｔ＿ｓｅｎｄ１１０４よりも末尾データサイズ分大きい値となっている。受信バッファ２０１０では、ｌｅｆｔ＿ｒｅｃｖ１１０２とｒｉｇｈｔ＿ｒｅｃｖ１１０３が同じ値となっており、未整列の受信中データが存在せず、ｐｒｅｖ＿ｌｅｆｔ＿ｒｅｃｖ１９００がｌｅｆｔ＿ｒｅｃｖ１１０２よりも小さい値となっている。この状態で、受信シーケンス番号がｒｉｇｈｔ＿ｓｅｎｄ１１０５と同じ値である末尾データに対するＡＣＫパケット２０１３を受信すると、ｌｅｆｔ＿ｓｅｎｄ１１０４がｒｉｇｈｔ＿ｓｅｎｄ１１０５と同じ値となり（２０１４）、受信バッファ２０１０に未整列の受信中データが無い状態で、送信バッファ２０１２に確認応答待ちのデータが無くなる。このタイミングで、通信装置２０００は、受信シーケンス番号をｌｅｆｔ＿ｒｅｃｖ１１０２としたＡＣＫパケット２０１６を受信端末２００１に対して返信する。上記のシーケンスにより、受信バッファに整列待ちの受信中データが無い状態で、受信端末側からＡＣＫを受信して、送信バッファに確認応答待ちの送信中データが無くなったタイミングで通常のＡＣＫを返信する手段が実現される。

【0051】

図１７には、図８のシーケンス図に、送信側ＴＣＰ通信で用いる受信バッファにおける受信中データの有無と、受信側ＴＣＰ通信で用いる送信バッファにおける送信中データの有無の情報を加えたシーケンス図を示す。

【0052】

通信装置１００／１０１は、データ付パケット１１０／１１１を、受信中データも送信中データも無い状態１６０６／１６０９で受け取るので、先頭データと判断してＡＣＫを返信しない。また、通信装置１００／１０１は、受信シーケンス番号４３８０のＡＣＫパケット１２５／１２６を受け取ると、受信中データも送信中データも無い状態１６３０／１６３１に変化するため、末尾データに対するＡＣＫパケット１２６／１２７を返信する。データパケット（１１３、１１４、１１６、１１７）を受信したときは、受信中データか送信中データがある状態なので、一つ前のデータパケットに対するＡＣＫパケットを返信する。また、受信中データや送信中データがある状態で、ＡＣＫパケット（１１９、１２０、１２３、１２４）を受信すると、受信済みデータに対するＡＣＫパケットを送信側へ返信しない。

【0053】

図１８には、ＮＩＦ０ ＴＣＰモジュール１００７の受信履歴更新部３１０６の処理フローチャートを表す。処理がスタートすると（ステップ３８０１）、受信履歴更新部３１０６は、ペイロード長が０より大きなパケットを受信するまで待機する（ステップ３８０２）。パケットを受信すると、受信履歴更新部３１０６は、ＮＩＦ０の受信バッファの管理ポインタ１００５を変更し（ステップ３８０３）、ＮＩＦ０の受信バッファ１０１３へパケットデータを記録する（ステップ３８０４）。更に、受信履歴更新部３１０６は、ＮＩＦ１の送信バッファ１０１６に送信中データが残っている、またはＮＩＦ０の受信バッファに残っている受信中データのサイズが受信パケットのペイロードサイズよりも大きいか否かを判定する（ステップ３８０５）。受信履歴更新部３１０６は、否と判定された場合は、ステップ３８０２に戻る。受信履歴更新部３１０６は、真と判定された場合は、受信済みデータの１パケット前、または１バイト前に対するＡＣＫを返信する（ステップ３８０６）。ステップ３８０５により、図１４に示した、最初に到着したデータに対してＡＣＫを返信しないシーケンス処理が実現される。また、ステップ３８０５に続くステップ３８０６により、図１５に示した、受信済みデータの１パケット前、または１バイト前に対するＡＣＫ返信のシーケンス処理が実現される。

【0054】

図１９には、ＮＩＦ０ ＴＣＰモジュール１００７のＴＸパケット再送部３１０４の処理フローチャートを表す。処理がスタートすると（ステップ３９０１）、ＴＸパケット再送部３１０４は、ペイロード長が０のＡＣＫパケットを受信するまで待機する（ステップ３９０２）。ＡＣＫパケットを受信すると、ＴＸパケット再送部３１０４は、ＮＩＦ０の送信バッファと、ＮＩＦ１の受信バッファにデータが有るか否かを判定する（ステップ３９０３）。無い場合は、ステップ３９０２へ戻る。有る場合は、ＴＸパケット再送部３１０４は、受信したＡＣＫパケット記載の受信シーケンス番号ＡＣＫ２９１３やｌｅｆｔ＿ｅｄｇｅ＿１〜４（２９１９、２９２１、２９２３、２９２５）やｒｉｇｈｔ＿ｅｄｇｅ＿1〜４（２９２０、２９２２、２９２４、２９２６）に基づいて、ＮＩＦ０の送信バッファの管理ポインタを変更する（ステップ３９０５）。ステップ３９０５では、受信したＡＣＫパケットに記載されている受信シーケンス番号ＡＣＫ２９１３が、ｌｅｆｔ＿ｓｅｎｄ１１０４よりも大きい場合、ｌｅｆｔ＿ｓｅｎｄ１１０４は、受信シーケンス番号ＡＣＫ２９１３の値に変更される。例えば、末尾ＡＣＫであれば、送信バッファ中にＡＣＫ待ちのデータがなくなる。更に、ステップ３９０３と同様に、ＴＸパケット再送部３１０４は、もう一度、ＮＩＦ０の送信バッファと、ＮＩＦ１の受信バッファにデータが有るか否かを判定する（ステップ３９０６）。

【0055】

ステップ３９０６で、ＮＩＦ１の受信バッファにデータが有る場合は、ＴＸパケット再送部３１０４は、再送中のデータ箇所の左端と右端を表すポインタｌｅｆｔ／ｒｉｇｈｔ＿ｒｔｓ１１０８−１〜ＳＥＧ＿ＳＩＺＥの値を確認し、再送パケットがあるか否かを判定する（ステップ３９０８）。再送パケットが無い場合は、ステップ３９０２へ戻る。再送パケットが有る場合は、パケットを再送して（ステップ３９０９）、ステップ３９０２へ戻る。ステップ３９０６において、ＮＩＦ１の受信バッファにデータが無いと判定された場合は、ＡＣＫパケットを受信したＮＩＦ０とは反対側のＮＩＦ１で、受信済みデータに対するＡＣＫを送信する（ステップ３９０７）。ＮＩＦ０の送信バッファの管理ポインタ変更処理（ステップ３９０５）の前後で、ＮＩＦ０の送信バッファとＮＩＦ１の受信バッファに送受信中のデータが有る状態から無い状態に変化したときに、受信済みデータに対するＡＣＫを返信することで、図１６に示した受信側から末尾ＡＣＫを受信するまで、末尾ＡＣＫを返信しないシーケンス処理が実現される。

【0056】

図２０には、図１８の受信バッファの管理ポインタ（ｐｒｅｖ＿ｌｅｆｔ＿ｒｅｃｖ１９００と、ｌｅｆｔ＿ｒｅｃｖ１１０２と、ｒｉｇｈｔ＿ｒｅｃｖ１１０３）変更処理（ステップ３８０３）を詳細化し、ステップ３８０５を受信バッファ管理ポインタを用いて表したフローチャート図をあらわす。このフローチャートの各ステップは、例えば、通信装置のＴＣＰモジュール１００７、１００８が実行する。

【0057】

処理がスタートすると（ステップ１７０１）、データ付パケットを受信するまで待機する（ステップ１７０２）。データ付パケットを受信すると、ｌｅｎ＝ペイロード２９２７の長さ、ｌｅｆｔ＿ｐｋｔ＝受信パケットの送信シーケンス番号、ｒｉｇｈｔ＿ｐｋｔ＝ｌｅｆｔ＿ｐｋｔ＋ｌｅｎ、とする（ステップ１７０３）。その後、ｒｉｇｈｔ＿ｐｋｔがｒｉｇｈｔ＿ｒｅｃｖ１１０３よりも大きいか否かを判定する（ステップ１７０４）。大きい場合は、更に、ｒｉｇｈｔ＿ｒｅｃｖ１１０３がｌｅｆｔ＿ｐｋｔ以上か否かを判定する（ステップ１７０５）。ステップ１７０５の判定結果が真の場合は、ｒｉｇｈｔ＿ｒｅｃｖ１１０３にｒｉｇｈｔ＿ｐｋｔを代入する（ステップ１７０６）。更に、ロスセグメントの有無を判定し（１７０７）、無い場合はｐｒｅｖ＿ｌｅｆｔ＿ｒｅｃｖ１９００にｌｅｆｔ＿ｒｅｃｖ１１０２を代入し（ステップ２３０９）、ｌｅｆｔ＿ｒｅｃｖ１１０２にｒｉｇｈｔ＿ｐｋｔを代入する（ステップ１７０８）。有る場合は何もしない。ステップ１７０５の判定結果が偽の場合は、新規ロスセグメントｌｅｆｔ＿ｌｏｓｓ[ｋ]とｒｉｇｈｔ＿ｌｏｓｓ[ｋ]を作成して、ｌｅｆｔ＿ｌｏｓｓ[ｋ]にｒｉｇｈｔ＿ｒｅｃｖ１１０３の値を、ｒｉｇｈｔ＿ｌｏｓｓ[ｋ]にｌｅｆｔ＿ｐｋｔの値を代入して（１７０９）、その後でｐｒｅｖ＿ｌｅｆｔ＿ｒｅｃｖ１９００にｌｅｆｔ＿ｒｅｃｖ１１０２を代入し（ステップ２３１１）、ｒｉｇｈｔ＿ｒｅｃｖ１１０３にｒｉｇｈｔ＿ｐｋｔの値を代入する（１７１０）。ステップ１７０４の判定結果が偽の場合は、パケットのセグメント（ｌｅｆｔ＿ｐｋｔ〜ｒｉｇｈｔ＿ｐｋｔ）と１バイト以上一致するロスセグメント（ｌｅｆｔ＿ｌｏｓｓ[ｋ]〜ｒｉｇｈｔ＿ｌｏｓｓ[ｋ]）があるか否かを判定し（ステップ１７１１）、無い場合は何もしない。有る場合は、ロスセグメントを更新した上で（ステップ１７１２）、ロスセグメントの有無を判定する（ステップ１７１３）。ロスセグメントが無い場合は、ｌｅｆｔ＿ｒｅｃｖ１１０２にｒｉｇｈｔ＿ｒｅｃｖ１１０３の値を代入する（ステップ１７１４）。その後に、ｐｒｅｖ＿ｌｅｆｔ＿ｒｅｃｖ１９００にｌｅｆｔ＿ｒｅｃｖ１１０２−１の値を代入する（ステップ２３１９）。ロスセグメントが有る場合は、ｌｅｆｔ＿ｒｅｃｖ１１０２に最小のロスセグメントの左端の値を代入する（ステップ１７１５）。また、ｐｒｅｖ＿ｌｅｆｔ＿ｒｅｃｖ１９００にｌｅｆｔ＿ｒｅｃｖ１１０２を代入する（ステップ２３２０）。ｌｅｆｔ＿ｒｅｃｖ１１０２とｒｉｇｈｔ＿ｒｅｃｖ１１０３の変更が完了すると、ｌｅｆｔ＿ｒｅｃｖ１１０２を受信シーケンスＡＣＫ２９１３に記載してＡＣＫパケットを返信する（ステップ１７１６）。

【0058】

更に、ステップ１７０８の後と、ステップ１７０７で偽と判定された後に、受信バッファへパケットデータを記録し（ステップ３８１０）、ｒｉｇｈｔ＿ｓｂｕｆ１１０６がｌｅｆｔ＿ｓｅｎｄ１１０４よりも大きい、または、ｒｉｇｈｔ＿ｒｅｃｖ１１０３とｌｅｆｔ＿ｒｂｕｆ１１０１の差がｌｅｎよりも大きいか否かを判定する（ステップ２３１３）。ステップ２３１３は、受信バッファか送信バッファのいずれかに送受信中のデータが残っているか否かを判定するための処理である。ステップ２３１３で否と判定されたときは、ＡＣＫ返信をしないまま、ステップ１７０２へ戻る。本ステップを挿入することで、先頭データを受信したときにＡＣＫ返信しない手段が実現される。

【0059】

更に、ステップ１７１１で否と判定された後に、ｐｒｅｖ＿ｌｅｆｔ＿ｒｅｃｖ１９００とｌｅｆｔ＿ｐｋｔが等しく、尚且つ、ｌｅｆｔ＿ｒｅｃｖ１１０２がｒｉｇｈｔ＿ｒｅｃｖ１１０３と等しく、尚且つ、ｒｉｇｈｔ＿ｒｅｃｖ１１０３がｒｉｇｈｔ＿ｐｋｔと等しいか否かを判定する（ステップ２３２１）。ステップ２３２１で、真（等しい）と判定された時は、ｐｒｅｖ＿ｌｅｆｔ＿ｒｅｃｖ１９００を１インクリメントする（ステップ２３２２）。更に、ｐｒｅｖ＿ｌｅｆｔ＿ｒｅｃｖ１９００がｒｉｇｈｔ＿ｒｅｃｖ１１０３と等しいか否かの判定を行い（ステップ２３２３）、真（等しい）と判定された場合は、ｐｒｅｖ＿ｌｅｆｔ＿ｒｅｃｖ１９００にｌｅｆｔ＿ｒｅｃｖ１１０２−１の値を代入する（ステップ２３２４）。ステップ２３２１〜２３２４を挿入することで、送信端末からのパケット再送が繰り返されるときに、送信端末がＲＳＴパケットを送信してコネクションを強制切断する可能性が低くなる。ステップ２３１３で否と判定されるケース以外、ＡＣＫ返信を行ってから（ステップ２３２５）、ステップ１７０２へ戻る。

【0060】

図２１には、ステップ２３２５の詳細なフローチャートを示す。ステップ２３２５の処理がスタートすると（ステップ２４０１）、ｒｉｇｈｔ＿ｓｂｕｆ１１０６とｌｅｆｔ＿ｓｅｎｄ１１０４が等しく、尚且つ、ｒｉｇｈｔ＿ｒｅｃｖ１１０３とｌｅｆｔ＿ｒｂｕｆ１１０１が等しいか否かを判定する（ステップ２４０２）。ステップ２４０２は、送信バッファにも受信バッファにも送受信中のデータが残っていないことを確認するための処理である。否と判定され、すなわち、送受信中のデータが残っていると判定された場合は、図１２や図１３のシーケンス図に示したようなサーバ側に予測コマンドを送信中か否かを判定する（ステップ２４０３）。否と判定された場合は、ｐｒｅｖ＿ｌｅｆｔ＿ｒｅｃｖ１９００を受信シーケンス番号としてＡＣＫを返信する（ステップ２４０４）。ステップ２４０２で真と判定され、送信バッファにも受信バッファにも送受信中のデータが残っていないと判定された場合や、ステップ２４０３で真と判定され、サーバ側に予測コマンドを送信中だと判定された場合は、ｌｅｆｔ＿ｒｅｃｖ１１０２を受信シーケンス番号としてＡＣＫを返信する（ステップ２４０５）。

【0061】

通信装置は、ステップ２４０２の分岐を用いることで、受信端末からの末尾データに対するＡＣＫを受信するまで、送信側に末尾データに対するＡＣＫを返信しなくなるため、通信装置に障害が発生しても、図４１を用いて説明したような送信側のＴＣＰ通信と受信側のＴＣＰ通信の状態の不一致が起こらなくなる。また、ステップ２４０３の分岐を用いることで、サーバ側に予測コマンドを送信した後で予測が外れても、サーバに対して末尾データに対するＡＣＫが返信されるため、図１２を用いて説明したようなサーバ側の処理が止まることが無くなる。

【0062】

図２２には、ロスセグメント更新（ステップ１７１２）のフローチャートを示す。処理スタート後（ステップ１８０１）、ｌｅｆｔ＿ｐｋｔがｌｅｆｔ＿ｌｏｓｓ[ｋ]以下であり、尚且つｌｅｆｔ＿ｌｏｓｓ[ｋ]がｒｉｇｈｔ＿ｐｋｔよりも小さいか否かを判定する（ステップ１８０２）。ステップ１８０２において、否と判定された場合は、ｌｅｆｔ＿ｐｋｔがｒｉｇｈｔ＿ｌｏｓｓ[ｋ]よりも小さく、尚且つｒｉｇｈｔ＿ｌｏｓｓ[ｋ]がｒｉｇｈｔ＿ｐｋｔ以下であるか否かを判定する（ステップ１８０３）。ここで、否と判定された場合は、ｌｅｆｔ＿ｌｏｓｓ[ｋ]がｌｅｆｔ＿ｐｋｔよりも小さく、ｒｉｇｈｔ＿ｐｋｔがｒｉｇｈｔ＿ｌｏｓｓ[ｋ]よりも小さいか否かを判定する（ステップ１８０４）。ステップ１８０４において真と判定された場合、ｒｉｇｈｔ＿ｌｏｓｓ[ｋ]にｌｅｆｔ＿ｐｋｔを代入した上で（ステップ１８０５）、新規ロスセグメントｌｅｆｔ＿ｌｏｓｓ[ｊ]とｒｉｇｈｔ＿ｌｏｓｓ[ｊ]を作成して、ｌｅｆｔ＿ｌｏｓｓ[ｋ]にｒｉｇｈｔ＿ｐｋｔの値を、ｒｉｇｈｔ＿ｌｏｓｓ[ｋ]にｒｉｇｈｔ＿ｌｏｓｓ[ｋ]の値を代入する（１８０６）。

【0063】

ステップ１８０２にて真と判定された場合、ｌｅｆｔ＿ｌｏｓｓ[ｋ]にｒｉｇｈｔ＿ｐｋｔの値を代入する（ステップ１８０８）。ステップ１８０３にて真と判定された場合、ｒｉｇｈｔ＿ｌｏｓｓ[ｋ]にｌｅｆｔ＿ｐｋｔの値を代入する（ステップ１８０７）。ステップ１８０７／１８０８が完了すると、ｌｅｆｔ＿ｌｏｓｓ[ｋ]がｒｉｇｈｔ＿ｌｏｓｓ[ｋ]以上であるか否かを判定する（ステップ１８０９）。ステップ１８０９にて真と判定された場合、ロスセグメントｌｅｆｔ＿ｌｏｓｓ[ｋ]とｒｉｇｈｔ＿ｌｏｓｓ[ｋ]を初期化して、消去する（ステップ１８１０）。

【0064】

例えば、端末と通信装置の間では標準ＴＣＰを使って通信を行い受信データの整列や送信データの再送を行い、各通信装置間ではＲＴＴや廃棄率に依存しない独自のプロトコル（独自ＴＣＰ）を使って通信を行い受信データの整列や送信データの再送を行う通信装置を用いるときに、送信端末から末尾のデータを受信して確認応答のＡＣＫパケットを返信し、その直後に故障した場合、送信端末では送信が完了している一方で、受信端末では受信が完了していない、というケースの発生を防ぐことができる。

【0065】

（ポインタの移動の補足説明）以下、ポインタの移動について補足して説明する。受信したデータサイズに応じて受信シーケンス番号を記載してＡＣＫパケットを返信する通信装置が、パケットを前から順番に受信することが出来ずに、ロスセグメントが発生したときに、どのようにポインタが移動するかを以下に示す。通信装置が送信端末との間のＴＣＰ通信に用いる受信バッファのポインタ移動と、通信装置が受信端末との間のＴＣＰ通信に用いる送信バッファのポインタ移動を示す。

【0066】

通信装置が、送信端末から送信シーケンス番号がｒｉｇｈｔ＿ｒｅｃｖ１１０３よりも大きなデータ付パケットを受信すると、ｒｉｇｈｔ＿ｒｅｃｖ１１０３を、受信パケットの送信シーケンス番号とデータ長の和に変更して、ｌｅｆｔ＿ｌｏｓｓ[０]をｌｅｆｔ＿ｒｅｃｖ１１０２に、ｒｉｇｈｔ＿ｌｏｓｓ[０]を受信パケットの送信シーケンス番号にしたロスセグメント記録ポインタを新たに作成する。更に、受信シーケンス番号をｌｅｆｔ＿ｒｅｃｖ１１０２にして、ＴＣＰオプションヘッダ２９１６内のｌｅｆｔ＿ｅｄｇｅ＿１（２９１９）とｒｉｇｈｔ＿ｅｄｇｅ＿１（２９２０）に、ｒｉｇｈｔ＿ｌｏｓｓ[０]とｒｉｇｈｔ＿ｒｅｃｖ１１０３の値を記載した部分的確認応答（Ｓｅｌｅｃｔｉｖｅ ＡＣＫ（ＳＡＣＫ））用のＡＣＫパケットを送信端末へ送る。その後、更に、通信装置が、送信端末から送信シーケンス番号がｒｉｇｈｔ＿ｒｅｃｖ１１０３よりも大きなデータ付パケットを受信すると、ｌｅｆｔ＿ｌｏｓｓ[１]をｒｉｇｈｔ＿ｒｅｃｖ１１０３に、ｒｉｇｈｔ＿ｌｏｓｓ[１]を受信パケットの送信シーケンス番号にしたロスセグメント記録ポインタを新たに作成して、ｒｉｇｈｔ＿ｒｅｃｖ１１０３を、受信パケットの送信シーケンス番号とデータ長の和に変更する。更に、受信シーケンス番号をｌｅｆｔ＿ｒｅｃｖ１１０２にして、ＴＣＰオプションヘッダ２９１６内のｌｅｆｔ＿ｅｄｇｅ＿１（２９１９）とｒｉｇｈｔ＿ｅｄｇｅ＿１（２９２０）に、ｒｉｇｈｔ＿ｌｏｓｓ[０]とｌｅｆｔ＿ｌｏｓｓ[１]の値を記載し、ＴＣＰオプションヘッダ２９１６内のｌｅｆｔ＿ｅｄｇｅ＿２（２９２１）とｒｉｇｈｔ＿ｅｄｇｅ＿２（２９２２）に、ｒｉｇｈｔ＿ｌｏｓｓ[１]とｒｉｇｈｔ＿ｒｅｃｖ１１０３の値を記載した部分的確認応答ＳＡＣＫ付のＡＣＫパケットを送信端末へ送る。その後、通信装置が、送信シーケンス番号がｌｅｆｔ＿ｒｅｃｖ１１０２と等しく、送信シーケンス番号とデータ長の和がｒｉｇｈｔ＿ｌｏｓｓ[０]と等しいデータ付再送パケットを、送信端末から受信すると、ｌｅｆｔ＿ｒｅｃｖ１１０２をｌｅｆｔ＿ｌｏｓｓ[１]の所まで移動させて、ロスセグメント記録用ポインタｌｅｆｔ＿ｌｏｓｓ[０]とｒｉｇｈｔ＿ｌｏｓｓ[０]を初期化して無くして、受信シーケンス番号をｌｅｆｔ＿ｒｅｃｖ１１０２にした確認応答用のＡＣＫパケットを送信端末へ送る。ｌｅｆｔ＿ｒｅｃｖ１１０２がｌｅｆｔ＿ｒｂｕｆ１１０１よりも大きくなると、ｌｅｆｔ＿ｒｂｕｆ１１０１からｌｅｆｔ＿ｒｅｃｖ１１０２まで書かれているデータを、ｒｉｇｈｔ＿ｓｂｕｆ１１０６を先頭に送信バッファへ移動させて、ｌｅｆｔ＿ｒｂｕｆ１１０１とｒｉｇｈｔ＿ｓｂｕｆ１１０６を、移動させたデータサイズ分、右側へ移動させる。

【0067】

次に、受信したデータサイズに応じて受信シーケンス番号を記載してＡＣＫパケットを返信する通信装置が、受信端末からＡＣＫを受信したときに、どのようにポインタが移動するかを示す。通信装置が送信端末との間のＴＣＰ通信に用いる受信バッファのポインタ移動と、通信装置が受信端末との間のＴＣＰ通信に用いる送信バッファのポインタ移動を示す。

【0068】

通信装置が、すでにある程度の量のデータを受信端末へ送っており、ｒｉｇｈｔ＿ｓｂｕｆ１１０６とｒｉｇｈｔ＿ｓｅｎｄ１１０５が等しく、ｒｉｇｈｔ＿ｓｅｎｄ１１０５がｌｅｆｔ＿ｓｅｎｄ１１０４よりも大きいときを初期状態とする。通信装置が、受信端末から、受信シーケンス番号がｌｅｆｔ＿ｓｅｎｄ１１０４よりも大きくｒｉｇｈｔ＿ｓｅｎｄ１１０５よりも小さな確認応答用のＡＣＫパケットを受信すると、ｌｅｆｔ＿ｓｅｎｄ１１０４の値がＡＣＫパケット記載の受信シーケンス番号に変更される。更に、受信シーケンス番号がｌｅｆｔ＿ｓｅｎｄ１１０４の値と等しく、尚且つ、受信シーケンス番号がＡＣＫパケットのそれと等しく、ＴＣＰオプションヘッダ２９１６内のｌｅｆｔ＿ｅｄｇｅ＿１（２９１９）にｌｅｆｔ＿ｓｅｎｄ１１０４よりも大きくｒｉｇｈｔ＿ｓｅｎｄ１１０５よりも小さな値を記載し、ＴＣＰオプションヘッダ２９１６内のｒｉｇｈｔ＿ｅｄｇｅ＿１（２９２０）にｒｉｇｈｔ＿ｓｅｎｄ１１０５の値を記載した部分的確認応答（Ｓｅｌｅｃｔｉｖｅ ＡＣＫ（ＳＡＣＫ））用の重複ＡＣＫパケットを受信すると、ｌｅｆｔ＿ｒｔｓ[０]をｌｅｆｔ＿ｓｅｎｄ１１０４に、ｒｉｇｈｔ＿ｒｔｓ[０]をｌｅｆｔ＿ｅｄｇｅ＿１（２９１９）にした再送セグメント記録ポインタを新たに作成する。通信装置は、再送セグメントが作成されると、ｌｅｆｔ＿ｒｔｓ[０]からｒｉｇｈｔ＿ｒｔｓ[０]までのデータを再送して、再送セグメント記録ポインタを初期化して消去する。

【実施例2】

【0069】

図２３、図２４、図２５を用い、上述の実施例の図面を適宜参照して、パケットのＴＣＰフラグにＰＳＨフラグがセットされているか否かで末尾データか否かを判断して、末尾データに対するＡＣＫパケットが受信端末側から到着するまで、受信済みデータの１パケット前、または１バイト前に対するＡＣＫを返信する通信装置８００の実施例を示す。本実施例では、実施例１で示した図３、図４のブロック構成を持つ装置と同様の構成を用いる。図１８や図１９で示した受信履歴更新部３１０６やＴＸパケット再送部３１０４で行う処理に、幾つかの処理を追加することで、本実施例の通信装置８００を実現する。
図２３には、受信履歴更新部３１０６がペイロード付きデータを受信した時の処理手順を示したフローチャート図を示す。図１８と同様の処理については、同じ符号を付し、説明を省略する。新たに、ＰＳＨデータ受信中か否かを判定するための状態変数ＰＳＨ＿ｒｅｃｖを定義して、図１８に示したステップ３８０１の後に、ＰＳＨ＿ｒｅｃｖに０を代入する処理（ステップ４００１）を挿入する。更に、ステップ３８０４の後に、受信パケットのＴＣＰフラグにＰＳＨフラグがセットされているか否かを判定する処理（ステップ４００２）を挿入する。ステップ４００２において、真と判定された場合は、ＰＳＨ＿ｒｅｃｖに１を代入して（ステップ４００３）、ステップ３８０５に移る。ステップ４００２において、否と判定された場合は、ＮＩＦ０において、従来どおり、受信済みデータに対するＡＣＫを返信してから（ステップ４００４）、ステップ３８０２へと戻る。本処理方式により、ＰＳＨパケットを受信したときだけ、実施例１に示したＡＣＫ返信の機能が有効になる。

【0070】

図２４には、ＴＸパケット再送部３１０４がＡＣＫパケットを受信した時の処理手順を示したフローチャート図を示す。図１９と同様の処理については、同じ符号を付し、説明を省略する。図１９に示したステップ３９０５の後に、ＰＳＨ＿ｒｅｃｖが１であるか否かを判定する処理（ステップ４１０１）を追加する。ステップ４１０１で真（ＰＳＨ＿ｒｅｃｖが１である）と判定した場合は、ステップ３９０６へ戻る。ステップ４１０１で偽と判定した場合は、ステップ３９０６を飛ばして、ステップ３９０８へと進む。更に、ステップ３９０７の後に、ＰＳＨ＿ｒｅｃｖに０を代入する処理（ステップ４１０２）を追加する。本処理方式により、ＰＳＨパケットを受信したときだけ、実施例１に示した、末尾データに対するＡＣＫパケットが受信端末側から到着するまで、末尾ＡＣＫを返信しない機能が有効になる。

【0071】

図２５には、装置８００が、図２３、図２４の処理方式を用いて、末尾データか否かを、パケット記載のＴＣＰフラグｆｌａｇ２９１４にＰＳＨフラグがセットされているか否かで判定を行い、ＰＳＨデータ受信中のときだけ、末尾データに対するＡＣＫパケットが受信端末側から到着するまで、末尾ＡＣＫを返信しない処理を行った場合のシーケンス図を示す。通信装置＃１（８００）が、送信端末８０３からＰＳＨフラグ付パケット８１０を受け取ると、末尾のデータと判断してＡＣＫを返信せずに、そのまま通信装置＃２へ送信する（８１１）。通信装置＃２（８０１）は、同様に、末尾のデータと判断してＡＣＫを返信せずに、そのまま受信端末（８０４）へと送信する（８１２）。通信装置＃１（８００）は、再送パケット（８１３）を受け取っても、受信シーケンス番号に受信済みデータサイズよりも1〜１４５９小さな値をセットしたＡＣＫを返信する。通信装置＃２（８０１）・通信装置＃１（８００）は、受信シーケンス番号に受信済みデータサイズをセットした末尾のデータに対するＡＣＫパケット（８１６、８１５）を受信端末側から受け取ると、送信端末側に向けて末尾のデータに対するＡＣＫパケット（８１５、８１４）を送信する。上記の方式により、送信端末では、送信が完了したと判断しているのにもかかわらず、受信端末では、受信が完了していないと判断している状態の不一致を防ぐことができる。

【実施例3】

【0072】

図２６〜図３６を用い、上述の実施例の図面を適宜参照して、送信端末と受信端末の間に２つの通信装置を設置し、通信装置間では上記特許出願１に記載の、又はそれをさらに改良した独自ＴＣＰによる通信を行うための実施例を示す。

【0073】

図２６には、図１をベースにＮＩＦ１側のＴＣＰモジュールを上記の独自ＴＣＰの処理を行うモジュール２５０１／２５０２に変更したシステム図を示す。本システムでは、ＷＡＮ９０７内で独自ＴＣＰを用いて通信が行われる。通信装置９１０／９２０（例えば、通信装置）は、図３に示したブロック図と同様なブロック図で実装することができ、ＮＩＦ ＴＣＰ１００８が独自ＴＣＰモジュール２５０１／２５０２に変わる。

【0074】

受信端末側の通信装置は、送信端末側の通信装置に対して廃棄箇所を全て逐一フィードバック通知すると共に、送信端末側の通信装置は、受信端末側の通信装置からフィードバック通知された廃棄箇所を再送し、尚且つ、基準時刻以降の再送帯域又は廃棄帯域（再送／廃棄帯域と記すこともある）と、基準時刻以前の送信帯域とに基づいて、特定の宛先に対するデータ送信帯域とデータ再送帯域の総和を制御することで、ＲＴＴや廃棄率に依存しない通信帯域を確保する。

【0075】

図２７〜図３０には、独自ＴＣＰの３つの特徴を表した説明図を示す。なお、独自ＴＣＰは、以降、Ｒａｄｉｃ（ＲＴＴ Ａｎｄ Ｄｉｓｃａｒｄ Ｉｎｄｅｐｅｎｄｅｎｔ Ｃｏｎｇｅｓｔｉｏｎ Ｃｏｎｔｒｏｌ）−ＴＣＰと記載することもある。図２７には、左側に、標準的なＴＣＰの例として従来型ＴＣＰの帯域制御方式を、特許出願１記載の右側に独自ＴＣＰの帯域制御方式を示す。従来型ＴＣＰは、送信端末２６０１において、ＲＴＴ毎の送信量を定めたウィンドウサイズ２６０５を制御することで（２６０７）、送信帯域を制御する。送信帯域は、ウィンドウサイズ／ＲＴＴで表される。この方式による帯域制御は、ＲＴＴが増加すると回線が空いていても送信不可能な時間２６１０が増加して、回線帯域の利用率が減少する、という課題があった。一方、独自ＴＣＰでは、一定時間毎の送信量を定めたトークンサイズ２６０６を制御することで（２６０８）、送信帯域を制御する。送信帯域は、トークンサイズ／インターバル時間で表される。独自ＴＣＰを用いることで、回線が空いていても送信不可能な時間を無くすことが出来るため、回線帯域の利用率が増加する（２６０９）。ＲＴＴに依存しない帯域制御を実現することができる。

【0076】

図２８には、左側に従来型ＴＣＰの再送制御方式を、右側に独自ＴＣＰの再送制御方式を示す。従来型ＴＣＰでは、ＡＣＫパケットのＴＣＰオプションヘッダ２９１６内のｌｅｆｔ＿ｅｄｇｅ＿１〜４（２９１９、２９２１、２９２３、２９２５）、ｒｉｇｈｔ＿ｅｄｇｅ＿１〜４（２９２０、２９２２、２９２４、２９２６）には、どこからどこまで部分的に受信済であるかを最大４箇所記載して、部分的確認応答（Ｓｅｌｅｃｔｉｖｅ ＡＣＫ（ＳＡＣＫ））用に用いる。一方、独自ＴＣＰでは、ＴＣＰオプションヘッダ２９１６内のｌｅｆｔ＿ｅｄｇｅ＿１〜４（２９１９、２９２１、２９２３、２９２５）、ｒｉｇｈｔ＿ｅｄｇｅ＿１〜４（２９２０、２９２２、２９２４、２９２６）には、どこからどこまで部分的に再送してほしいかを最大４箇所記載して、部分的未確認応答（Ｎｅｇａｔｉｖｅ ＡＣＫ（ＮＡＣＫ））用に用いる。

【0077】

従来型ＴＣＰでは、送信端末２７０１から受信端末２７０２へ送った１２個のデータパケットＡ〜Ｌ（２７０５）のうち、Ｂ、Ｄ、Ｆ、Ｈ、Ｊが途中で廃棄されたとすると、ＴＣＰオプションヘッダ２９１６に書き込める受信済み箇所が最大４箇所までである制約から、Ｉ以降に送ったパケットに対する確認応答をこの時点では送信端末２７０１に送ることができない（２７０９）。送信端末は、Ａ〜Ｉまでの部分的確認応答を記載した確認応答パケット（２７０９）を用いて、パケットＡ〜Ｉのうち廃棄されたパケットＢ、Ｄ、Ｆ、Ｈを再送する（２７０６）。受信端末２７０２は、再送パケット（２７０６）を受信してから、パケットＩ以降の部分的確認応答を記載した確認応答を返信する（２７１２）。送信端末２７０１は、パケットＩ以降の部分的確認応答を記載した確認応答（２７１２）を受信してから、パケットＩ以降に廃棄されたパケットＪを再送することができる（２７０７）。一方、独自ＴＣＰでは、送信端末２７０３から受信端末２７０４へ送った１２個のデータパケットＡ〜Ｌ（２７０８）のうち、Ｂ、Ｄ、Ｆ、Ｈ、Ｊが途中で廃棄されたとしても、Ａ〜Ｊまでの再送してほしい箇所をＴＣＰオプションヘッダ２９１６内のｌｅｆｔ＿ｅｄｇｅ＿１（２９１９とｒｉｇｈｔ＿ｅｄｇｅ＿１（２９２０）へ逐一書き込んでから、部分的未確認応答用（ＮＡＣＫ）のＡＣＫパケットを返信する（２７１１）。各再送要求箇所は、１つのＮＡＣＫパケットにだけ書き込まれる。送信端末２７０３は、部分的未確認応答用（ＮＡＣＫ）のＡＣＫパケット（２７１１）を受信すると、ＴＣＰオプションヘッダ２９１６に記載された再送要求箇所Ｂ、Ｄ、Ｆ、Ｈ、Ｊを再送する（２７１０）。ロスが大量に発生したときでも、一度で再送が完了するため、通信時間が短縮し（２７１２）、帯域が向上する。つまり、送信端末と受信端末の間に２台の通信中継装置（通信装置）を設置し、受信端末側の通信装置が送信端末側の通信装置に対して廃棄箇所を全て逐一フィードバック通知する。例えば、送信端末側の通信装置は、受信端末側の通信装置からフィードバック通知された廃棄箇所を再送すると共に、基準時刻以降の再送帯域や廃棄帯域と、基準時刻以前の送信帯域とに基づいて、特定の宛先に対するデータ送信帯域とデータ再送帯域の総和を増減させる。それにより、廃棄率に依存しない通信を実現することができる。

【0078】

なお、図２９に示すように、部分的未確認応答用（ＮＡＣＫ）のＡＣＫパケットによって再送されたパケットが廃棄されるケースもある。送信端末３０００からパケットＡ〜Ｄが送信され（３００２）、パケットＢが廃棄され、パケットＢをＴＣＰオプションヘッダ２９１６内のｌｅｆｔ＿ｅｄｇｅ＿１（２９１９とｒｉｇｈｔ＿ｅｄｇｅ＿１（２９２０）に記載した部分的未確認応答用（ＮＡＣＫ）のＡＣＫパケット（３００３）によって再送されたパケットＢ（３００４）が再び廃棄されたとする。この場合、受信端末３００１は、例えば２ＲＴＴ待っても再送パケットＢ（３００４）が到達しなければ、再び、パケットＢの再送を要求する部分的未確認応答用（ＮＡＣＫ）のＡＣＫパケット（３００５）を送信する（３００６）。本再送方式は、受信バッファ管理ポインタのｌｅｆｔ／ｒｉｇｈｔ＿ｌｏｓｓ１１０７と関連付けて、図７に示すＡＣＫ返信時刻ａｃｋｅｄ＿ｔｉｍｅ１９０１を記録することで実現する。ＡＣＫ返信時刻ａｃｋｅｄ＿ｔｉｍｅ１９０１と現在時刻との差分が２ＲＴＴを超過したときに、超過した廃棄箇所ｌｅｆｔ／ｒｉｇｈｔ＿ｌｏｓｓ１１０７の再送を要求する部分的未確認応答用（ＮＡＣＫ）のＡＣＫパケットを再送する。

【0079】

図３０には、左側に従来型ＴＣＰの輻輳制御方式を、右側に独自ＴＣＰの輻輳制御方式を示す。従来型ＴＣＰは、パケット廃棄が１回起きただけでも、制御帯域を大幅に減少させる（２８０１）。通信回線では、回線利用率が１００％に到達していなくても、バッファ等において待ち行列理論から導かれる一定の確率で廃棄が生じる（２８０６）。このため、従来型ＴＣＰは、回線利用率が１００％に到達する前に、帯域が減少してしまい（２８０４）、回線帯域を１００％使い切ることが出来ない場合があった。一方、独自ＴＣＰは、廃棄／再送率が一定に推移していれば、待ち行列理論から導かれる一定の確率で廃棄が生じているに過ぎないと判断して帯域を増加させていく。廃棄／再送率が増加し始めたら、例えば回線帯域の使いすぎが発生したと判断して、直近の廃棄／再送帯域と、それよりも１ＲＴＴ前の制御帯域とに基づいて、１ＲＴＴ前の制御帯域よりも小さくなるように制御帯域を減少させる。制御帯域が回線帯域付近で上下するように制御するため、回線帯域を１００％近く使い切ることができる。なお、ここで、送信帯域とは、シェーパ３２０９へパケットを振り分ける振分部３２０８において、シェーパ毎に観測している入力帯域を指す。また、制御帯域とは、シェーパ３２０９からの実際の出力帯域を指す。

【0080】

図３１には、ＮＩＦ１側のＴＣＰモジュール２５０１／２５０２ブロックに実装する独自ＴＣＰを実現するためのブロック図を示す。ＮＩＦ０側のＴＣＰモジュール１００７ブロックに実装する標準ＴＣＰを実現するためのブロック図は、図４と同様のものを用いることができる。まず、標準ＴＣＰを実現するＴＣＰブロック１００７（９１３／９２４）について説明すると、図４に示すように受信処理を行うＲＸ部３１０２と、送信処理を行うＴＸ部３１０１を有する。ＲＸ部３１０２は、受信パケットをＴＣＰ制御パケットとデータ付パケットとＡＣＫ／部分的確認応答用ＳＡＣＫパケットに分離するパケット解析部３１０８と、受信したＴＣＰ制御パケットに基づいて状態テーブル１００１内のＴＣＰ状態１００３を変更するＴＣＰ制御部３１０７と、受信したデータパケットの送信シーケンス番号ＳＥＱ２９１２と受信シーケンス番号ＡＣＫ２９１３とに基づいて、状態テーブル１００１内のバッファ管理ポインタ１００５を変更してＡＣＫパケットや部分的確認応答ＳＡＣＫ付ＡＣＫパケットを返信する受信履歴更新部３１０６、とを有する。受信履歴更新部３１０６のバッファ管理ポインタ１００５の変更では、実施例１に記載の方法を用いる。

【0081】

ＴＸ部３１０１は、状態テーブル１００１内のＴＣＰ状態１００４を用いてＴＣＰ制御パケットを送信するＴＣＰ制御部３１０３と、受信したＡＣＫパケットに基づいて状態テーブル１００１内のバッファ管理ポインタ１００５を変更し、受信した部分的確認応答ＳＡＣＫ付ＡＣＫパケットを用いて送信バッファ１０１５からデータを読み出してパケットを再送するＴＸパケット再送部３１０４と、送信バッファ１０１５からデータを読み出してパケットを送信して、状態テーブル１００１内のバッファ管理ポインタ１００５を変更する送信履歴更新部３１０５と、ＡＣＫ／ＳＡＣＫパケット、ＴＣＰ制御パケット、再送パケット、データパケットをＦＩＦＯで集約して出力するマルチプレクサ３１０９およびバッファ３１１０〜３１１３とを有する。

【0082】

独自ＴＣＰを実現するＴＣＰブロック２５０１／２５０２は、標準ＴＣＰを実現するＴＣＰブロック１００７をベースに、図３１に示すように、ＲＸ部３１０２内の一部のブロックからの出力を変更し、ＴＸ部３１０１内に幾つかのブロックを追加することで実現される。まず、パケット解析部３１０８は、ＡＣＫ／部分的確認応答用ＳＡＣＫパケットを、ＡＣＫ・部分的未確認応答用（ＮＡＣＫ）のＡＣＫパケット３２１０に変更し、ＴＸパケット再送部３１０４に出力する。同様に、受信履歴更新部３１０６のＡＣＫ／部分的確認応答用ＳＡＣＫパケットを、ＡＣＫ・部分的未確認応答用（ＮＡＣＫ）のＡＣＫパケット３２１０に変更し、バッファ３１１０に出力する。ＡＣＫ／ＳＡＣＫパケットをＡＣＫ／ＮＡＣＫパケットに変更し、変更されたパケットを送ることで、ＴＸ部３１０１では、廃棄箇所の即時再送を行うことができる。

【0083】

ＴＸ部３１０１は、図４と異なり、送信パケットと再送パケットのヘッダ情報を用いてどのシェーパに割り振るかを判定するシェーパ判定部３２０１と、コネクション情報毎に宛先シェーパを定めたコネクション・シェーパテーブル３２０２と、シェーパ判定部３２０１の判定結果に基づいてパケットを割り振る振り分け部３２０８と、シェーパＡ〜Ｃ（３２０９）とを有する。この構成により、ＲＴＴ非依存なトークンに基づく帯域制御が可能となる。

【0084】

さらに、ＴＸ部３１０１は、現在時刻を出力するタイマ３２０３と、インターバル時間を定めたインターバル格納部３２０４と、シェーパ毎の送信帯域を制御する送信帯域制御部３２０６と、シェーパ毎に送信帯域や再送帯域の統計情報を記録するシェーパ毎の送信・再送帯域テーブル３２０５と、インターバル時間あたりの送信可能量を制御するトークン更新部３２０７とを追加する構成である。

【0085】

送信帯域制御部３２０６は、シェーパ毎の送信・再送帯域テーブル３２０５記載の制御帯域が変更されると、新たな変更済み制御帯域をトークン更新部３２０７へ通知する。トークン更新部３２０７は、トークンバケツアルゴリズムを用いて、各シェーパ３２０９からパケットが送信可能か否かを判定し、送信可能と判定したシェーパ３２０９からパケットを送信するように集約部３１０９へ指示する。この構成により、再送率に基づく輻輳制御が可能となる。

【0086】

トークンバケツアルゴリズムでは、トークンバケツに単位時間毎に予め定められたトークンが蓄積されていき、送信パケット長に到達するとパケットの送信が許可される。更に、パケット送信と同時に、送信パケット長と同じ分のトークンが、トークンバケツから減らされる。トークン更新部３２０７は、送信帯域制御部３２０６から通知された制御帯域に基づいて、トークンバケツに加算するトークンの値を決定する。以上の、送信帯域制御部３２０６の制御により、図２７のトークンサイズに基づく帯域制御を実現可能となる。

【0087】

図３２には、ＴＣＰコネクション毎に使用するシェーパを定めるためのコネクション・シェーパテーブル３２０２のフォーマットを表す。コネクション・シェーパテーブル３２０２には、送信元ＩＰ／サブネット、宛先ＩＰ／サブネット、送信元ポート番号、及び、宛先ポート番号を含むコネクション情報毎に、対応するシェーパの識別情報を記載する。シェーパ判定部３２０１は受け取ったパケットのＩＰヘッダ記載のＩＰアドレス２９０７／２９０８、ＴＣＰヘッダ記載のポート番号２９１０／２９１１と一致するコネクション情報を持つコネクション・シェーパテーブル３２０２のエントリを探し、そのエントリに記載されたシェーパにパケットが出力されるように振り分け部３２０８へ指示する。

【0088】

図３３には、送信帯域制御部３２０６が制御帯域を更新する際の概念的なフローチャートを表す。処理がスタートすると（ステップ４２０１）、送信帯域制御部３２０６が（以下同じ）、パケット再送率（＝再送帯域／送信帯域）の増加率が一定値を超過したか否かを判定する（ステップ４２０２）。超過した場合は、現在の再送帯域と、昔の制御帯域を用いて、制御帯域を更新する（ステップ４２０３）。超過しなかった場合は、制御帯域を増加させる（ステップ４２０４）。

【0089】

図３４には、シェーパ毎の送信・再送帯域テーブル３２０５のフォーマットを表す。シェーパ毎の送信・再送帯域テーブル３２０５は、シェーパ毎に、旧基準時刻前の送信帯域・制御帯域と、基準時刻前の送信帯域・再送帯域・制御帯域、基準時刻と、基準時刻後の送信ビット積算値・再送ビット積算値・制御帯域とを記録する。送信ビット積算値・再送ビット積算値は、例えば、シェーパにパケットを振り分ける振分部３２０８が送信ビット数、再送ビット数を送信帯域制御部３２０６に通知し、送信帯域制御部３２０６がシェーパ毎の送信・再送帯域テーブル３２０５に書き込むことができる。

【0090】

図３５には、シェーパ毎の送信・再送帯域テーブル３２０５が保持する値の意味を説明するための概念図である。上から下に向かって時間の経過を表す。図３５の４３０１に示すように、基準時刻後の制御帯域は、現在時刻における制御帯域を表す（本実施例では、ｔｏｋｅｎと表す）。基準時刻後の送信帯域は、現在時刻における送信帯域を表し（本実施例では、ｓｎｄと表す）、基準時刻後の送信ビット積算値をインターバルで除算することで求められる。基準時刻後の再送帯域は、現在時刻における再送帯域を表し（本実施例では、ｒｔｓと表す）、基準時刻後の再送ビット積算値をインターバルで除算することで求められる。また、図３５の４３０２に示すように、基準時刻前の制御帯域・送信帯域・再送帯域は、基準時刻の直前まで（現在の基準時刻からインターバル時間前まで）の制御帯域・送信帯域・再送帯域を表す（本実施例では、ｏｌｄ＿ｔｏｋｅｎ、ｏｌｄ＿ｓｎｄ、ｏｌｄ＿ｒｔｓと表す）。また、図３５の４３０３に示すように、現在使用している基準時刻の一つ前に使用していた基準時刻を旧基準時刻と呼び、旧基準時刻前の制御帯域・送信帯域・再送帯域は、旧基準時刻の直前まで（旧基準時刻からさらにインターバル時間前まで。現在の基準時刻からすると２インターバル時間前）の制御帯域・送信帯域・再送帯域を表す（本実施例では、ｏｌｄ＿ｏｌｄ＿ｔｏｋｅｎ、ｏｌｄ＿ｏｌｄ＿ｓｎｄ、ｏｌｄ＿ｏｌｄ＿ｒｔｓと表す）。図３５の４３０２に示すように、基準時刻前の再送率ｏｌｄ＿ｒｔｓ＿ｒａｔｉｏは、ｏｌｄ＿ｒｔｓ／ｏｌｄ＿ｏｌｄ＿ｓｎｄで求められる。また、図３５の４３０１に示すように、基準時刻後の現在の再送率ｒｔｓ＿ｒａｔｉｏは、現在の再送帯域ｒｔｓと、基準時刻前の送信帯域とに基づき、ｒｔｓ／ｏｌｄ＿ｓｎｄで求められる。

【0091】

図３６には、送信帯域制御部３２０６がシェーパ毎の送信・再送帯域テーブル３２０５記載の値を用いて、制御帯域を変更するフローチャート図を表す。処理がスタートすると（ステップ３５０１）、送信帯域制御部３２０６が（以下同じ）、初めにタイマ３２０３の出力する現在時刻と、送信・再送帯域テーブル３２０５記載の基準時刻との差が、インターバル３２０４以上であるか否かを判定する（ステップ３５０２）。インターバルとして、計測したＲＴＴ等を使用してもよい。ステップ３５０２において真と判断された場合、制御帯域（基準時刻後）ｔｏｋｅｎの値をｔｍｐに退避させておく（ステップ３５０３）。更に、再送ビット積算値（基準時刻後）／インターバル／送信帯域（基準時刻前）で求められる再送率（基準時刻後）ｒｔｓ＿ｒａｔｉｏが、再送帯域（基準時刻前）／送信帯域（旧基準時刻前）で求められる旧再送率（基準時刻前）ｏｌｄ＿ｒｔｓ＿ｒａｔｉｏのＫ倍（Ｋ：予め定められた１以上の定数）よりも大きいか否かを判定する（ステップ３５０４）。大きい場合は、再送率が増加していると判断して、制御帯域（基準時刻後）ｔｏｋｅｎの値を、制御帯域（基準時刻前）ｏｌｄ＿ｔｏｋｅｎの値よりも小さくなるように、再送帯域ｒｔｓを用いて減少させる。例えば、制御帯域（基準時刻後）ｔｏｋｅｎ＝制御帯域（基準時刻前）ｏｌｄ＿ｔｏｋｅｎ−再送帯域（基準時刻後）ｒｔｓとする（ステップ３５０５）。ステップ３５０４で偽と判定された場合は、制御帯域（基準時刻後）ｔｏｋｅｎを増加させる（ステップ３５０６）。ステップ３５０５・３５０６が終了すると、送信帯域（基準時刻前）ｏｌｄ＿ｓｎｄ＝送信帯域（基準時刻後）ｓｎｄ、再送帯域（基準時刻前）ｏｌｄ＿ｒｔｓ＝再送帯域（基準時刻後）ｒｔｓ、基準時刻＝基準時刻＋インターバル、送信ビット積算値（基準時刻後）＝０、再送ビット積算値（基準時刻後）＝０、制御帯域（旧基準時刻前）ｏｌｄ＿ｏｌｄ＿ｔｏｋｅｎ＝制御帯域（基準時刻前）ｏｌｄ＿ｔｏｋｅｎ、送信帯域（旧基準時刻前）ｏｌｄ＿ｏｌｄ＿ｓｎｄ＝送信帯域（基準時刻前）ｏｌｄ＿ｓｎｄ、制御帯域（基準時刻前）ｏｌｄ＿ｔｏｋｅｎ＝ｔｍｐ、とし、各値を送信・再送帯域テーブル３２０５に記憶する（ステップ３５０７）。

【0092】

ステップ３５０２で、偽と判定された場合は、ステップ３５０４と同様に、再送ビット積算値（基準時刻後）／インターバル／送信帯域（基準時刻前）で求められる再送率（基準時刻後）ｒｔｓ＿ｒａｔｉｏが、再送帯域（基準時刻前）／送信帯域（旧基準時刻前）で求められる旧再送率（基準時刻前）ｏｌｄ＿ｒｔｓ＿ｒａｔｉｏのＫ倍（Ｋ：予め定められた１以上の定数）よりも大きいか否かを判定する（ステップ３５０８）。大きい場合は、例えば再送率が増加していると判断して、ステップ３５０５と同様に、制御帯域（基準時刻後）ｔｏｋｅｎの値を、制御帯域（基準時刻前）ｏｌｄ＿ｔｏｋｅｎの値よりも小さくなるように、再送帯域ｒｔｓを用いて減少させる。例えば、制御帯域（基準時刻後）ｔｏｋｅｎ＝制御帯域（基準時刻前）ｏｌｄ＿ｔｏｋｅｎ−再送帯域（基準時刻後）ｒｔｓとする（ステップ３５０９）。

【0093】

以上の送信帯域制御部３２０６の制御帯域を更新する方法により、図３０に示す直近の廃棄／再送帯域と、それよりも１ＲＴＴ前の制御帯域とに基づいて、１ＲＴＴ前の制御帯域よりも小さくなるように制御帯域を減少させることが可能となる。制御帯域が回線帯域付近で上下するように更新されるため、回線帯域を１００％近く使い切ることができる。以上記載した手段を用いることで、標準的なＴＣＰ通信しかできない端末間でも、ＲＴＴや廃棄率に依存しない通信を実現することができる。

【実施例4】

【0094】

図３７〜図４０を中心に、上述の実施例の図面を適宜参照して、通信装置を端末間に２台設置し、端末間のＴＣＰ通信を、端末と通信装置間のＴＣＰ通信、通信装置間のＴＣＰ通信、通信装置と端末間のＴＣＰ通信、という３つのＴＣＰ通信に分割して、各通信装置が中継する２つのＴＣＰ通信のうち、端末と通信装置間のＴＣＰ通信では標準ＴＣＰを、通信装置間のＴＣＰ通信では上記特許出願１に記載の又はそれをさらに改良した独自ＴＣＰを用いつつ、実施例１に記載のＡＣＫ返信方法を用いる実施例を説明する。各通信装置が中継する２つのＴＣＰ通信では、送信データの再送と受信データの整列が独立して実行される。

【0095】

本実施例では、図２６に記載のシステム、図３に記載のブロックを備えた通信装置（例えば通信装置）を用い、通信装置のＴＣＰモジュールは、端末側は図４に記載のブロックを備えた標準ＴＣＰモジュールを用い、対向する通信装置側は図３１に記載のブロックを備えた独自ＴＣＰモジュールを用いる（図２６参照）。更に、受信履歴更新部３１０６において、実施例１において図２２、図１４〜図２１、図１８、図１９を用いて説明した手法を用いてバッファ管理ポインタ更新と、ＡＣＫパケット返信を行う。

【0096】

また、図３７に示すように、図１８のフローチャート図が示す処理に対して、ＡＣＫを返信する処理（ステップ３８０６）の前に、ＴＣＰオプションフィールドのｒｉｇｈｔ／ｌｅｆｔ＿ｅｄｇｅ＿１〜４（２９１９〜２９２６）に、管理ポインタｒｉｇｈｔ／ｌｅｆｔ＿ｌｏｓｓ１１０７が指示する廃棄箇所を記載する処理（ステップ４４０１）を追加することで、廃棄箇所を記載した部分的未確認応答（Ｎｅｇａｔｉｖｅ ＡＣＫ（ＮＡＣＫ））用のＡＣＫパケットの返信が実現される。他の各ステップは、図１８と同様であり、同じ符号を付して説明を省略する。

【0097】

更に、図３８に示すように、図１９のフローチャート図が示す処理に対して、送信バッファの管理ポインタを変更する処理（ステップ３９０５）の後で、ＴＣＰオプションフィールドのｒｉｇｈｔ／ｌｅｆｔ＿ｅｄｇｅ＿１〜４（２９１９〜２９２６）に記載されている値を、再送箇所管理ポインタｒｉｇｈｔ／ｌｅｆｔ＿ｒｔｓ１１０８に記載する処理（ステップ４５０１）を追加することで、廃棄箇所を記載した部分的未確認応答（Ｎｅｇａｔｉｖｅ ＡＣＫ（ＮＡＣＫ））用のＡＣＫパケットを受信したときに、廃棄箇所の即時再送が実現される。

【0098】

受信履歴更新部３１０６は、図３７に示すように、図１８のフローチャート図が示す処理に対して、ＡＣＫを返信する処理（ステップ３８０５）の前に、ＴＣＰオプションフィールドのｒｉｇｈｔ／ｌｅｆｔ＿ｅｄｇｅ＿１〜４（２９１９〜２９２６）に、管理ポインタｒｉｇｈｔ／ｌｅｆｔ＿ｌｏｓｓ１１０７が指示する廃棄箇所を記載する処理（ステップ４４０１）を追加することで、廃棄箇所を記載した部分的未確認応答（Ｎｅｇａｔｉｖｅ ＡＣＫ（ＮＡＣＫ））用のＡＣＫパケット返信を実現する。

【0099】

更に、受信履歴更新部３１０６は、廃棄箇所の管理ポインタｒｉｇｈｔ／ｌｅｆｔ＿ｌｏｓｓ１１０７毎に、ＴＣＰオプションフィールドに記載してＡＣＫパケットを返信した時刻を記録しておき、現在時刻とＡＣＫパケットの返信時刻との差が一定時間以上に達するまで、管理ポインタｒｉｇｈｔ／ｌｅｆｔ＿ｌｏｓｓ１１０７をＴＣＰオプションフィールドに記載したＡＣＫパケットを返信しないことで、図２９に示した、一定時間経過しても再送パケットが到着しない場合に、再度、廃棄箇所を記載したＡＣＫパケットを返信することが可能となる。

【0100】

更に、ＴＸパケット再送部３１０４は、図３８に示すように、図１９のフローチャート図が示す処理に対して、送信バッファの管理ポインタを変更する処理（ステップ３９０５）の後で、ＴＣＰオプションフィールドのｒｉｇｈｔ／ｌｅｆｔ＿ｅｄｇｅ＿１〜４（２９１９〜２９２６）に記載されている値を、再送箇所管理ポインタｒｉｇｈｔ／ｌｅｆｔ＿ｒｔｓ１１０８に記載する処理（ステップ４５０１）を追加し、再送箇所管理ポインタｒｉｇｈｔ／ｌｅｆｔ＿ｒｔｓ１１０８に記載された範囲のデータを再送することで、廃棄箇所を記載した部分的未確認応答（Ｎｅｇａｔｉｖｅ ＡＣＫ（ＮＡＣＫ））用のＡＣＫパケットを受信したときに、廃棄箇所を即時再送することが可能となる。以上の受信履歴更新部３１０６と、ＴＸパケット再送部３１０４の制御により、図２８の全廃棄箇所の即時再送が実現可能となる。

【0101】

図３９には、本実施例を用いた場合に、通信装置間の独自ＴＣＰを用いた通信において、ロスセグメントが発生したときに、どのようにポインタが移動し、どのようなＡＣＫパケットが返信されるかの一例を示したシーケンス図を示す。通信装置＃２（３６０２）（上述の通信装置９２０に相当）が通信装置＃１（３６０１）（上述の通信装置９１０に相当）との間の独自ＴＣＰ通信に用いる受信バッファ３６０３のポインタ移動と、通信装置３６０２が受信端末３６０３との間の標準ＴＣＰ通信に用いる送信バッフ３６０４のポインタ移動を示す。

【0102】

通信装置＃２（３６０２）が、通信装置＃１（３６０１）から送信シーケンス番号がｒｉｇｈｔ＿ｒｅｃｖ１１０３よりも大きなデータ付パケット３６０５を受信すると、ｒｉｇｈｔ＿ｒｅｃｖ１１０３を、受信パケットの送信シーケンス番号とデータ長の和に変更して、ｌｅｆｔ＿ｌｏｓｓ[０]をｌｅｆｔ＿ｒｅｃｖ１１０２に、ｒｉｇｈｔ＿ｌｏｓｓ[０]を受信パケットの送信シーケンス番号にしたロスセグメント記録ポインタを新たに作成する（３６０６）。更に、受信シーケンス番号をｐｒｅｖ＿ｌｅｆｔ＿ｒｅｃｖ１１０２にして、ＴＣＰオプションヘッダ２９１６内のｌｅｆｔ＿ｅｄｇｅ＿１（２９１９）とｒｉｇｈｔ＿ｅｄｇｅ＿１（２９２０）に、ｌｅｆｔ＿ｌｏｓｓ[０]とｒｉｇｈｔ＿ｌｏｓｓ［０］の値を記載した（３６０４）部分的未確認応答（Ｎｅｇａｔｉｖｅ ＡＣＫ（ＮＡＣＫ））用のＡＣＫパケット３６０８を通信装置＃１（３６０１）へ送る。その後、更に、通信装置＃２（３６０２）が、通信装置＃１（３６０１）から送信シーケンス番号がｒｉｇｈｔ＿ｒｅｃｖ１１０３よりも大きなデータ付パケット３６０９を受信すると、ｌｅｆｔ＿ｌｏｓｓ[１]をｒｉｇｈｔ＿ｒｅｃｖ１１０３に、ｒｉｇｈｔ＿ｌｏｓｓ[１]を受信パケットの送信シーケンス番号にしたロスセグメント記録ポインタを新たに作成して、ｒｉｇｈｔ＿ｒｅｃｖ１１０３を、受信パケットの送信シーケンス番号とデータ長の和に変更する（３６１０）。更に、受信シーケンス番号をｐｒｅｖ＿ｌｅｆｔ＿ｒｅｃｖ１１０２にして、ＴＣＰオプションヘッダ２９１６内のｌｅｆｔ＿ｅｄｇｅ＿１（２９１９）とｒｉｇｈｔ＿ｅｄｇｅ＿１（２９２０）に、ｌｅｆｔ＿ｌｏｓｓ[１]とｒｉｇｈｔ＿ｌｏｓｓ[１]の値を記載した（３６０５）部分的未確認応答ＮＡＣＫ用のＡＣＫパケット３６１２を通信装置＃１（３６０１）へ送る。その後、通信装置＃２（３６０２）が、送信シーケンス番号がｌｅｆｔ＿ｒｅｃｖ１１０２と等しく、送信シーケンス番号とデータ長の和がｒｉｇｈｔ＿ｌｏｓｓ[０]と等しいデータ付再送パケット３６１３を、通信装置＃１（３６０１）から受信すると、ｌｅｆｔ＿ｒｅｃｖ１１０２をｌｅｆｔ＿ｌｏｓｓ[１]の所まで移動させて、ロスセグメント記録用ポインタｌｅｆｔ＿ｌｏｓｓ[０]とｒｉｇｈｔ＿ｌｏｓｓ[０]を初期化して無くして（３６１４）、受信シーケンス番号をｐｒｅｖ＿ｌｅｆｔ＿ｒｅｃｖ１１０２にした確認応答用のＡＣＫパケット３６１８を通信装置＃１（３６０１）へ送る。ｌｅｆｔ＿ｒｅｃｖ１１０２がｌｅｆｔ＿ｒｂｕｆ１１０１よりも大きくなると、ｌｅｆｔ＿ｒｂｕｆ１１０１からｌｅｆｔ＿ｒｅｃｖ１１０２まで書かれているデータを、ｒｉｇｈｔ＿ｓｂｕｆ１１０６を先頭に送信バッファ３６１５へ移動させて（３６１６）、ｌｅｆｔ＿ｒｂｕｆ１１０１とｒｉｇｈｔ＿ｓｂｕｆ１１０６を、移動させたデータサイズ分、右側へ移動させる（３６１７、３６１９）。

【0103】

図４０には、本実施例を用いた場合に、通信装置＃１（３６００）が通信装置＃２（３６０２）からＮＡＣＫを受信したときに、どのようにポインタが移動するかを示したシーケンス図を示す。通信装置＃１（３６００）が送信端末３６０１との間のＴＣＰ通信に用いる受信バッファ３６０３のポインタ移動と、通信装置＃１（３６００）が通信装置＃２（３６０２）との間の独自ＴＣＰ通信に用いる送信バッファ３６０４のポインタ移動を示す。

【0104】

通信装置＃１（３６００）が、すでにある程度の量のデータを通信装置＃２（３６０２）へ送っており、ｒｉｇｈｔ＿ｓｂｕｆ１１０６とｒｉｇｈｔ＿ｓｅｎｄ１１０５が等しく、ｒｉｇｈｔ＿ｓｅｎｄ１１０５がｌｅｆｔ＿ｓｅｎｄ１１０４よりも大きいときを初期状態とする（３６０４）。通信装置＃１（３６００）が、通信装置＃２（３６０２）から、受信シーケンス番号がｌｅｆｔ＿ｓｅｎｄ１１０４よりも大きくｒｉｇｈｔ＿ｓｅｎｄ１１０５よりも小さな確認応答用のＡＣＫパケット３６０５を受信すると、ｌｅｆｔ＿ｓｅｎｄ１１０４の値がＡＣＫパケット３６０５記載の受信シーケンス番号ＡＣＫに変更される（３６０６）。更に、受信シーケンス番号がｌｅｆｔ＿ｓｅｎｄ１１０４の値と等しく、尚且つ、受信シーケンス番号がＡＣＫパケット３６０５と等しく、ＴＣＰオプションヘッダ２９１６内のｌｅｆｔ＿ｅｄｇｅ＿１（２９１９）にｌｅｆｔ＿ｓｅｎｄ１１０４の値を記載し、ＴＣＰオプションヘッダ２９１６内のｒｉｇｈｔ＿ｅｄｇｅ＿１（２９２０）にｌｅｆｔ＿ｓｅｎｄ１１０４よりも大きくｒｉｇｈｔ＿ｓｅｎｄ１１０５よりも小さな値を記載した（３６１１）部分的未確認応答ＮＡＣＫ用の重複ＡＣＫパケット（３６０７）を受信すると、ｌｅｆｔ＿ｒｔｓ[０]をｌｅｆｔ＿ｅｄｇｅ＿１（２９１９）に、ｒｉｇｈｔ＿ｒｔｓ[０]をｒｉｇｈｔ＿ｅｄｇｅ＿１（２９２０）にした再送セグメント記録ポインタを新たに作成する（３６０８）。通信装置＃１（３６００）は、再送セグメントが作成されると、ｌｅｆｔ＿ｒｔｓ[０]からｒｉｇｈｔ＿ｒｔｓ[０]までのデータを再送して（３６０９）、再送セグメント記録ポインタを初期化して消去する（３６１０）。

【0105】

上記に記載の手段を用いることで、標準的なＴＣＰ通信しかできない端末間でも、ＲＴＴや廃棄率に依存しない通信を実現することが出来、尚且つ、通信装置のいずれか一方が故障しても、送信端末では送信が完了している一方で、受信端末では受信が完了していない、というケースを発生させなくすることが可能となる。
［変形例］
以下、図４２ないし図４８を用いて図３０ないし図３６に関連する通信装置の送信制御部における帯域制御に関する他の変形例を説明する。以下、送信帯域制御部３２０６が、所定の期間内における現時点における再送状況と、過去の所定の期間内における送信状況、特に再送状況とに基づいて、シェーパー毎のバッファ３２０９や再送用のバッファ３１１０に保持されるパケットをネットワークに送出する量である制御帯域を増減する量を制御する例である。

【0106】

図４２は、シェーパ毎の送信・再送帯域テーブル３２０５が保持する値の意味を説明するための図３５の変形例である。上から下に向かって時間の経過を表す。図４２の４２０１と４２０２に示すように、基準時刻後の制御帯域は、現在時刻における制御帯域に対応し（本実施例では、ｔｏｋｅｎと表す）。基準時刻後の送信帯域は、現在時刻における送信帯域（本実施例では、ｓｎｄと表す）に対応する。送信帯域制御部３２０６は、基準時刻後の送信ビット積算値を現在時刻と基準時刻の差で除算することで求める場合と（４２０２）、基準時刻後の送信ビット積算値をインターバルで除算した値に、基準時刻後の送信帯域ｏｌｄ＿ｓｎｄに１−（現在時刻−基準時刻）／インターバルを乗算した値を加算することで求める場合がある（４２０１）。

【0107】

基準時刻後の再送帯域は、現在時刻における再送帯域に対応する（本実施例では、ｒｔｓと表す）。この場合は、送信帯域制御部３２０６は、基準時刻後の再送ビット積算値を現在時刻と基準時刻の差で除算することで求める場合と（４２０２）、基準時刻後の再送ビット積算値をインターバルで除算した値に、基準時刻後の再送帯域ｏｌｄ＿ｒｔｓに１−（現在時刻−基準時刻）／インターバルを乗算した値を加算することで求める場合がある（４２０１）。また、図４２の４２０３に示すように、基準時刻前の制御帯域・送信帯域・再送帯域は、基準時刻の直前まで（現在の基準時刻からインターバル時間前まで）の制御帯域・送信帯域・再送帯域に対応する（本実施例では、ｏｌｄ＿ｔｏｋｅｎ、ｏｌｄ＿ｓｎｄ、ｏｌｄ＿ｒｔｓと表す）。

【0108】

また、図４２の４２０４に示すように、現在使用している基準時刻の一つ前に使用していた基準時刻を旧基準時刻と呼び、旧基準時刻前の制御帯域・送信帯域・再送帯域は、旧基準時刻の直前まで（旧基準時刻からさらにインターバル時間前まで。現在の基準時刻からすると２インターバル時間前）の制御帯域・送信帯域・再送帯域に対応する（本実施例では、ｏｌｄ＿ｏｌｄ＿ｔｏｋｅｎ、ｏｌｄ＿ｏｌｄ＿ｓｎｄ、ｏｌｄ＿ｏｌｄ＿ｒｔｓと表す）。図４２の４２０３に示すように、基準時刻前の再送率ｏｌｄ＿ｒｔｓ＿ｒａｔｉｏは、ｏｌｄ＿ｒｔｓ／ｏｌｄ＿ｏｌｄ＿ｓｎｄで求められる。また、図４２の４２０１または４２０２に示すように、基準時刻後の現在の再送率ｒｔｓ＿ｒａｔｉｏは、現在の再送帯域ｒｔｓと、基準時刻前の送信帯域とに基づき、ｒｔｓ／ｏｌｄ＿ｓｎｄで求められる。現在時刻から基準時刻までを１区間前、基準時刻から旧基準時刻までを２区間前、旧基準時刻以前を３区画前、と区別する。インターバルには、計測したＲＴＴを使用してもよいし、固定値を用いてもよい。

【0109】

図４３、４４等を用いて、図３３の変形例として、送信帯域制御部３２０６が、１区間前の再送帯域と、２区間前以上前の帯域の使用状況と、に基づいて、制御帯域を増減する制御をする例を示す。図４３には、送信帯域制御部３２０６がシェーパ毎の送信・再送帯域テーブル３２０５記載の値を用いて、制御帯域を更新する例を示す。処理がスタートすると（ステップ４３０１）、送信帯域制御部３２０６が（以下同じ）、１区間前のパケット再送帯域ｒｔｓが閾値を超過したか否かを判定する（ステップ４３０２）。超過した場合は、送信帯域制御部３２０６は、１区間前の再送帯域と、２区間以上前の送信/制御帯域を用いて、制御帯域を減少させる（ステップ４３０３）。ステップ４３０３の結果、通信装置から、一のシェーパーに対応するＷＡＮ側へのＴＸ部３１０１からのデータ流出量は、減少する。

【0110】

一方、超過しなかった場合は、ステップ４３０４に進み、送信帯域制御部３２０６は、制御帯域を増加させる制御を行う。はじめに、一定期間、再送帯域の閾値超過が無いか否かを判定する（ステップ４３０４）。例えば、一定期間とは、過去における２区間以上前の所定の一又は複数の区間に対応する。過去における所定の区間毎の再送帯域は、図３４に示す送信再送帯域テーブル３２０５に、旧基準時刻前の再送帯域の欄を、区間ごとに設け、送信帯域制御部３２０６は、再送状況を管理する。ステップ４３０４では、送信帯域制御部３２０６は、旧基準時刻前の再送帯域の欄の所定の一以上の区間の再送帯域の情報を参照し、一定期間、再送帯域の閾値超過が無いか否かを判定する。この場合は、ステップ４３０２における閾値と、ステップ４３０６における閾値は異なってもよい。

【0111】

または、ステップ４３０３において最後に帯域減少させた時刻として保持しておき、送信帯域制御部は、最後に帯域減少させた時刻と、現時刻とを比較して、所定の期間経過したかを判定してもよい。帯域減少させる処理（ステップ４３０３）は、図４３の処理時点で、再送帯域が閾値を超えていた場合に行われるため、帯域減少させた時刻を送信再送帯域テーブルに保持しておくことで、ステップ４３０２の閾値と同じ情報を用いて、ステップ４３０４の判定をすることができる。

【0112】

ステップ４３０４の結果、ＹＥＳの場合、送信帯域制御部３２０６は、制御帯域を指数的に増加させる（ステップ４３０５）。ステップ４３０５の結果、通信装置から、一のシェーパーに対応するＷＡＮ側へのＴＸ部３１０１からのデータ流出量は、増加する。一方、ＮＯの場合は、送信帯域制御部３２０６は、制御帯域を線形的に増加させる（４３０６）。ステップ４６０５，あるいは４６０６により増加された新たな制御帯域に基づいて、各シェーパー毎のバッファ３２０９に保持されるパケットを、ネットワークへ送出する。

【0113】

ステップ４３０６による帯域の増加は、ステップ４３０５における帯域の増加よりも、緩やかな増加の制御となり、通信装置から一のシェーパーに対応するＷＡＮ側へのＴＸ部３１０１からのデータ流出量は、ステップ４３０５より比べ緩やかに増加する。ステップ４３０４〜４３０６により、再送帯域が閾値を下回ってから一定時間経つまでは、他通信との競合が発生する可能性があると判断し、線形的にゆっくりと帯域を増加させる。一方、再送帯域が閾値を下回っている状態が一定時間続くと、他通信との競合が発生していないと判断し、指数的に急激に帯域を増加させる。このように、２区間前以上の一定期間の再送の発生状況により、制御帯域の増加する割合を制御することにより、他の通信帯域を圧迫しないような帯域制御が可能となる。

【0114】

なお、ステップ４３０５とステップ４３０６の帯域の増加のさせ方は、指数的な増加、線形的な増加に限定されない。例えば、ステップ４３０２の結果、一定期間における再送帯域が閾値以下の場合に増加させる制御帯域量が、一定期間における再送帯域が閾値を超過した場合に増加させる制御帯域量の２倍や３倍としてもよい。つまり、ステップ４３０５と４３０６では、送信帯域制御部３２０６は、制御帯域を増加させる場合、２区間以上前の再送帯域に基づいて、制御帯域の増加量を制御し、過去の再送帯域が一定期間、閾値を下回っている場合に比べ、閾値に達した場合の制御帯域の増加量を抑える。また、送信帯域制御部３２０６は、一定期間における再送帯域が閾値を上回った回数によって、帯域の増加を緩やかにするか急にするかを制御してもよい。また、送信帯域制御部は、一定期間、帯域を減少させた回数によって、帯域の増加を緩やかにするか急にするかを制御してもよい。図４３に示す処理により、２区間以上に亘る送信／制御／再送帯域に基づく帯域制御と、他の通信帯域を圧迫しないような帯域制御の共存が可能となる。

【0115】

図４４には、図４３をより詳細に説明した、送信帯域制御部３２０６がシェーパ毎の送信・再送帯域テーブル３２０５記載の値を用いて、制御帯域を設定する際のフローチャート図を表す。処理がスタートすると（ステップ４４０１）、送信帯域制御部３２０６が（以下同じ）、基準時刻後の再送帯域ｒｔｓが、予め定めた閾値ｔｈｒ＿Ｒよりも大きいか否かを判定する（ステップ４４０２）。大きい場合、送信帯域制御部３２０６は、基準時刻前の制御帯域ｏｌｄ＿ｔｏｋｅｎよりも小さくなるように、基準時刻後の再送帯域ｒｔｓを用いて、新たな制御帯域（基準時刻後）ｔｏｋｅｎを決定する（ステップ４４０８）。例えば、ｏｌｄ＿ｔｏｋｅｎ−ｒｔｓを新たな制御帯域（基準時刻後）ｔｏｋｅｎとする（ステップ４４０８）。ステップ４４０２にて否と判定した場合、送信帯域制御部３２０６は、現在時刻と基準時刻との差がインターバル以上か否かを判定する（ステップ４４０３）。否の場合は、ステップ４４０２に戻る。

【0116】

ステップ４４０３にて真と判定した場合、送信帯域制御部３２０６は、制御帯域（基準時刻後）ｔｏｋｅｎの値をｔｍｐに退避させておく（ステップ４４０４）。その後、送信帯域制御部３２０６は、制御帯域（基準時刻後）ｔｏｋｅｎを増加させる。一定期間、送信帯域制御部３２０６は、再送帯域の閾値超過が無いか否かを判定する（ステップ４４０５）。ＹＥＳの場合は、送信帯域制御部３２０６は、制御帯域を指数的に増加させる（ステップ４４１０）。ＮＯの場合は、送信帯域制御部３２０６は、制御帯域を線形的に増加させる（ステップ４４０９）。

【0117】

その後、送信帯域制御部３２０６は、制御帯域（旧基準時刻前）ｏｌｄ＿ｏｌｄ＿ｔｏｋｅｎ＝制御帯域（基準時刻前）ｏｌｄ＿ｔｏｋｅｎ、制御帯域（基準時刻前）ｏｌｄ＿ｔｏｋｅｎ＝ｔｍｐ、とし、各値を送信・再送帯域テーブル３２０５に記憶する（ステップ４４０６）。ステップ４４０６またはステップ４４０８を実施した後、送信帯域制御部３２０６は、送信帯域（旧基準時刻前）ｏｌｄ＿ｏｌｄ＿ｓｎｄ＝送信帯域（基準時刻前）ｏｌｄ＿ｓｎｄ、送信帯域（基準時刻前）ｏｌｄ＿ｓｎｄ＝送信帯域（基準時刻後）ｓｎｄ、再送帯域（基準時刻前）ｏｌｄ＿ｒｔｓ＝再送帯域（基準時刻後）ｒｔｓ、基準時刻＝基準時刻＋インターバル、送信ビット積算値（基準時刻後）＝０、再送ビット積算値（基準時刻後）＝０、基準時刻＝現在時刻として、各値を送信・再送帯域テーブル３２０５に記憶する（ステップ４４０７）。ステップ４４０７の後、ステップ４４０２に戻る。ステップ４４０５と４４０９と４４１０により、再送帯域が閾値を下回ってから一定時間経つまでは、他通信との競合が発生する可能性があると判断し、線形的にゆっくりと帯域を増加させる。一方、再送帯域が閾値を下回っている状態が一定時間続くと、他通信との競合が発生していないと判断し、指数的に急激に帯域を増加させる。これにより、他の通信帯域を圧迫しないような帯域制御が可能となる。更に、図４４に示す処理により、２区間以上に亘る送信／制御／再送帯域に基づく帯域制御と、他の通信帯域を圧迫しないような帯域制御の共存が可能となる。

【0118】

図４５、４６、４７を用いて、送信帯域制御部３２０６が、複数の区間における再送率の変化率に基づいて、制御帯域を制御する例を説明する。図４５には、図３３の変形例として、送信帯域制御部３２０６がシェーパ毎の送信・再送帯域テーブル３２０５記載の値を用いて、制御帯域を更新する処理を表す。処理がスタートすると（ステップ４５０１）、送信帯域制御部３２０６が（以下同じ）、パケット再送率の変化率（ｒｔｓ＿ｒａｔｉｏ／ｏｌｄ＿ｒｔｓ＿ｒａｔｉｏ）が閾値を超過したか否かを判定する（ステップ４５０２）。超過した場合は、１区間前の再送帯域と、２区間以上前の送信/制御帯域を用いて、制御帯域を減少させる（ステップ４５０３）。超過しなかった場合は、制御帯域を増加させる（ステップ４５０４）。これにより、２区間以上に亘る送信／制御／再送帯域、および再送率の変化率に基づく、帯域制御が可能となる。

【0119】

図４６には、図４５の変形例として、送信帯域制御部３２０６がシェーパ毎の送信・再送帯域テーブル３２０５記載の値を用いて、制御帯域を更新する際、特に帯域を増加させる場合を中心に、フローチャート図を用いて説明する。処理がスタートすると（ステップ４６０１）、ステップ４６０２、４６０３は、図４５のステップ４５０２及び４５０３に対応する。ステップ４６０２の結果、パケットの再送率の変化率（ｒｔｓ_ｒａｔｉｏ／ｏｌｄ＿ｒｔｓ＿ｒａｔｉｏ）が閾値を超過しなかった場合は、送信帯域制御部３２０６は、過去の一定期間、再送率の変化率の閾値超過が無いか否かを判定する（ステップ４６０４）。

【0120】

これは、ステップ４６０３で、送信帯域制御部３２０６は、最後に帯域減少させた時刻として保持しておき、送信帯域制御部３２０６は、最後に帯域減少させた時刻と、現時刻とを比較して、所定の期間経過したかを判定してもよい。帯域減少させる処理（ステップ４６０３）は、図４６の処理時点で、再送帯域が閾値を超えていた場合に行われるため、帯域減少させた時刻を管理しておくことで、ステップ４６０２の閾値と同じ情報を用いて、ステップ４６０４の判定をすることができる。

【0121】

あるいは、一定期間とは、過去における２区間以上前の所定の一又は複数の区間に対応する。過去における所定の区間毎の再送帯域は、図３４に示す送信再送帯域テーブル３２０５に、パケット再送率の欄を過去の区間ごとに設け、送信帯域制御部３２０６は、パケット再送の変化率を管理してもよい。ステップ４６０４では、送信帯域制御部３２０６は、送信再送帯域管理テーブル３２０５を参照し、一定期間における再送の変化率が閾値を超過していないか判定する。この場合、ステップ４６０４の閾値とステップ４６０２の閾値は異なる値でもよい。

【0122】

一定期間、再送率の変化率の閾値超過が無い場合は、送信帯域制御部３２０６は、制御帯域を指数的に増加させる（ステップ４６０６）。ステップ４６０４にて否と判定した場合は、送信帯域制御部３２０６は、制御帯域を線形増加させる（ステップ４６０５）。ステップ４６０５，及び４６０６により増加させた場合、新たな制御帯域を、テーブル３２０５に格納し、新たな制御帯域に基づいて、各シェーパー毎のバッファ３２０９に保持されるパケットを、ネットワークに送出する。

【0123】

図４３のステップ４３０５や４３０６と同様に、ステップ４６０６による帯域の増加は、ステップ４６０５における帯域の増加よりも、緩やかな増加の制御となり、ステップ４６０６の結果、通信装置から、一のシェーパーに対応するＷＡＮ側へのＴＸ部３１０１からのデータ流出量は、ステップ４６０５より比べ緩やかに増加する。これにより、２区間以上に亘る送信／制御／再送帯域、および再送率の変化率に基づく帯域制御と、他の通信帯域を圧迫しないような帯域制御を共存させることが可能となる。つまり、廃棄率の増加率が閾値を下回ってから一定時間経つまでは、他通信との競合が発生する可能性があると判断し、線形的にゆっくりと帯域を増加させる。一方、廃棄率の増加率が閾値を下回っている状態が一定時間続くと、他通信との競合が発生していないと判断し、指数的に急激に帯域を増加させる。これにより、他の通信帯域を圧迫しないような帯域制御が可能となる。

【0124】

図４３と同様に図４６も、２区間前以上の一定期間の再送の発生状況により、制御帯域の増加する割合を制御することにより、他の通信帯域を圧迫しないような帯域制御が可能となる。なお、ステップ４６０５とステップ４６０６の帯域の増加のさせ方は、指数的な増加、線形的な増加に限定されない。例えば、ステップ４６０２の結果、一定期間における再送の変化率が閾値以下の場合に増加させる制御帯域量が、一定期間における再送の変化率が閾値を超過した場合に増加させる制御帯域量の２倍や３倍としてもよい。つまり、ステップ４３０５と４３０６では、送信帯域制御部３２０６は、制御帯域を増加させる場合、２区間以上前の再送率の変化率に基づいて、制御帯域の増加量を制御し、過去の再送率の変化率が一定期間、閾値を下回っている場合に比べ、閾値に達した場合の制御帯域の増加量を抑えるようにしてもよい。送信帯域制御部３２０６は、ステップ４６０４の代わりに一定期間における再送率の変化率が閾値を上回った回数によって、帯域の増加を緩やかにするか急にするかを判定してもよい。

【0125】

図４７には、図４６の具体的な例として、送信帯域制御部３２０６が制御帯域を更新する処理を示す。処理がスタートすると（ステップ４７０１）、送信帯域制御部３２０６が（以下同じ）、初めにタイマ３２０３の出力する現在時刻と、送信・再送帯域テーブル３２０５記載の基準時刻との差が、インターバル３２０４以上であるか否かを判定する（ステップ４７０２）。インターバルには、計測したＲＴＴを用いてもよいし、予め定めた値を用いても良い。ステップ４７０２において真と判断された場合、送信帯域制御部３２０６は、制御帯域（基準時刻後）ｔｏｋｅｎの値をｔｍｐに退避させておく（ステップ４７０３）。更に、再送率（基準時刻後）ｒｔｓ＿ｒａｔｉｏが、旧再送率（基準時刻前）ｏｌｄ＿ｒｔｓ＿ｒａｔｉｏのＫ倍（Ｋ：予め定められた１以上の定数）よりも大きいか否かを判定する（ステップ４７０４）。大きい場合は、送信帯域制御部３２０６は、再送率が増加していると判断して、制御帯域（基準時刻後）ｔｏｋｅｎの値を、制御帯域（基準時刻前）ｏｌｄ＿ｔｏｋｅｎの値よりも小さくなるように、再送帯域ｒｔｓを用いて減少させる。例えば、制御帯域（基準時刻後）ｔｏｋｅｎ＝制御帯域（基準時刻前）ｏｌｄ＿ｔｏｋｅｎ−再送帯域（基準時刻後）ｒｔｓとする（ステップ４７０５）。更に、最後に帯域減少させた時刻としてｄｅｃ＿ｔｉｍｅに現在時刻を代入しておく（ステップ４７０６）。

【0126】

ステップ４７０４で偽と判定された場合は、送信帯域制御部３２０６は、制御帯域（基準時刻後）ｔｏｋｅｎを線形的にまたは指数的に増加させる。現在時刻と、最後に帯域減少させた時刻ｄｅｃ＿ｔｉｍｅの差が、予め定めた閾値Ｔよりも大きいか否かを判定する（ステップ４７０８）。Ｔは、ＲＴＴとｔｏｋｅｎに比例する動的変数値としてもよい。ステップ４７０８にて真と判定した場合は、ｔｏｋｅｎを指数的に増加させる（ステップ４７０９）。たとえば、予め定めた値Ｅを用いて、ｔｏｋｅｎ＝Ｅ＊ｔｏｋｅｎとしてもよい（ステップ４７０９）。Ｅは、ｔｏｋｅｎによって定まる値としてもよい。ステップ４７０８にて偽と判定した場合は、ｔｏｋｅｎを線形的に増加させる（ステップ４７１０）。たとえば、予め定めた値Ｌを用いて、ｔｏｋｅｎ＝ｔｏｋｅｎ＋Ｌ＊ＭＳＳ／ＲＴＴとしてもよい（ステップ４７１０）。ＭＳＳはＭａｘｉｍｕｍ Ｓｅｇｍｅｎｔ Ｓｉｚｅである。ステップ４７０６、４７０９、４７１０が終了したら、送信帯域（旧基準時刻前）ｏｌｄ＿ｏｌｄ＿ｓｎｄ＝送信帯域（基準時刻前）ｏｌｄ＿ｓｎｄ、送信帯域（基準時刻前）ｏｌｄ＿ｓｎｄ＝送信帯域（基準時刻後）ｓｎｄ、再送帯域（基準時刻前）ｏｌｄ＿ｒｔｓ＝再送帯域（基準時刻後）ｒｔｓ、基準時刻＝基準時刻＋インターバル、送信ビット積算値（基準時刻後）＝０、再送ビット積算値（基準時刻後）＝０、制御帯域（旧基準時刻前）ｏｌｄ＿ｏｌｄ＿ｔｏｋｅｎ＝制御帯域（基準時刻前）ｏｌｄ＿ｔｏｋｅｎ、制御帯域（基準時刻前）ｏｌｄ＿ｔｏｋｅｎ＝ｔｍｐ、とし、各値を送信・再送帯域テーブル３２０５に記憶する（ステップ４７０７）。

【0127】

ステップ４７０２で、偽と判定された場合は、ステップ４７０４と同様に、送信帯域制御部３２０６は、再送率（基準時刻後）ｒｔｓ＿ｒａｔｉｏが、旧再送率（基準時刻前）ｏｌｄ＿ｒｔｓ＿ｒａｔｉｏのＫ倍（Ｋ：予め定められた１以上の定数）よりも大きいか否かを判定する（ステップ４７１１）。大きい場合は、例えば再送率が増加していると判断して、ステップ３５０５と同様に、制御帯域（基準時刻後）ｔｏｋｅｎの値を、制御帯域（基準時刻前）ｏｌｄ＿ｔｏｋｅｎの値よりも小さくなるように、再送帯域ｒｔｓを用いて減少させる。例えば、制御帯域（基準時刻後）ｔｏｋｅｎ＝制御帯域（基準時刻前）ｏｌｄ＿ｔｏｋｅｎ−再送帯域（基準時刻後）ｒｔｓとする（ステップ４７１２）。ステップ４７１２が終了したら、ステップ４７０２に戻る。 以上により、２区間以上に亘る送信／制御／再送帯域、および再送率の変化率に基づく帯域制御と、他の通信帯域を圧迫しないような帯域制御を共存させることが可能となる。

【0128】

図４６及び４７によると、送信帯域制御部３２０６は、第一の期間内における現時点で設定されている制御帯域に基づいて、ＴＸ部３１０１から送出されるパケットに占める再送パケットの再送率の変化率を監視する。その監視結果、所定の閾値に達した場合、送出されるパケットの量を減少させるために、制御帯域を小さくし、その制御帯域に従ってバッファ３２０９からパケットを読み出す。また、監視結果、再送率の変化率が、所定の時間経過後、閾値に達しなかった場合、送信帯域制御部３２０６は、送出されるパケットの量を増加させるために制御帯域を大きくし、その制御帯域に従って、その制御帯域に従ってバッファ３２０９からパケットを読み出す。また、制御帯域を大きくする場合、送信帯域制御部３２０６は、過去の第一の期間ごとの制御帯域の遷移に基づいて、どの程度大きくするかを制御する。例えば、制御帯域が減少された時点と現在の時刻との期間が、第一の期間よりも大きく、あらかじめ設けられた期間を経過している場合は、していない場合に比べて、増加させる量を制御する。

【0129】

図４３ないし図４７によると、送信帯域制御部３２０６は、ＲＴＴ等に対応するインターバル毎にＴＸ部３１０１から送出されるパケットの量を制限するための制御帯域を更新する。送信帯域制御部は、再送パケットの送出に応じて、インターバルである第一の期間ごとに再送状況を監視し、再送状況に基づいて、制御帯域を増減すべきかを判断する。監視対象となる再送状況は、例えば、第一の期間で発生した再送パケットの量に対応する再送帯域や、第一の期間で発生した再送パケットの量が、監視した時点を含む第一の期間よりも前の期間で発生した再送パケットの量との比較したものが対象となる。制御帯域を減少させる場合、送信帯域制御部３２０６は、監視した時点を含む第一の期間よりも、過去の送信状況、再送状況や設定されていた制御帯域に基づいて、減少させる帯域量を決定し、制御帯域を減少させる。

【0130】

一方、制御帯域を増加させる場合、送信帯域制御部３２０６は、制御帯域を減少させた時点と現時点との間隔をみて、間隔が長い場合のときは、短い場合に比べて増加させる制御帯域の量大きくする、制御を行う。以上の構成や処理により、通信装置は、第一の期間における再送状況と、過去の送信状況によって、きめ細やかな帯域制御を行うことができる。また、帯域の増減をきめ細やかに行うことで、他の通信帯域への圧迫を防ぐことができる。

【0131】

また、以上の送信帯域制御部３２０６の制御帯域を更新する方法により、現時点の第一の期間における再送帯域と、それより以前の第一の期間、例えば、１ＲＴＴ前の制御帯域野菜層帯域とに基づいて、１ＲＴＴ前の制御帯域よりも小さくなるように制御帯域を減少させ、あるいは、増加させることが可能となる。制御帯域が回線帯域付近で上下するように更新されるため、回線帯域を有効に使うことができる。

【0132】

以下、図４８ないし５３を用いて、図９に関係するデータ通信を行う通信装置間を中心にシーケンス図を説明する。図４８は、図９に示すデータ通信を行う前に、ＴＣＰコネクションを確立するためのシーケンス図を示す。はじめに、送信端末１０３と通信装置＃１ １００との間で、ＳＹＮ４８０１、ＳＹＮ−ＡＣＫ４８０２、ＡＣＫ４８０３のやり取りを行いコネクションを確立する。次に、通信装置＃１ １００と通信装置＃２ １０１との間で、ＳＹＮ４８０４、ＳＹＮ−ＡＣＫ４８０５、ＡＣＫ４８０６のやり取りを行いコネクションを確立する。最後に、通信装置＃２ １０１と受信端末１０４との間で、ＳＹＮ４８０７、ＳＹＮ−ＡＣＫ４８０８、ＡＣＫ４８０９のやり取りを行いコネクションを確立する。送信端末１０３は、送信端末１０３と通信装置＃１ １００との間で、コネクションが確立した後に、図９と同様にデータ送信を開始する。

【0133】

図４９は、図９に示すデータ通信を行う前に、ＴＣＰコネクションを確立するための別のシーケンス図を示す。送信端末１０３から、通信装置＃１ １００と通信装置＃２ １０１を経由して、受信端末１０４に向けて、ＳＹＮ（４９０１、４９０４、４９０７）が送られる。次に、受信端末１０４から、通信装置＃２ １０１と通信装置＃１ １００を経由して、送信端末１０３に向けて、ＳＹＮ−ＡＣＫ（４９０８、４９０５、４９０２）が送られる。最後に、送信端末１０３から、通信装置＃１ １００と通信装置＃２ １０１を経由して、受信端末１０４に向けて、ＡＣＫ（４９０３、４９０６、４９０９）が送られる。この後、送信端末１０３は、図９と同様にデータ送信を開始する。

【0134】

図５０は、図９に示すデータ通信を行う前に、ＴＣＰコネクションを確立するための別のシーケンス図を示す。送信端末１０３から、通信装置＃１ １００と通信装置＃２ １０１を経由して、受信端末１０４に向けて、ＳＹＮ（５００１、５００４、５００７）が送られる。次に、受信端末１０４から、通信装置＃２ １０１と通信装置＃１ １００を経由して、送信端末１０３に向けて、ＳＹＮ−ＡＣＫ（５００８、５００５、５００２）が送られる。通信装置＃２ １０１は、ＳＹＮ−ＡＣＫ５００８を受け取ると、ＡＣＫ５００９を返信する。通信装置＃１ １００は、ＳＹＮ−ＡＣＫ５００５を受け取ると、ＡＣＫ５００６を返信する。送信端末１０３は、ＳＹＮ−ＡＣＫ５００２を受け取ると、ＡＣＫ５００３を返信する。その後、送信端末１０３は、図９と同様にデータ送信を開始する。

【0135】

図５１は、図９に示すデータ通信を行った後に、ＴＣＰコネクションを切断するためのシーケンス図を示す。はじめに、送信端末１０３と通信装置＃１ １００との間で、ＦＩＮ５１０１、ＦＩＮ−ＡＣＫ５１０２、ＡＣＫ５１０３のやり取りを行い、コネクションを切断する。次に、通信装置＃１ １００と通信装置＃２ １０１との間で、ＦＩＮ５１０４、ＦＩＮ−ＡＣＫ５１０５、ＡＣＫ５１０６のやり取りを行い、コネクションを確立する。最後に、通信装置＃２ １０１と受信端末１０４との間で、ＦＩＮ５１０７、ＦＩＮ−ＡＣＫ５１０８、ＡＣＫ５１０９のやり取りを行いコネクションを切断する。

【0136】

図５２は、図９に示すデータ通信を行った後に、ＴＣＰコネクションを切断するための別のシーケンス図を示す。送信端末１０３から、通信装置＃１ １００と通信装置＃２ １０１を経由して、受信端末１０４に向けて、ＦＩＮ（５２０１、５２０４、５２０７）が送られる。次に、受信端末１０４から、通信装置＃２ １０１と通信装置＃１ １００を経由して、送信端末１０３に向けて、ＦＩＮ−ＡＣＫ（５２０８、５２０５、５２０２）が送られる。最後に、送信端末１０３から、通信装置＃１ １００と通信装置＃２ １０１を経由して、受信端末１０４に向けて、ＡＣＫ（５２０３、５２０６、５２０９）が送られる。

【0137】

図５３は、図９に示すデータ通信を行った後に、ＴＣＰコネクションを切断するための別のシーケンス図を示す。送信端末１０３から、通信装置＃１ １００と通信装置＃２ １０１を経由して、受信端末１０４に向けて、ＦＩＮ（５３０１、５３０４、５３０７）が送られる。次に、受信端末１０４から、通信装置＃２ １０１と通信装置＃１ １００を経由して、送信端末１０３に向けて、ＦＩＮ−ＡＣＫ（５３０８、５３０５、５３０２）が送られる。通信装置＃２ １０１は、ＦＩＮ−ＡＣＫ５３０８を受け取ると、ＡＣＫ５３０９を返信する。通信装置＃１ １００は、ＦＩＮ−ＡＣＫ５３０５を受け取ると、ＡＣＫ５３０６を返信する。送信端末１０３は、ＦＩＮ−ＡＣＫ５３０２を受け取ると、ＡＣＫ５３０３を返信する。

【0138】

以上、図９並びに図４８ないし図５３により、端末間でＴＣＰコネクションを確立後、通信装置が、送信側と受信側とのデータ通信を中継し、送信側の端末にＡＣＫを返すタイミングを制御する。データ通信に関するＡＣＫを送信側が受信するのに応じて、送信側からＴＣＰコネクションを切断する処理が行われる、例を説明した。

【産業上の利用可能性】

【0139】

本発明は、例えば、端末間の通信を中継する通信装置及び通信システムに利用可能である。

【符号の説明】

【0140】

１０３、９０３、９０４ 端末
１０４、９０５、９０６ 端末
１１０ データの流れ
１００、９１０ 通信装置
１０１、９２０ 通信装置
９００、９０１、９０２、９０７ ネットワーク
１０００ プロキシモジュール

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】

【図38】

【図39】

【図40】

【図41】

【図42】

【図43】

【図44】

【図45】

【図46】

【図47】

【図48】

【図49】

【図50】

【図51】

【図52】

【図53】