(57)【特許請求の範囲】
【請求項１】
他の装置までの通信経路に応じて特定された当該通信経路において一度に送信可能な第１のデータ量に基づいて定まる、前記他の装置との接続において一度に送信可能なデータ量に関する第２のデータ量の更新処理を行う更新手段と、
前記第１のデータ量の有効期限が切れていても、前記接続において信号の送信と受信とが行われていない時間が所定時間以上となるまでは、
１）前記第２のデータ量を小さくする場合には前記更新手段による当該第２のデータ量の更新処理を行い、
２）前記第２のデータ量を大きくする場合には前記更新手段による当該第２のデータ量の更新を行わない、
ように前記更新手段を制御する制御手段と、
を有することを特徴とする通信装置。
【請求項２】
前記更新手段は、前記時間が所定時間以上となった場合に、前記第２のデータ量の更新処理を行うことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記更新手段は、更新した後の前記第２のデータ量のデータを有する信号を前記他の装置へ宛てて送信して、当該信号が前記他の装置に届かなかった場合、前記第２のデータ量を小さくするように、さらなる当該第２のデータ量の更新処理を行うことを特徴とする請求項２に記載の通信装置。
【請求項４】
前記信号は、前記接続が生存しているかを確認するためのパケットであることを特徴とする請求項３に記載の通信装置。
【請求項５】
前記更新手段は、さらに、前記時間が所定時間以上となった場合であって、前記第１のデータ量の有効期限が切れている場合、前記第１のデータ量を更新することを特徴とする請求項１から４のいずれか１項に記載の通信装置。
【請求項６】
他の装置までの通信経路に応じて特定された当該通信経路において一度に送信可能な第１のデータ量に基づいて定まる、前記他の装置との接続において一度に送信可能なデータ量に関する第２のデータ量の更新処理を行う更新手段を有する通信装置の制御方法であって、
前記第１のデータ量の有効期限が切れていても、前記接続において信号の送信と受信とが行われていない時間が所定時間以上となるまでは、
１）前記第２のデータ量を小さくする場合には前記更新手段による当該第２のデータ量の更新処理を行い、
２）前記第２のデータ量を大きくする場合には前記更新手段による当該第２のデータ量の更新を行わない、
ように前記更新手段を制御する工程を有することを特徴とする制御方法。
【請求項７】
他の装置までの通信経路に応じて特定された当該通信経路において一度に送信可能な第１のデータ量に基づいて定まる、前記他の装置との接続において一度に送信可能なデータ量に関する第２のデータ量の更新処理を行う更新手段を有する通信装置に備えられたコンピュータに、
前記第１のデータ量の有効期限が切れていても、前記接続において信号の送信と受信とが行われていない時間が所定時間以上となるまでは、
１）前記第２のデータ量を小さくする場合には前記更新手段による当該第２のデータ量の更新処理を行い、
２）前記第２のデータ量を大きくする場合には前記更新手段による当該第２のデータ量の更新を行わない、
ように前記更新手段を制御する工程を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信における送信データ単位の制御技術に関する。
【背景技術】
【０００２】
Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ（ＩＰ）通信において、送信ホストから受信ホストまでの通信経路において一度に送信可能なデータ量の単位は、パスＭＴＵ（Ｐａｔｈ  Ｍａｘｉｍｕｍ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｕｎｉｔ）と呼ばれる。なお、以下では、パスＭＴＵのことを、ＰＭＴＵと呼ぶ。ここで、ＭＴＵは、通信経路に含まれるリンクのそれぞれにおいて一度に送信可能なデータ量に対応し、ＰＭＴＵは、通信経路に含まれるリンクのそれぞれに関するＭＴＵのうち最小の値となる。一般に、ＩＰ通信において、送信ホストが送信したパケットは、そのサイズがＰＭＴＵ以下である場合、経路上のルータによって分割や破棄されることなく受信ホストへ到達することが想定されている。
【０００３】
送信ホストが受信ホストまでのＰＭＴＵを推定すること、またはその方法は、パスＭＴＵ探索（Ｐａｔｈ  ＭＴＵ  Ｄｉｓｃｏｖｅｒｙ）と呼ばれる。なお、以下では、パスＭＴＵ探索のことをＰＭＴＵＤと呼ぶ。ＰＭＴＵＤの基本的なメカニズムは、ＩＥＴＦ（インターネット技術タスクフォース）のＲＦＣ（Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔｓ）１１９１（ＩＰｖ４）及びＲＦＣ１９８１（ＩＰｖ６）に提示されている。また、具体的なＰＭＴＵＤの様々な方法が提案されている（特許文献１、ＩＥＴＦのＲＦＣ４８２１参照）。ＩＥＴＦのＲＦＣ４８２１では、プロトコルスタックのパケット化階層におけるＰＭＴＵＤの方法が提案されており、その中の１つとして、ＴＣＰ再送機能で送信するパケットのサイズを減らしながら通信の相手装置へのＰＭＴＵを推定する方法が示されている。
【０００４】
ＩＰの上位層プロトコルのＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）の多くの実装では、送信ＩＰパケットサイズがＰＭＴＵ以下になるように、ＴＣＰ送信セグメントサイズが適応的に決定される。これにより、通信経路でのパケット消失を回避することが可能となる。この実装によれば、通信中にＴＣＰ通信の相手装置までの間の通信経路に関するＰＭＴＵが小さくなったとしても、送信可能な最大セグメントサイズを調整して送信データの到達性を確保することができる。
【０００５】
一般的な実装では、ＴＣＰ／ＩＰプロトコルスタックでは、受信ホストまでの経路情報に関連付けて推定されたＰＭＴＵが保持される。一方で、受信ホストまでの通信経路が変更されたなどの理由により、ＰＭＴＵは動的に変更され得るため、多くの実装では、保持されるＰＭＴＵには有効期限が付され、有効期限の経過時に対応するＰＭＴＵが無効化される。例えば、上述のＩＥＴＦのＲＦＣ１１９１やＲＦＣ１９８１には、１０分というＰＭＴＵの有効期限の参考値が記載されている。受信ホストへのＰＭＴＵは、無効化されると、送信ホストから最初の中継先までのＭＴＵにリセットされ、その後、ＰＭＴＵＤによって、受信ホストへのＰＭＴＵが推定される。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特許第３５１１９６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ＴＣＰでは、通信の相手装置への通信経路に関するＰＭＴＵが小さいとき、調整したＴＣＰ送信セグメントサイズが小さくなり、十分な伝送効率を得ることができない場合がある。一方で、そのＰＭＴＵが有効期限に達してリセットされ、ＰＭＴＵＤによってＰＭＴＵを再取得すると、結果として、その再取得後のＰＭＴＵが以前の値より大きくなりうる。ＰＭＴＵが大きくなる場合、ＴＣＰ送信セグメントサイズを大きくできるため、結果的に送信効率を改善することができる。しかしながら、通信の相手装置までの通信経路に関するＰＭＴＵが大きくなることを期待してＴＣＰ送信セグメントサイズを大きくすると、実際にはＰＭＴＵがリセット以前と変化しない場合、サイズが大きくなったパケットが経路上のルータで破棄されてしまう。この結果、ＴＣＰの再送が発生することになる。
【０００８】
ここで、ＴＣＰ通信が短時間で終了する場合、通信中にＰＭＴＵが変化することは稀である。また、ＴＣＰ通信が長時間におよぶ場合であっても、再び推定されたＰＭＴＵがリセット以前と変化していないことは多い。このため、データ送信を連続実行している最中に、ＰＭＴＵの有効期限切れが発生すると、ＴＣＰの再送を引き起こし、ＴＣＰ送信スループットが一時的に低下してしまうという課題があった。
【０００９】
本発明は上記課題に鑑みなされたものであり、他の装置との通信において一度に送信可能なデータ量の更新に関して、スループットの低下を防ぐ技術を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記目的を達成するため、本発明の通信装置は、他の装置までの通信経路に応じて特定された当該通信経路において一度に送信可能な第１のデータ量に基づいて定まる、前記他の装置との接続において一度に送信可能なデータ量に関する第２のデータ量の更新処理を行う更新手段と、前記第１のデータ量の有効期限が切れていても、前記接続において信号の送信と受信とが行われていない時間が所定時間以上となるまでは、１）前記第２のデータ量を小さくする場合には前記更新手段による当該第２のデータ量の更新処理を行い、２）前記第２のデータ量を大きくする場合には前記更新手段による当該第２のデータ量の更新を行わない、ように前記更新手段を制御する制御手段と、を有する。
【発明の効果】
【００１１】
本発明によれば、他の装置との通信において一度に送信可能なデータ量の更新に関して、スループットの低下を防ぐことができる。
【図面の簡単な説明】
【００１２】
【図１】通信装置の構成例を示すブロック図。
【図２】第１更新部１０７における処理例を示すフローチャート。
【図３】ＴＣＰキープアライブタイマ１０９における処理例を示すフローチャート。
【図４】第２更新部１０８における処理例を示すフローチャート。
【図５】第２更新部１０８における処理例を示すフローチャート。
【図６】送信シーケンス番号列と相手装置の受信ウィンドウとの関係を示す図。
【図７】第２更新部１０８における別の処理例を示すフローチャート。
【発明を実施するための形態】
【００１３】
以下、添付図面を参照して本発明の実施の形態を詳細に説明する。
【００１４】
＜＜実施形態１＞＞
本実施形態では、通常のＩＰ通信のようにして、通信装置から通信の相手装置までの通信経路に関して、その通信経路で一度に送信可能な最大のデータ量としてＰＭＴＵが特定される。そして、そのデータ量に基づいて定まる、ＴＰＣ接続において一度に送信可能な最大のデータ量は、セグメントサイズとして特定される。ここで、本実施形態では、通信装置は、ある通信経路の情報を、ＰＭＴＵ及びそのＰＭＴＵの有効期限と共に保持しておき、また、その通信経路と、送信元及び宛先が一致するＴＣＰ接続に関してそのセグメントサイズを保持する。
【００１５】
ここで、上述の課題を解決するために、通信装置は、通信の相手装置への通信経路に関するＰＭＴＵの有効期限が切れたとしても、送信セグメントサイズを大きくしないことができる。これによれば、通信装置が再送を行うことがなくなるため、再送による一時的な送信スループットの低下を防止することができる。しかしながら、有効期限が切れたＰＭＴＵの値が小さい場合で、かつ、更新することによってそのＰＭＴＵの値が大きくなる状況においては、ＰＭＴＵを更新して、送信セグメントサイズを大きくすれば、ＴＣＰ接続の通信効率を改善させることができる。すなわち、通信装置は、ＰＭＴＵの有効期限が切れた場合に、送信セグメントサイズを大きくしないことで再送を防止できるが、通信効率の改善の機会を失うこととなり得る。
【００１６】
このため、本実施形態に係る通信装置は、まず、再送発生の防止の観点から、ＰＭＴＵの有効期限が切れたとしても、直ちに送信セグメントサイズを更新しない。一方で、通信装置は、送信及び受信が行われていない時間が所定時間以上に達した場合に、送信セグメントサイズを更新するようにする。すなわち、通信装置は、送信及び受信が行われていない時間が所定時間以上に達した場合には、送信セグメントサイズをしないようにする。なお、通信装置は、送信及び受信が行われていない時間が所定時間以上となっていない場合は、送信セグメントサイズが小さくなる更新を行うが、送信セグメントサイズが大きくなる更新は行わないようにしてもよい。送信セグメントサイズが小さくなる更新であれば、再送が発生する確率が小さいからである。すなわち、通信装置は、ＰＭＴＵの有効期限が切れていても、送信及び受信が行われていない時間が所定時間以上となるまでは、送信セグメントサイズの更新を制限する。これにより、ＴＣＰ接続に係る通信が行われていない期間に送信セグメントの更新を行うため、その通信のスループットへの影響を抑えることができる。したがって、このような構成によって、送信セグメントサイズの更新に伴う、再送の発生の防止及びスループットの劣化の防止を達成することができる。
【００１７】
以下では、通信装置の構成及び処理の流れについて詳細に説明する。なお、以下に説明する通信装置の構成は一例に過ぎず、本実施形態に係る各処理を実行することができる構成であれば、他の構成が用いられてもよい。また、以下に説明する各処理も一例に過ぎず、上述のように、通信装置における送信セグメントサイズの更新を制限するものであれば、どのような処理が行われてもよい。なお、以下では、ＰＭＴＵなどの用語が用いられるが、これらの用語は説明のために用いたものであり、同様の概念の他の用語が用いられてもよいことは明らかである。例えば、ＰＭＴＵは、通信経路に含まれるリンクに基づいて特定される、その通信経路において一度に送信可能なデータ量を示すため、用語ＰＭＴＵは、そのようなデータ量を特定する概念の全てを含むものとして説明される。また、以下では、送信及び受信される信号がパケットの形式を有する場合について説明するが、他の形式の信号が用いられてもよい。
【００１８】
（通信装置）
図１は、本実施形態に係る通信装置の構成例を示す図である。通信装置は、例えば、システムバス１０１、ＣＰＵ１０２、ＲＯＭ１０３、ＲＡＭ１０４、通信制御部１０５及びプロトコル処理部１０６を含んで構成される。システムバス１０１には、ＣＰＵ１０２、ＲＯＭ１０３、ＲＡＭ１０４、通信制御部１０５及びプロトコル処理部１０６が接続され、システムバス１０１は、これらのブロック間のデータの転送を行う。ＣＰＵ１０２は中央演算処理装置であり、通信装置全体の制御及び通信装置の通信及びそれ以外の処理を行う。なお、ＣＰＵ１０２は、いわゆる中央演算処理装置でない他の１つ以上のプロセッサであってもよい。ＲＯＭ１０３は、例えばシステムプログラムを格納する記憶装置であり、ＲＡＭ１０４は、例えばシステムプログラム実行時に使用される一時記憶装置である。通信装置においては、一例として、ＲＯＭ１０３からＲＡＭ１０４にシステムプログラムが読み込まれ、ＣＰＵ１０２がそのシステムプログラムを実行する。通信制御部１０５は、ネットワーク１１０に接続してフレームの送受信を行うための制御／処理機能を有し、プロトコル処理部１０６は、ＴＣＰ／ＩＰ通信処理を実行するための制御／処理機能を有する。
【００１９】
通信装置は、通信制御部１０５を介してネットワーク１１０に接続することができる。通信制御部１０５は、ネットワーク１１０に対して伝送フレームの送受信を行うネットワークインタフェースである。通信制御部１０５は、例えばイーサネット（登録商標）規格に従った有線通信インタフェース、又は例えばＩＥＥＥ８０２．１１の無線ＬＡＮ通信規格に従った無線通信インタフェースを含む。例えばネットワーク１１０がイーサネット（登録商標）による有線ネットワークの場合、通信制御部１０５は、イーサネット（登録商標）のＭＡＣ処理（伝送メディア制御処理）、伝送フレームの送受信等の処理を行う。なお、図１は、通信装置が１つのネットワーク１１０に接続する場合の例を示しているが、通信装置は、複数のネットワーク１１０に接続してもよい。この場合、通信装置は、複数の通信制御部１０５を有してもよいし、複数のネットワークに接続可能な１つの通信制御部を有してもよい。
【００２０】
プロトコル処理部１０６は、例えば通信プロトコル処理用のハードウェア回路装置、又は通信プロトコル処理用に設計されたマイクロプロセッサを含んで構成され、汎用的なＴＣＰ／ＩＰプロトコルの通信処理を行う。例えば、プロトコル処理部１０６は、ＩＰｖ４（ＩＰバージョン４）、ＩＰｖ６（ＩＰバージョン６）、ＩＣＭＰ、ＵＤＰ、並びにＴＣＰの少なくともいずれかに関する通信プロトコル処理、送信フロー制御並びに輻輳制御、及び、通信エラー制御等を行う。なお、本実施形態では、プロトコル処理部１０６には、第１更新部１０７、第２更新部１０８、及びＴＣＰキープアライブタイマ１０９が、例えばプロトコル処理部１０６で実行されるソフトウェアとして、実装される。
【００２１】
プロトコル処理部１０６は、ＰＭＴＵの管理も行う。ここで、本実施形態におけるプロトコル処理部１０６によるＰＭＴＵ管理方法について説明する。プロトコル処理部１０６は、一般的なＩＰプロトコルスタックと同様に、ルーティングを実行する。ルーティング処理では、送信パケットの宛先ＩＰアドレスなどの情報に基づいて送信インタフェースや最初の送信先ノードが決定される。この処理のために、プロトコル処理部１０６は、ルーティングの決定規則であるルーティングテーブルを管理する。さらに、プロトコル処理部１０６は、送信パケットのルーティング処理結果を、パケットの送信元ＩＰアドレスと宛先ＩＰアドレスとの組み合わせを含むと共に有効期限を付した情報として、キャッシュして管理する。これにより、プロトコル処理部１０６は、ルーティング処理を効率化することができる。なお、ここでは、このキャッシュ先をルーティングキャッシュと呼ぶ。
【００２２】
ルーティングキャッシュの情報は、送信元ＩＰアドレスから宛先ＩＰアドレスへの経路情報でありうる。このため、本実施形態では、プロトコル処理部１０６は、送信元から宛先へのＰＭＴＵを、このルーティングキャッシュ情報に関連付けて保持する。なお、プロトコル処理部１０６は、ルーティングキャッシュ情報を破棄するとき、関連付けられたＰＭＴＵも削除する。ルーティングキャッシュ情報と関連付けられて保持されるＰＭＴＵの初期値は、ルーティング処理結果に含まれる送信インタフェースのＭＴＵ、又はそのインタフェースが接続するネットワークリンクのＭＴＵのいずれかの小さい値でありうる。そして、プロトコル処理部１０６は、ＰＭＴＵＤにより実際のＰＭＴＵが推定されると、保持しているＰＭＴＵの値を更新する。また、本実施形態では、プロトコル処理部１０６は、保持するＰＭＴＵに有効期限を設定し、その有効期限が経過したとき、ＰＭＴＵの値をリセットして初期値に戻す。なお、ルーティングキャッシュは、ルーティング処理結果を有効期限を付して一時的に保持する仕組みであるため、そのルーティングキャッシュに係る経路情報にも有効期限が設定されていることとなる。このため、ＰＭＴＵの有効期限は、関連付けられたルーティングキャッシュ情報の有効期限と同一とされてもよい。
【００２３】
（第１更新部１０７の処理）
次に、プロトコル処理部１０６における、第１更新部１０７の処理の流れについて、図２を用いて説明する。第１更新部１０７は、ルーティングキャッシュ情報に保持するＰＭＴＵ（以下、ＲＣＰＭＴＵと呼ぶ。）の更新に伴い、ＴＣＰ接続ごとに保持されるＰＭＴＵ（以下、ＴＣＰＭＴＵと呼ぶ。）を更新する処理を実行する。なお、ＴＣＰＭＴＵの値は、ＴＣＰ接続で用いられる最大セグメントサイズに関し、各ＴＣＰ接続では、データがそのＴＣＰＭＴＵの大きさを超えない範囲のサイズで伝送されるように、分割される。なお、ＴＣＰＭＴＵの値は、最大セグメントサイズそのものであってもよいし、最大セグメントサイズを特定するための何らかのインデックス又はインジケータ等であってもよい。
【００２４】
第１更新部１０７は、まず、ルータから送信された「Ｐａｃｋｅｔ−Ｔｏｏ−Ｂｉｇ」メッセージのＩＣＭＰｖ６パケットを受信する（Ｓ２０１）。このメッセージは、例えば、ＩＣＭＰｖ６フォーマットのタイプフィールドの値が２であるパケットの形式を有し得る。また、このメッセージには、ＭＴＵフィールドに、ルータが通知するＰＭＴＵ（以下、ＴＢＰＭＴＵと呼ぶ。）の値が含まれている。さらに、このメッセージには、そのルータが転送できず破棄したＩＰｖ６パケットの一部または全体が付加される。なお、ＩＰｖ４の場合は、Ｓ２０１において、ＩＰフラグメント不可のため転送パケットが破棄されたことを示すコードを有する「Ｄｅｓｔｉｎａｔｉｏｎ  Ｕｎｒｅａｃｈａｂｌｅ」メッセージのＩＣＭＰパケットが受信される。このメッセージは、ＩＣＭＰフォーマットのタイプフィールドの値が３で、コードフィールドの値が４のパケットである。
【００２５】
続いて、第１更新部１０７は、受信した「Ｐａｃｋｅｔ−Ｔｏｏ−Ｂｉｇ」メッセージに付されたパケットの送信元ＩＰアドレスと宛先ＩＰアドレスに基づいて、ルーティングキャッシュ情報を検索し、対応するＲＣＰＭＴＵを取得する（Ｓ２０２）。そして、第１更新部１０７は、ルーティングキャッシュ情報の検索に失敗してＲＣＰＭＴＵを取得できなかった場合、又は受信したメッセージで通知されたＴＢＰＭＴＵが取得したＲＣＰＭＴＵの値以上である場合（Ｓ２０２でＮＯ）、処理を終了する。
【００２６】
一方、第１更新部１０７は、取得したＲＣＰＭＴＵの値が、受信したメッセージによって通知されたＴＢＰＭＴＵの値より小さかった場合（Ｓ２０２でＹＥＳ）は、そのＲＣＰＭＴＵを、ＴＢＰＭＴＵの値となるように情報を更新する（Ｓ２０３）。そして、第１更新部１０７は、ＲＣＰＭＴＵを更新したルーティングキャッシュ情報の送信元ＩＰアドレスと宛先ＩＰアドレスが、それぞれ自局のＩＰアドレスと通信の相手装置のＩＰアドレスに一致するＴＣＰ接続があるかを調べる（Ｓ２０４）。そのようなＴＣＰ接続がない場合（Ｓ２０４でＮＯ）、第１更新部１０７は、処理を終了する。一方、第１更新部１０７は、そのようなＴＣＰ接続がある場合（Ｓ２０４でＹＥＳ）、更新したＲＣＰＭＴＵの値が、そのＴＣＰ接続についてのＴＣＰＭＴＵの値よりも小さいかを調べる（Ｓ２０５）。そして、第１更新部１０７は、更新したＲＣＰＭＴＵの値が、Ｓ２０４で発見されたＴＣＰ接続のＴＣＰＭＴＵの値より小さい場合（Ｓ２０５でＹＥＳ）、そのＴＣＰＭＴＵの値を、更新後のＲＣＰＭＴＵの値となるように更新する（Ｓ２０６）。一方、第１更新部１０７は、更新したＲＣＰＭＴＵの値が、Ｓ２０４で発見されたＴＣＰ接続のＴＣＰＭＴＵの値以上である場合（Ｓ２０５でＮＯ）は、ＴＣＰＭＴＵの更新を行わない。その後、第１更新部１０７は、Ｓ２０４で発見されたＴＣＰ接続の全てについてＳ２０５の判定と、必要に応じてＳ２０６の更新処理とが行われたかを判定し（Ｓ２０７）、全ＴＣＰ接続について処理が完了した場合（Ｓ２０７でＹＥＳ）に、処理を終了する。一方、第１更新部１０７は、全ＴＣＰ接続についての処理が完了していない場合（Ｓ２０７でＮＯ）は、処理をＳ２０５に戻す。
【００２７】
このように、第１更新部１０７は、「Ｐａｃｋｅｔ−Ｔｏｏ−Ｂｉｇ」メッセージを受信して、ルーティングキャッシュ情報に関連付けられたＲＣＰＭＴＵを更新する。また、第１更新部１０７は、そのＲＣＰＭＴＵに関するルーティングキャッシュ情報の送信元と宛先のＩＰアドレスが一致するＴＣＰ接続に関するＴＣＰＭＴＵをも、必要に応じて更新する。ただし、ＴＣＰＭＴＵの値は、その大きさが小さくなる場合にのみ更新され、第１更新部１０７は、ＴＣＰＭＴＵの値を大きくする更新を行うことはない。
【００２８】
（ＴＣＰキープアライブタイマ１０９の処理）
次に、プロトコル処理部１０６における、ＴＣＰキープアライブタイマ１０９の処理の流れについて、図３を用いて説明する。ＴＣＰでは、アイドル状態（接続中であるが送受信のない状態）でも、その接続が維持される。その一方で、ＴＣＰでは、アイドル状態が長時間に及ぶ場合、通信の相手装置とのコネクションが正常に維持されているかを検出するため、ＴＣＰキープアライブと呼ばれる機能が実装される。ＴＣＰキープアライブについては、ＩＥＴＦのＲＦＣ１１２２に記載されている。ＴＣＰキープアライブ機能では、アイドル状態になったときにタイマが起動され、タイマのタイムアウト時に、検査パケットが送信されて、通信の相手装置の生存が確認される。
【００２９】
図３の処理は、通信中であるＴＣＰコネクションに対して実行され、また、プロトコル処理部１０６における周期的なタイマ処理として実装される。一般に、ＴＣＰキープアライブタイマのタイムアウト時間は秒単位で定められ、時間計測の精度は重要でない。このため、本実施形態では、図３の処理は、ＴＣＰ接続ごとに約１秒に１回、周期的に実行されるものとする。
【００３０】
図３の処理において、ＴＣＰキープアライブタイマ１０９は、まず、前回の本処理実行後、送信または受信処理を実行したかを確認する（Ｓ３０１）。この結果、送信または受信処理を実行していた場合（Ｓ３０１でＹＥＳ）、ＴＣＰキープアライブタイマ１０９は、アイドル状態の計時時間をリセットしてゼロとして（Ｓ３０３）、処理を終了する。一方、送信または受信処理を実行していなかった場合（Ｓ３０１でＮＯ）、アイドル状態の計時時間を加算する（Ｓ３０２）。その後、ＴＣＰキープアライブタイマ１０９は、現在の計時時間が、タイムアウトとなる所定時間以上であるかを判定する（Ｓ３０４）。ＴＣＰキープアライブタイマ１０９は、現在の計時時間が所定時間以上でない場合（Ｓ３０４でＮＯ）は、そのまま処理を終了する。一方、ＴＣＰキープアライブタイマ１０９は、現在の計時時間が所定時間以上の場合（Ｓ３０４でＹＥＳ）、タイムアウトが発生したと判定し、計時を停止する（Ｓ３０５）。具体的には、ＴＣＰキープアライブタイマ１０９は、対象のＴＣＰ接続について、次回の図３の処理が実行されないようにする。その後、ＴＣＰキープアライブタイマ１０９は、タイムアウト処理を起動して（Ｓ３０６）、処理を終了する。このタイムアウト処理については後述する。
【００３１】
（第２更新部１０８の処理）
次に、プロトコル処理部１０６における、第２更新部１０８の処理の流れについて、図４、図５、及び図６を用いて説明する。図４は、図３のＳ３０６でＴＣＰキープアライブタイマ１０９がタイムアウト処理を行うことにより開始される、第２更新部１０８が実行する処理の流れの例を示している。
【００３２】
第２更新部１０８は、処理が始まると、まず、ＴＣＰ接続の自局のＩＰアドレスを送信元ＩＰアドレスとし、通信の相手装置のＩＰアドレスを宛先ＩＰアドレスとして、ルーティングキャッシュ情報がキャッシュされているかを判定する（Ｓ４０１）。ここで、ルーティングキャッシュ情報がキャッシュされていない場合（Ｓ４０１でＮＯ）は、自局内に相手装置へのＲＣＰＭＴＵが保持されていないこととなる。このため、第２更新部１０８は、送信インタフェースのＭＴＵ（以下、ＩＦＭＴＵと呼ぶ。）と、そのインタフェースが接続するローカルネットワークリンクのＭＴＵ（以下、ＬＬＭＴＵと呼ぶ。）のいずれかの小さい値となるように、ＴＣＰＭＴＵの値を更新する（Ｓ４０４）。
【００３３】
一方、第２更新部１０８は、ルーティングキャッシュ情報をキャッシュしている場合（Ｓ４０１でＹＥＳ）、そのルーティングキャッシュ情報に対応するＲＣＰＭＴＵの値が、ＩＦＭＴＵ及びＬＬＭＴＵの小さい方の値よりも小さいかを判定する（Ｓ４０２）。ＲＣＰＭＴＵの値がＩＦＭＴＵ及びＬＬＭＴＵの小さい方の値よりも小さい場合（Ｓ４０２でＹＥＳ）、第２更新部１０８は、ＴＣＰＭＴＵの値を、ＲＣＰＭＴＵの値となるように更新する（Ｓ４０３）。一方、ＲＣＰＭＴＵの値がＩＦＭＴＵ及びＬＬＭＴＵの小さい方の値以上である場合（Ｓ４０２でＮＯ）、ＩＦＭＴＵ及びＬＬＭＴＵの小さい方の値となるように、ＴＣＰＭＴＵの値を更新する（Ｓ４０４）。なお、第２更新部１０８による更新では、ＴＣＰＭＴＵの値は更新前により大きくなってもよい。最後に、第２更新部１０８は、ＴＣＰキープアライブ機能としての通信の相手装置の生存を確認するとともに、その相手装置のＰＭＴＵを推定するためのＰＭＴＵＤ処理を実行し（Ｓ４０５）、処理を終了する。
【００３４】
次に、Ｓ４０５の処理の詳細について、図５を用いて説明する。図５は、ＰＭＴＵＤに対応したＴＣＰキープアライブ検査処理の流れを示している。まず、第２更新部１０８は、処理が開始されると、キープアライブ検査パケットの送信回数をゼロにクリアする（Ｓ５０１）。続いて、第２更新部１０８は、キープアライブ検査パケットの送信回数が既定数以下であるかを判定する（Ｓ５０２）。なお、初期的には、キープアライブ検査パケットの送信回数は０であるため、第２更新部１０８は、処理をＳ５０３へ進める。なお、第２更新部１０８は、キープアライブ検査パケットの送信回数が既定数を超えており、規定回数の検査パケットの送信に対して相手装置からの応答がなかったと判定すると（Ｓ５０２でＮＯ）、そのＴＣＰ接続をクローズする（Ｓ５１０）。その後、第２更新部１０８は、処理を終了する。
【００３５】
一方、第２更新部１０８は、Ｓ５０３においてキープアライブ検査パケットを送信し、続いて、その検査パケットに対して、Ｐａｃｋｅｔ−Ｔｏｏ−Ｂｉｇが受信されたかを判定する（Ｓ５０４）。そして、第２更新部１０８は、Ｐａｃｋｅｔ−Ｔｏｏ−Ｂｉｇが受信されたと判定すると（Ｓ５０４でＹＥＳ）、Ｐａｃｋｅｔ−Ｔｏｏ−Ｂｉｇによって通知されたＴＢＰＭＴＵとなるように、そのＴＣＰ通信のＴＣＰＭＴＵを更新する（Ｓ５０５）。なお、このＳ５０５の処理は、第１更新部１０７が実行してもよく、第１更新部１０７は、この時に、併せて、ＲＣＰＭＴＵを更新してもよい。また、ＴＣＰＭＴＵの更新は、Ｐａｃｋｅｔ−Ｔｏｏ−Ｂｉｇが受信されたときに、その経路情報と送信元・宛先アドレスが一致する全てのＴＣＰ接続について実行されてもよいし、図３でタイムアウトが発生したＴＣＰ接続についてのみ実行されてもよい。なお、キープアライブ検査パケットが相手装置に到着していない場合に、Ｓ５０５の処理が実行される。したがって、第２更新部１０８は、処理をＳ５０５からＳ５０３へ戻し、続いて、更新されたＴＣＰＭＴＵで検査パケットを作成して送信する。すなわち、Ｓ５０３〜Ｓ５０５の処理が繰り返され、これにより相手装置へのＰＭＴＵＤが実現される。
【００３６】
ここで、Ｓ５０３において送信されるキープアライブ検査パケットの作成方法について、図６を参照して説明する。図６は、ＴＣＰ接続ごとに管理される送信シーケンス番号列と通信の相手装置の受信ウィンドウとの関係を表している。図６では、送信シーケンス番号６０１がそれぞれの四角形で表される送信データに付されており、右から左へ番号が大きくなるように一列に並んでいる状態を示している。６０２の位置のシーケンス番号までが、送信及び受信済みのデータ６０３である。すなわち、６０２は、現在の送信済みのデータのうち、最大のシーケンス番号のものを示している。そして右隣の６０４のデータは、相手装置が次に受信すべきデータである。６０６の太破線の枠線は、相手装置の受信ウィンドウを示す。つまり、通信の相手装置は、現在、６０４から６０５までの範囲の送信シーケンス番号のデータを受信することができることを示している。この受信ウィンドウの範囲長は、例えば、相手装置の受信ウィンドウサイズ６０７と一致する。
【００３７】
本実施形態では、キープアライブ検査パケットとして、ペイロードデータを有するＴＣＰパケットが作成される。ここで、キープアライブ検査パケットを作成して送信するのは、図３のＳ３０６でタイムアウトが発生した時であり、ＴＣＰ接続においてデータの送信と受信とが行われていないアイドル状態である。したがって、このペイロードデータは、受信装置において破棄されてもよいデータでありうる。このため、第２更新部１０８は、送信するキープアライブ検査パケットにおいて、それまでに受信が完了しているデータに関するシーケンス番号を進めないようにシーケンス番号を設定して、相手装置にデータを破棄させた上でＡＣＫを送信させる。具体的には、第２更新部１０８は、ペイロードの最後尾の１オクテットデータの送信シーケンス番号が６０２のデータのものと同じとなるように、キープアライブ検査パケットを作成する。さらに、検査パケットのＩＰパケットでは、その全長が（例えば図４のＳ４０３又はＳ４０４で更新された）ＴＣＰＭＴＵに一致するように、ペイロードサイズが決定される。ここで、６０９は決定したペイロードサイズを示しており、６０８のデータに対応するシーケンス番号が、検査パケットのＴＣＰヘッダに格納される。これにより、検査パケットが相手装置まで到達しても、そのペイロードデータの全てが相手装置の受信ウィンドウ６０６から外れているため、相手装置はそのペイロードデータを受信しない（破棄する）。また、相手装置は、次に受信すべき６０４のデータに関するシーケンス番号をＡＣＫ番号とする受信応答を返信することになる。このため、キープアライブ検査パケットの機能を果たすことができる。一方、キープアライブ検査パケットのＩＰパケット長はＴＣＰＭＴＵとなっている。このため、現在のＴＣＰＭＴＵよりも、相手装置までの通信経路に関するＰＭＴＵが小さい場合、経路途中のルータからＰａｃｋｅｔ−Ｔｏｏ−Ｂｉｇメッセージが返信され、通信装置には、ＴＢＰＭＴＵが通知されることになる。この場合、第２更新部１０８は、図５のＳ５０４においてＰａｃｋｅｔ−Ｔｏｏ−Ｂｉｇメッセージを受信することとなり、Ｓ５０５において、ＴＣＰＭＴＵがＴＢＰＭＴＵに更新される。これにより、次にＳ５０３でキープアライブ検査パケットが再送信されるときには、検査パケットのペイロードサイズは、更新されたＴＣＰＭＴＵの値に一致するように設定されることにより、小さくなる。
【００３８】
図５に戻り、Ｓ５０４においてＰａｃｋｅｔ−Ｔｏｏ−Ｂｉｇメッセージを受信していない場合（Ｓ５０４でＮＯ）、第２更新部１０８は、続いて、キープアライブ検査パケットに対するＡＣＫ（受信確認応答）を受信したかを確認する（Ｓ５０６）。そして、第２更新部１０８は、ＡＣＫを受信した場合（Ｓ５０６でＹＥＳ）、相手装置が生存していることを確認できたため、ＴＣＰキープアライブタイマをリセットし（Ｓ５０９）、処理を終了する。
【００３９】
一方、第２更新部１０８は、ＡＣＫを受信しなかった場合（Ｓ５０６でＮＯ）、続いて、送信したキープアライブ検査パケットへの応答待ちの経過時間がタイムアウトしたかを確認する（Ｓ５０７）。なお、ここでの応答待ちのタイムアウト時間は、一定の時間でもよいし、キープアライブ検査パケットの送信回数の増加に従って増加させてもよい。第２更新部１０８は、応答待ちがタイムアウトした場合（Ｓ５０７でＹＥＳ）、検査パケット送信回数を１だけ増加させ（Ｓ５０８）、処理をＳ５０２へ戻す。ここで、検査パケット送信回数が規定数を超えると（Ｓ５０２でＮＯ）、ＴＣＰ接続がクローズされることとなる。一方、第２更新部１０８は、応答待ちがタイムアウトしていない場合（Ｓ５０７でＮＯ）、タイムアウトするまで、Ｐａｃｋｅｔ−Ｔｏｏ−Ｂｉｇメッセージの受信と、相手装置からのＡＣＫの受信とのいずれかを待ち受ける。
【００４０】
以上のように、本実施形態では、各ＴＣＰ接続のＴＣＰＭＴＵは、第１更新部１０７と第２更新部１０８の何れかによって更新されうる。このとき、本実施形態では、ＲＣＰＭＴＵの有効期限が経過してその値がリセットされても、そのＲＣＰＭＴＵに基づいて定められる、ＴＣＰ接続のＴＣＰＭＴＵについては、直ちに更新されない。すなわち、通信装置は、ＴＣＰ接続について、その送信と受信とが行われていない時間が所定時間以上となるまでは、ＴＣＰＭＴＵの更新を制限する。ここでの制限は、例えば、ＴＣＰＭＴＵの更新を行わないこと、又は、ＴＣＰＭＴＵの値を小さくする更新のみを認めること、などを含む。一方、通信装置は、送信と受信とが行われていない時間が所定時間以上となった場合には、ＴＣＰＭＴＵの更新の制限を解除する。すなわち、通信装置は、送信と受信とが行われていない時間が所定時間以上となった場合に、ＴＣＰＭＴＵを更新し、又は、ＴＣＰＭＴＵの値を大きくする更新をも認める。これにより、ＴＣＰ接続に係る通信が行われていない期間に送信セグメントの更新を行うため、その通信のスループットへの影響を抑えることができる。したがって、このような構成によって、送信セグメントサイズの更新に伴う、再送の発生の防止及びスループットの劣化の防止を達成することができる。
【００４１】
＜＜実施形態２＞＞
本実施形態では、個々のＴＣＰ接続の接続継続時間が計時され、ＴＣＰキープアライブタイマのタイムアウト発生時に、キープアライブタイムアウト処理の中でＴＣＰＭＴＵを更新するか否かが、その継続時間に基づいて決定される処理について説明する。図７に、本実施形態において、第２更新部１０８が実行するＴＣＰキープアライブタイマのタイムアウト処理の流れの例を示す。なお、図７において、図４の処理と同様の処理については、同じ参照符号を付して、その説明を省略する。
【００４２】
第２更新部１０８は、実施形態１の図４の処理と同様に、図３のＳ３０７においてＴＣＰキープアライブタイマのタイムアウト処理が起動されると、図７の処理を開始する。本処理では、第２更新部１０８は、ＴＣＰ接続の継続時間が、所定時間より大きいかどうかを調べ（Ｓ７０１）、この所定時間よりも継続時間が大きい場合にのみ、キープアライブタイマのタイムアウト処理において、ＴＣＰＭＴＵを更新する。具体的には、第２更新部１０８は、ＴＣＰ接続の継続時間が所定時間より大きい場合（Ｓ７０１でＹＥＳ）、図４のＳ４０１〜Ｓ４０５と同様にして、ＴＣＰＭＴＵの値を更新して、ＴＣＰＭＴＵ更新対応のＴＣＰキープアライブ検査処理を実行する。なお、ＴＣＰキープアライブ検査処理については、実施形態１と同様に、図５の処理が実行される。その後、第２更新部１０８は、ＴＣＰ接続の継続時間をリセットして、計時を再開し（Ｓ７０２）、処理を終了する。一方、第２更新部１０８は、ＴＣＰ接続の継続時間が所定時間以下である場合（Ｓ７０１でＮＯ）、ＴＣＰＭＴＵの更新を伴わない、通常のＴＣＰキープアライブ検査処理を実行する（Ｓ７０３）。Ｓ７０３では、ＴＣＰ通信の相手装置が生存しているか否かの検査のみが実行される。その後、第２更新部１０８は処理を終了する。
【００４３】
このように、本実施形態では、ＴＣＰ接続の経過時間によって、ＴＣＰキープアライブタイマのタイムアウト処理において、ＴＣＰＭＴＵを更新するかが決定される。一般的に、ＴＣＰキープアライブタイマのタイムアウト時間は設定可能なパラメータとして実装され、例えば、短い時間間隔でタイムアウトが発生しうる。そして、この場合に、タイムアウトが発生する度にＴＣＰＭＴＵを更新すると、結果としてスループットが劣化し得る。これに対して、本実施形態によれば、ＴＣＰキープアライブタイマのタイムアウト時間が小さく設定された場合であっても、ＴＣＰ接続の継続時間に基づいて、十分な時間が経過した場合にのみＴＣＰＭＴＵが更新されるようにすることが可能となる。なお、本実施形態では、他の構成については実施形態１と同様であるため、実施形態１と同様の効果を得ることも可能である。
【００４４】
なお、実施形態１及び２は、ともに、第２更新部１０８がキープアライブ検査パケットを利用したＰＭＴＵＤを実行すると説明した。しかしながら、他のＰＭＴＵＤの方法が、ＰＭＴＵを推定するのに用いられてもよい。例えば、第２更新部１０８は、ＩＣＭＰエコーリクエストパケットを使用して、ＰＭＴＵＤを実行してもよい。また、通信装置が、さらに他のＰＭＴＵＤの処理機能を有し、第２更新部１０８がそのＰＭＴＵＤ処理を起動するようにしてもよい。また、実施形態１及び２は、ともに、データ通信のプロトコルとしてＴＣＰが用いられる例について説明したが、データ通信がアイドル状態を検出可能な他のプロトコルが用いられてもよい。
【００４５】
＜＜その他の実施形態＞＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００４６】
１０６：プロトコル制御部、１０７：第１更新部、１０８：第２更新部、１０９：ＴＣＰキープアライブタイマ
【図１】
0006478816.tif 000002
【図２】
0006478816.tif 000003
【図３】
0006478816.tif 000004
【図４】
0006478816.tif 000005
【図５】
0006478816.tif 000006
【図６】
0006478816.tif 000007
【図７】
0006478816.tif 000008