接続指向の正順デリバリ環境において接続を管理するための方法およびシステム
本開示は、正順デリバリ環境においてクライアントとサーバとの間の接続を確立するためのシステムおよび方法を提供する。本開示のシステムおよび方法は、第１の種類のメッセージをサーバへと送信することによって接続の確立を要求するように構成されたクライアントを含んでおり、サーバが、サーバの接続につながる第２の種類のメッセージをクライアントへと送信することによって接続の確立が可能であることを確認するように構成さえている。第１の種類のメッセージにより、第１の最大応答時間としての第１の所定の期間を測定する第１のクライアントタイマが開始され、第２の種類のメッセージまたはデータメッセージの受信によって、第１のクライアントタイマが停止される。接続は、第３の種類のメッセージの送信によって閉じられる。
【発明の詳細な説明】
【関連出願および優先権の主張】
【０００１】
本出願は、「ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＭＡＮＡＧＩＮＧ Ａ ＣＯＮＮＥＣＴＩＯＮ ＩＮ Ａ ＣＯＮＮＥＣＴＩＯＮ ＯＲＩＥＮＴＥＤ ＩＮ−ＯＲＤＥＲ ＤＥＬＩＶＥＲＹ ＥＮＶＩＲＯＮＭＥＮＴ」という名称の２００９年９月３０日付の米国特許出願第１２／５７１，０１８号の部分継続出願である。特許出願第１２／５７１，０１８号は、本出願の譲受人へと譲渡されており、ここでの言及によってあたかも全体が本明細書に記載されているかのように本出願に援用される。本出願は、米国特許出願第１２／５７１，０１８号について米国特許法第１１９条（ｅ）に規定の優先権を主張する。
【技術分野】
【０００２】
本開示は、伝達可能なアイテムの正順（ｉｎ−ｏｒｄｅｒ）デリバリを特徴とするネットワークによって互いに接続されたマルチコンポーネントシステムのコンポーネント間の通信のための方法およびシステムに関する。
【背景技術】
【０００３】
現在開発されている高度に統合されたシステムにおいては、高帯域幅の通信能力が、性能の要件としての前提条件である。さらに、セカンドソースの原理を追求するシステム開発者は、任意のあらゆる製造者から自身の設計のコンポーネントを選択できなければならないと同時に、それらがいかなる問題もなく相互運用されることを必要とする。このことが、該当の分野において活動する複数の製造者によって設立され、コンポーネントおよびコンポーネント間の相互通信についての規格を定める標準化団体の形成につながる。そのような標準化団体の１つが、モバイル・インダストリ・プロセッサ・インターフェイス・アライアンス（ＭＩＰＩ（登録商標））である。現時点において、この団体は、モバイルシステムの相互通信の詳細について作業する約１５０の製造者の集まりである。ある程度の情報が、ワールドワイドウェブ上のｈｔｔｐ：／／ｗｗｗ．ｍｉｐｉ．ｏｒｇ／において入手可能である。
【０００４】
コンポーネント間の通信を標準化するために、ＭＩＰＩ（登録商標）アライアンスは、モバイルシステムにおいてデバイスを接続するためのシリアル高速リンクとして、ＵｎｉＰｒｏＳＭを定めている。ＵｎｉＰｒｏＳＭ規格は、着実に発展中であり、現時点において規格バージョン１．０がリリースされている。この規格の種々のバージョンの特徴についてのある程度の情報が、ワールドワイドウェブ上のインターネット百科事典（ｈｔｔｐ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｕｎｉｐｒｏ）において入手可能である。
【０００５】
相互接続および通信の規格を用意することで、製造者は、自身のシステムの開発においてはるかに柔軟になることができ、種々の要件に良好に適し、種々のベンダによって提供されるコンポーネントを混ぜ合わせ、適合させることができる。ＵｎｉＰｒｏ規格またはユニファイドプロトコルは、高速シリアルリンクを利用するチップ対チップのネットワークに向けられている。エラーハンドリング、フロー制御、ルーティング、およびアービトレーションなどの一般的な相互接続の問題を解決する汎用の通信プロトコルとなるように定められている。
【０００６】
現時点において、ＵｎｉＰｒｏは、接続の確立と同時に、状態およびバッファなどの他のリソースの割り当てを必要とする接続指向の通信を提供している。通常は、接続が、通信に関わるバッファのオーバフローを防止するための、クレジット・エンド・トゥ・エンド・フロー制御を実装する。これが、データの喪失または破損がないことを保証する信頼できるネットワークの使用との組み合わせにおいて、ユーザへの信頼できる通信サービスを保証する。
【０００７】
ＵｎｉＰｒｏの将来の発展において、リアルタイムのトラフィッククラスを提供するバージョンを予測することができるが、レイヤ２の再送信の数を抑える結果となり、データのデリバリそのものについての保証を犠牲にすることによって、パケットのデリバリに関する制限時間を保証できる。なぜならば、レイヤ２の再送信の数を抑えることで、データの断片がデリバリされない可能性をきわめて小さくできるからである。ＵｎｉＰｒｏアプリケーションの上位のレイヤが、該当のレポートの受信時に、欠けた断片を処理しなければならない。接続指向の通信にもとづく信頼できるリアルタイムのトラフィッククラスは、接続を開始し、維持し、終了させるためのプロトコルを必要とする。現時点において、スリーウェイハンドシェイクが、伝送制御プロトコルＴＣＰから知られている。詳細は、ｔｈｅ ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ、ＤＡＲＰＡ Ｉｎｔｅｒｎｅｔ ｐｒｏｇｒａｍ、ｐｒｏｔｏｃｏｌ ｓｐｅｃｉｆｉｃａｔｉｏｎ ｂｙ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｃｉｅｎｃｅｓ Ｉｎｓｔｉｔｕｔｅ、Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｓｏｕｔｈｅｒｎ Ｃａｌｉｆｏｒｎｉａ、ＩＥＴＦ ｒｅｑｕｅｓｔ ｆｏｒ ｃｏｍｍｅｎｔｓ ＃７９３、Ｓｅｐｔｅｍｂｅｒ １９８１に公開されている。しかしながら、ＴＣＰは、ネットワークにつきものの低い信頼性に対処しなければならず、したがってそのような不確実性に対処するための予防措置をプロトコルにおいて講じる必要があるため、ユニファイドプロトコルとは大きく異なる。さらに、ＴＣＰは、例えばパケットがネットワークにおいてさまざまな経路をとることができるため、データのデリバリに順番がないことを前提としている。したがって、ＴＣＰは、接続の管理を保証するために、きわめて大きな続き番号および最大パケット寿命を使用する。しかしながら、ＵｎｉＰｒｏは、典型的には最大でも１０のノードからなる小さなネットワークにおいて働き、順番どおりの通信を提供する。したがって、使用されるオーバヘッドを通常のプロトコルよりも少なくすることができ、機能を犠牲にすることなく単純さを達成することができる。
【０００８】
さらに、Ｂ−ＩＳＤＮ ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｔｏｃｏｌｓ ｆｏｒ ａｃｃｅｓｓ ｓｉｇｎａｌｌｉｎｇ， ＩＴＵ−Ｔ ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｑ．２９３１， Ｆｅｂ−１９９５においてＩＴＵ−Ｔ Ｑ．２９３１に開示されているＡＴＭ接続設定も当分野において知られている。関連の接続設定は、ＡＴＭにおいてはリファレンスと呼ばれる続き番号を使用するＴＣＰにおいて使用される機構と同様の機構を使用するが、ＡＴＭも、メッセージのオーバヘッドを生じさせ、したがって通信チャネルからの帯域幅を必要とする大きな続き番号にもとづいている。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本開示の目的は、接続指向の正順デリバリ環境において接続を管理するための代案の方法およびシステムであって、最小限のメッセージのオーバヘッドでリソースの適切な割り当てならびに接続の確立および終了を可能にする方法およびシステムを提供することにある。
【課題を解決するための手段】
【００１０】
この課題は、接続指向の正順デリバリ環境において接続を管理するための方法であって、下記によって解決される。
ａ）クライアントが第１の種類のメッセージ（１１４０）をサーバへと送信することによって、接続の確立を要求し、
ｂ）サーバが、サーバの接続につながる第２の種類のメッセージをクライアントへと接続することによって接続の確立が可能であることを確認し、
ｃ）第１の種類のメッセージを送信することによって、第１の最大応答時間としての第１の所定の期間を測定する第１のクライアントタイマを始動し、第２の種類のメッセージまたはデータメッセージを受信することによって、第１のクライアントタイマが停止され、
ｄ）第３のメッセージを送信することによって接続が閉じられる。
【００１１】
さらに本開示は、接続指向の正順デリバリ環境において接続を管理するためのシステムであって、
サーバと、クライアントと、正順デリバリのネットワークと、を備えており、サーバが、上述の方法のうちのサーバに関する動作のいずれかを実行するように構成され、クライアントが、上述の方法のうちのクライアントに関する動作のいずれかを実行するように構成されているシステムを提供する。
【００１２】
本開示は、サーバ、クライアント、ルータなどにおいて本開示の方法のいずれかを実行するためのコンピュータプログラム製品を含む。
【００１３】
さらに本開示は、上述のコンピュータプログラム製品を保存する機械によって読み取ることができる一時的でない信号記憶媒体を含む。例えば、機械によって読み取ることができる一時的でない信号記憶媒体は、ＣＤＲＯＭまたはＤＶＤＲＯＭなどの光ディスク、磁気テープメモリ、ハードディスクまたはディスケットなどの磁気ディスクメモリ、ＵＳＢメモリスティックまたはフラッシュメモリなどの半導体メモリなどであってよい。
【００１４】
本開示の好都合なさらなる実施の形態が、従属請求項に提示される。
【００１５】
好都合なことに、本開示による方法は、メッセージの数を最小限にし、サーバによる第１のメッセージの脱落を防止する。このやり方で、たとえ信頼できるネットワークを使用していても、本方法は、別の接続を処理している等により接続に対応するための利用可能なリソースを有さないビジーサーバを保護する。
【００１６】
好都合には、本開示による方法のさらなる実施の形態によれば、可能な限り短い時間での接続の確立を保証すると同時に、サーバに充分な処理時間を許しつつ最初の送信における第１の種類のメッセージのサーバにおける脱落への対処を保証するために、第１の所定の期間が過ぎた場合にもう１つの第１の種類のメッセージがサーバへと送信される。
【００１７】
好都合には、本開示による方法のさらなる実施の形態によれば、第２の種類のメッセージの受信がクライアントの接続につながる一方で、第４の種類のメッセージの送信が、本方法が信頼性に欠けるネットワークまたはリアルタイムのトラフィッククラスに対応して、確認メッセージが受信された旨をサーバへと知らせることを可能にする。
【００１８】
有益には、サーバからクライアントへの第２の種類のメッセージの形式の本開示の方法のさらなる実施の形態による確認メッセージが、このメッセージの喪失から接続の確立を保護するために、第２の所定の期間を測定する第１のサーバタイマによって守られる一方で、確認メッセージがサーバから受信された旨のクライアントからの確認としての第４の種類のメッセージの受信が、第１のサーバタイマを停止させる。このやり方で、接続の確実な確立が、最小限の数のメッセージで保証される。
【００１９】
好都合には、本開示による方法のさらなる実施の形態によれば、他の接続への対応または他のアプリケーションの高い処理付加に起因してリソースが利用不可能であるがゆえに接続の確立が不可能である場合に、サーバが第５の種類のメッセージを生成し、クライアントへと送信する。このメッセージが、クライアントにおいて受信されたときに、クライアントが接続を閉じることを好都合に可能にし、サーバが利用不可能であるときにクライアントを所定の状態にする方法を提供する。
【００２０】
好都合には、本開示による方法のさらなる実施の形態によれば、第３の所定の期間を測定する第２のクライアントタイマが、第３の種類のメッセージが送信されたときに開始されることで、第３の種類のメッセージへの応答が第３の所定の期間内に受信されない場合に、接続の所定の終了が保証され、適切な対策がとられる。
【００２１】
有益には、本開示による方法のさらなる実施の形態によれば、第３の種類のメッセージの受信を確認し、したがって接続の確立および終了について綿密に構造化された取り扱いおよび管理が保証されていることを確認するために、サーバが第３の種類のメッセージの受信時に第６の種類のメッセージをクライアントへと送信する。
【００２２】
好都合には、本開示による方法のさらなる実施の形態によれば、信頼性に欠けるネットワークまたはリアルタイム通信のためのトラフィッククラスを有するネットワークがメッセージの伝達に使用される場合に、クライアントとの確実な通信を守るために、第６の種類のメッセージの送信によって第２のサーバタイマが開始される。
【００２３】
有益には、本開示の方法のさらなる実施の形態によれば、ひとたびクライアントが第６の種類のメッセージを受信し、したがってサーバが接続を閉じている旨を知ると、第２のクライアントタイマが停止されると同時に、この第６の種類のメッセージの受信を確認するため、ならびにサーバおよびクライアントにおける所定の状態を保証するために、第７の種類のメッセージがサーバへと送信される。
【００２４】
好都合には、本開示の方法のさらなる実施の形態によれば、クライアントおよびサーバの間の通信の柔軟性を高めると同時に、用途またはトラフィッククラスに応じて接続のために要求される帯域幅を定めることができるよう、クライアントおよびサーバの間で交換される任意のメッセージが、ルータを通過することができる。同時に、ルータは、受信したメッセージを、要求された帯域幅が利用できる場合に限って転送する。
【００２５】
好都合には、本開示による方法のさらなる実施の形態によれば、ルータが要求された帯域幅の提供に利用できる場合、クライアントによって指定された（addressed）サーバからの確認メッセージが受信されるまで、他のサーバおよびクライアントからの通信を拒絶しつつ、さらなる帯域幅の割り当てから保護する。このやり方で、帯域幅の割り当てが、存在しうる他の通信相手によるアクセスから保護される。
【００２６】
好都合には、本開示による方法のさらなる実施の形態は、アプリケーションクライアントとアプリケーションサーバとの間に確立される接続を介してデータの交換を提供するために、クライアントがクライアントにおいてメッセージを開始させるアプリケーションクライアントによって対処される一方で、サーバがアプリケーションサーバと通信することで、通信の確立のためのメッセージを交換するクライアントおよびサーバによってアプリケーションサーバとアプリケーションクライアントとの間の通信の確立を可能にする。
【００２７】
好都合には、本開示によるシステムは、本開示による方法の各機能を実行するために、最小限の構成においてサーバ、クライアント、および正順デリバリのネットワークを提供する。
【００２８】
好都合には、本開示によるシステムのさらなる実施の形態は、本開示による方法の実施の形態を利用しつつ、柔軟性を高め、クライアントとサーバとの間の通信距離を伸ばすためのルータを提供する。
【００２９】
好都合には、本開示のシステムのさらなる実施の形態によれば、通信の際に同時には使用されない確認メッセージが、１つのフォーマットのただ１つのメッセージへと節約され、通信の文脈においてサーバまたはクライアントにおいて正しい機能をもたらす。同様に、同時に動作することがないサーバタイマおよびクライアントタイマも、必要なときに作動させられ、本開示およびその実施の形態の方法によるメッセージ交換において第１または第２のサーバまたはクライアントタイマを実現するただ１つのサーバタイマおよびただ１つのクライアントタイマとして実現することができる。
【００３０】
以下で、本開示の実施の形態の例を、図面に示した実施例にもとづいてさらに説明する。
【図面の簡単な説明】
【００３１】
【図１】信頼できるネットワークにおいて生じる典型的なメッセージ交換を示している。
【図２】信頼できるネットワークにおける状態および状態変化の例を説明する状態機械を示している。
【図３】信頼できるネットワークにおけるサーバの状態および状態変化の例を示している。
【図４】信頼性に欠けるネットワークにおける例としてのメッセージの流れを示している。
【図５】信頼性に欠けるネットワークにおけるクライアントの例としての状態および状態変化を示している。
【図６】信頼性に欠けるネットワークにおけるサーバの状態および状態変化の例を示している。
【図７】帯域幅の割り当てを含むサーバ、クライアント、およびルータ間のメッセージの流れの例を示している。
【図８】メッセージがルータを通過するときの信頼性に欠けるネットワークにおけるクライアントとサーバとの間のメッセージの流れの例を示している。
【図９】メッセージの流れにルータを含んでいる信頼性に欠けるネットワークにおけるクライアントの例としての状態および状態変化を示している。
【図１０】メッセージの流れにルータを含んでいる信頼性に欠けるネットワークにおける例としてのサーバの状態および状態変化を示している。
【図１１】信頼性に欠けるネットワークにおけるクライアントとサーバとの間のメッセージの流れに含まれるルータの例としての状態および状態変化を示している。
【図１２】サーバがビジーであるときの信頼性に欠けるネットワークにおけるクライアントとサーバとの間のメッセージ交換の例を示している。
【図１３】第１の種類のメッセージが失われる場合のクライアントとサーバとの間のメッセージ交換の例を示している。
【図１４】第２の種類のメッセージが失われる場合のクライアントとサーバとの間のメッセージ交換の例を示している。
【図１５】サーバアプリケーションがクラッシュした場合のクライアントとサーバとの間のメッセージの流れの例を示している。
【図１６】サーバがビジーである場合の信頼性に欠けるネットワークにおけるクライアントとサーバとの間のメッセージの流れの例を示している。
【図１７】プロトコルエラーが生じる場合のクライアントとサーバとの間のメッセージ交換の例を示している。
【図１８】ルータを含む信頼性に欠けるネットワークにおいて生じる第１のエラーの例を示している。
【図１９】経路にルータを含んでいるクライアントとサーバとの間の通信において生じる例としての第２のエラーを示している。
【図２０】間にルータを有しているクライアントとサーバとの間で生じる通信エラーの第３の例を示している。
【図２１】ルータを通過するメッセージ交換に関し、クライアントとサーバとの間の通信において生じる通信エラーの第４の例を示している。
【図２２】信頼性に欠けるネットワークにおける例としてのさらなるメッセージの流れを示している。
【図２３】信頼性に欠けるネットワークにおける例としての別のメッセージの流れを示している。
【発明を実施するための形態】
【００３２】
本開示を、特定の実施の形態に関して、特定の図面を参照しつつ説明するが、本開示は、これらに限られるわけではなく、特許請求の範囲以外の何ものにも限定されない。説明される図面は、あくまでも概略図であって、本開示を限定するものではない。図面においては、説明の目的のために、一部の構成要素のサイズが誇張され、比例尺では描かれていない。
【００３３】
効率をよくする目的で、図２、図３、図５、図６、図９、図１０、および図１１のような状態機械に関する図面の説明の全体を通じて、状態変化のトリガおよびそれによって生じる事象を説明するために、以下の文法的規則が使用される。
【００３４】
＜トリガ＞／＜アクション＞などの書式が、状態機械における表記に使用される。ここで、＜トリガ＞は、対応するトランザクションへとつながるトリガとして機能する入力トリガのプレースホルダとして機能する。さらに、＜アクション＞は、トランザクションに関連付けられた一式の結果としての事象のプレースホルダとして機能する。
【００３５】
本明細書および特許請求の範囲において、用語「・・・からなる（ｃｏｍｐｒｉｓｉｎｇ）」が使用される場合、他の構成要素または工程が除外されるわけではない。さらに、本明細書および特許請求の範囲において、「第１の」、「第２の」、「第３の」、などといった用語は、類似の構成要素間の区別のために用いられ、必ずしも順番または時系列を表わすために使用されているわけではない。そのように使用される用語が、適切な状況のもとで互いに入れ換え可能であり、本明細書に記載される本開示の実施の形態が、本明細書に記載または例示の順序以外の順序でも機能できることを、理解すべきである。
【００３６】
図１が、信頼できるネットワークにおける本開示の一実施の形態による接続管理のためのメッセージの流れの例を示している。図面の説明の全体を通して、同じ参照符号が、すべての図面において、同じエンティティに使用され、その繰り返しの説明は、効率をよくする目的で省略される。
【００３７】
図１に例示されるとおり、アプリケーションクライアント１０００は、信頼できるネットワークを使用して、クライアント１１００、サーバ１２００、およびアプリケーションサーバ１３００と通信する。ネットワークは、単純なリンクであってよく、あるいは１つ以上のルータを含むことができる。しかしながら、簡単にするために、図１においてはいかなるルータも示されていない。アプリケーションクライアント１０００は、接続の確立を開始するために、「Ｃ＿Ｃｌｏｓｅｄ」の状態１１３０にあるクライアント１１００へ、メッセージ１０１０「Ｔ＿ＯＰＥＮ．ｒｅｑ」を送信する。クライアント１１００において、第１の種類のメッセージ１１４０「Ｔ＿ＳＹＮ」が「Ｓ＿Ｌｉｓｔｅｎ」状態にあるサーバ１２００へ送信された時点で、第１のタイマが開始される。サーバはアプリケーションサーバ１３００へのメッセージ「Ｔ＿ＯＰＥＮ．ｉｎｄ」１３１０を生成し、アプリケーションサーバ１３００がデータを取り扱うことができる場合には、サーバへのメッセージ１３２０「Ｔ＿ＯＰＥＮ．ｒｓｐ」にて応答する。サーバ１２００は、状態１２２０「Ｓ＿ＷａｉｔＲｓｐ」にあるときに第１のサーバタイマを用いて、メッセージ１３１０および１３２０の間の時間間隔を測定する。メッセージ１３２０を受信すると、第２の所定の期間を測定する第１のサーバタイマが停止され、第２の種類のメッセージ１１５０「Ｔ＿ＳＹＮ＿Ａｃｋ」がクライアント１１００へと送信され、クライアント１１００において、メッセージ１１４０が生成されて状態１１２０「Ｃ＿ＷａｉｔＡｃｋ」となったときに開始された第１のクライアントタイマが停止され、メッセージ１０２０「Ｔ＿ＯＰＥＮ．ｃｎｆ」が生成される。今や状態１２３０「Ｓ＿Ｃｏｎｎｅｃｔｅｄ」にあるサーバ１２００に接続が行われる。今やアプリケーションクライアントがデータ送信の要求１０３０「Ｔ＿ＤＡＴＡ．ｒｅｑ」の送信を開始し、これが確認メッセージ１０４０「Ｔ＿ＤＡＴＡ．ｃｎｆＬ」によってクライアント１１００によって確認される。サーバを「Ｓ＿Ｃｏｎｎｅｃｔｅｄ」の状態に、クライアントを「Ｔ＿Ｃｏｎｎｅｃｔｅｄ」の状態に残しつつ、サーバ１２００は送信されたデータ１１６０「Ｔ＿ＤＡＴＡ」を受信し、アプリケーションクライアントからのデータ１３３０「Ｔ＿ＤＡＴＡ．ｉｎｄ」をアプリケーションサーバへと送信し、アプリケーションサーバはメッセージ１３４０「Ｔ＿ＤＡＴＡ．ｒｓｐＬ」によって応答する。
【００３８】
データをメッセージ１３５０「Ｔ＿ＤＡＴＡ．ｒｅｑ」をサーバ１２００へと送信することによってアプリケーションサーバから要求することもでき、このメッセージはメッセージ１１６０「Ｔ＿ＤＡＴＡ」としてクライアント１１００へと転送され、そこからメッセージ「Ｔ＿ＤＡＴＡ．ｉｎｄ」１０５０としてアプリケーションクライアントへとさらに転送され、「Ｃ＿Ｃｏｎｎｅｃｔｅｄ」の状態１１１０にあるクライアント１１００へのメッセージ１０６０「Ｔ＿ＤＡＴＡ．ｒｓｐＬ」によって応答するよう、アプリケーションクライアントを促す。
【００３９】
接続を終わらせるために、アプリケーションクライアントはメッセージ１０７０「Ｔ＿ＣＬＯＳＥ．ｒｅｑ」を送信し、これがクライアント１１００によってメッセージ１０８０「Ｔ＿ＣＬＯＳＥ．ｃｎｆＬ」にて確認されるとともに、クライアント１１００はサーバ１２００への第３の種類のメッセージ１１７０「Ｔ＿ＦＩＮ」を生成し、サーバ１２００はアプリケーション１３００へと接続閉鎖１３７０「Ｔ＿ＣＬＯＳＥ．ｉｎｄ」を知らせることによって応答し、これがサーバ１３００によってメッセージ１３８０「Ｔ＿ＣＬＯＳＥ．ｒｓｐＬ」にて確認され、サーバを状態１２４０「Ｓ＿Ｌｉｓｔｅｎ」に移行させる。あるいは、接続の閉鎖がメッセージ１０７０「Ｔ＿ＣＬＯＳＥ．ｒｅｑ」にてアプリケーションサーバ１３００によって要求され（メッセージ１０８０「Ｔ＿ＣＬＯＳＥ．ｃｎｆＬ」にて確認される）、メッセージ１３７０「Ｔ＿ＣＬＯＳＥ．ｉｎｄ」にて示される（メッセージ１３８０「Ｔ＿ＣＬＯＳＥ．ｒｓｐＬ」にて応答される）場合に、メッセージ１１７０「Ｔ＿ＦＩＮ」を送信することによってサーバ１２００により、接続が閉鎖されてもよい。一般に、これらの実施の形態において説明したそれぞれのメッセージの流れを、サーバおよびクライアントに関して逆にすることができ、すなわちサーバおよびクライアントを入れ替えることができる。
【００４０】
クライアントは状態１１３０「Ｃ＿Ｃｌｏｓｅｄ」のままである。たとえ信頼できるネットワークが通信の基盤を形成している場合であっても、メッセージの処理に利用できるリソースが存在しない場合に、第１の種類のメッセージ１１４０がサーバによって落とされる可能性があるため、メッセージ１１４０および１１５０の間のタイマが必要である。随意により、メッセージ１３１０および１３２０の間でサーバによって運営されて第２の所定の期間を測定するタイマが、通信に必要とされるアプリケーションサーバのアプリケーションがクラッシュまたは他の理由で利用可能になっていないかどうかを監視するために、利用可能である。
【００４１】
便宜上、クライアント１１００は、メッセージ１１４０の送信後に到着する傾向にあるメッセージ１１５０の受信のためのリソースを提供すべきである。このやり方で、好都合なことに、サーバ１２００において、メッセージ１１５０の適切な伝送を監視するためのタイマが不要である。同様に、クライアント１１００および／またはサーバ１２００は、メッセージ１１７０の受信／取り扱いのためのリソースを提供すべきである。このやり方で、メッセージ１１７０の送信者はメッセージ１１７０の伝送損失に対する保護のためのタイマを必要としない。
【００４２】
図２は、図１に示したメッセージの流れに関係する状態機械を、クライアントがとることができる状態および状態変化の例として示している。
【００４３】
本明細書における状態機械の表記をさらに説明するために、例が図２を参照して提示されるが、これは、状態機械を表わす他の図にも同様のやり方で適用可能である。
【００４４】
ここで、図２において、状態１１３０から状態１１２０へのクライアントの移行２１００は、アプリケーションクライアント１０００からのＴ＿ＯＰＥＮ．ｒｅｑ（ｍｙ＿ｓｅｒｖｅｒ）の受信によって引き起こされ、サーバ１２００へのＴ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ）の送信およびクライアント１１００におけるＴｉｍｅｒ＿ＳＹＮの開始にもつながる。これは、上述の表記において、２１００：Ｔ＿ＯＰＥＮ．ｒｅｑ（ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＳＹＮと称される。
【００４５】
他の例として、移行２２００のトリガの事象は、Ｔｉｍｅｒ＿ＳＹＮの時間切れであり、やはりサーバ１２００へのＴ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ）の送信およびクライアント１１００におけるＴｉｍｅｒ＿ＳＹＮの再開につながる。これが、２２００：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿ＳＹＮ／Ｔ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），ｒｅｓｔａｒｔ Ｔｉｍｅｒ＿ＳＹＮと称される。
【００４６】
状態１１３０にあるとき、クライアントは、２１００：Ｔ＿ＯＰＥＮ．ｒｅｑ（ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＳＹＮに対応して、状態１１２０「Ｃ＿ＷａｉｔＳｙｎＡｃｋ」へと移行することができる。クライアントは、２２００：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿ＳＹＮ／Ｔ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），ｒｅｓｔａｒｔ Ｔｉｍｅｒ＿ＳＹＮに対応して状態１１２０のままである一方で、状態１１３０への再移行が、２１５０：Ｔ＿ＳＹＮ＿ＥＲＲ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＯＰＥＮ．ｃｎｆ（ｅｒｒｏｒ），ｓｔｏｐ Ｔｉｍｅｒ＿ＳＹＮに従って生じる。状態１１２０から状態１１１０「Ｃ＿Ｃｏｎｎｅｃｔｅｄ」への移行が、２３００：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＯＰＥＮ．ｃｎｆ（ｏｋ），ｓｔｏｐ Ｔｉｍｅｒ＿ＳＹＮまたは２３００： Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＯＰＥＮ．ｃｎｆ（ｏｋ），ｓｔｏｐ Ｔｉｍｅｒ＿ＳＹＮ， Ｔ＿ＤＡＴＡ．ｉｎｄに従って生じる一方で、クライアントは、２４００：Ｔ＿ＤＡＴＡ．ｒｅｑ／Ｔ＿ＤＡＴＡ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ）または２４００：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＤＡＴＡ．ｉｎｄに対応して状態１１１０にとどまり、２５００：Ｔ＿ＣＬＯＳＥ．ｒｅｑ（）／Ｔ＿ＣＬＯＳＥ．ｃｎｆ，Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｒｅｖｅｒ）によって状態１１３０へと移行する。
【００４７】
図３は、図１に示したメッセージの流れの文脈においてサーバがとることができる状態および状態変化の例としての状態機械を示している。
【００４８】
状態「Ｓ＿ＷａｉｔＣｌｏｓｅＲｓｐＥ」３２２０、状態３４２０「Ｓ＿Ｅｒｒｏｒ」、状態１２２０「Ｓ＿ＷａｉｔＯｐｅｎＲｓｐ」、状態１２３０「Ｓ＿Ｃｏｎｎｅｃｔｅｄ」、ならびにさらなる状態３３２０「Ｓ＿ＷａｉｔＣｌｏｓｅＲｓｐ」および状態１２１０「Ｓ＿Ｌｉｓｔｅｎ」が示されている。
【００４９】
状態１２１０から状態１２２０への移行は、３３５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＯＰＥＮ．ｉｎｄ（ｍｙ＿ｃｌｉｅｎｔ），ｓｔａｒｔ Ｔｉｍｅｒ＿ Ｒｓｐによって生じ、状態１２２０から３４２０への移行は、３２００：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿Ｒｓｐ／ｓｔｏｐ Ｔｉｍｅｒ＿Ｒｓｐ，Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）によって生じ、状態１２２０から状態１２３０への移行は、３３００：Ｔ＿ＯＰＥＮ．ｒｓｐ（）／ｓｔｏｐ Ｔｉｍｅｒ＿Ｒｓｐ，Ｔ＿ＳＹＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）に対応して生じる。状態３４２０から状態３２２０への状態変化は、３１００：Ｔ＿ＯＰＥＮ．ｒｓｐ（）／Ｔ＿ＣＬＯＳＥ．ｉｎｄ（）に従って生じる。
【００５０】
さらなる移行が、３４５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＣＬＯＳＥ．ｉｎｄ（）に対応して状態１２３０から３３２０へと生じ、３５５０：Ｔ＿ＣＬＯＳＥ．ｒｓｐ／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）によって状態３３２０から状態１２１０へと生じる。状態１２１０は、最初に事象３６５０：Ｔ＿ＬＩＳＴＥＮ．ｒｅｑ／−によってトリガされる。サーバは、移行３１５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）に従って状態３４２０にとどまる。サーバは、移行３４００：Ｔ＿ＤＡＴＡ．ｒｅｑ（ｄａｔａ）／Ｔ＿ＤＡＴＡ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）または３４００：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）／Ｔ＿ＤＡＴＡ．ｉｎｄ（ｄａｔａ）または３４００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）または３４００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）に従って状態１２３０にとどまる。サーバは、移行３５００：Ｔ＿ＤＡＴＡ．ｒｅｑ（ｄａｔａ）／Ｔ＿ＤＡＴＡ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）または３５００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）に従って状態３３２０にとどまる。
【００５１】
例えば、状態３３２０において、サーバは依然としてデータを送信することができるが、クライアントからそれ以上のデータは受信しない。
【００５２】
図４は、レイヤ２の再送信の数に制限があるネットワークなど、信頼性を欠くネットワークにおいて生じる本開示による実施の形態のメッセージの流れの例を示している。
【００５３】
図１との比較において容易に特定できるとおり、交換されるメッセージの多くは同じである。この事実ゆえ、信頼できるネットワークにおいて必要とされるメッセージを、信頼性に欠けるネットワークにおける接続の確立に必要なメッセージから隔てる、メッセージの流れにおける相違に注目する。信頼性に欠けるネットワークの場合には、好ましくは、追加のタイマおよびメッセージが、信頼性の欠如を補償し、かつ、接続の確立を確実にするために、用意される。この場合、クライアント１１００が、第４の種類のメッセージ４１５０「Ｔ＿ＡＣＫ＿ＡＣＫ」を生成する。この第４の種類のメッセージは、信頼性に欠けるネットワークの場合に用意され、第２の種類のメッセージ１１５０の適切な伝達を監視するためのメッセージの流れを実行する。第４の種類のメッセージの適切かつ時機を得た伝達は、サーバ１２００が状態７５１０「Ｓ＿ＷａｉｔＳｙｎＡｃｋ」にある間に、サーバ１２００において動作する第２のサーバタイマによって判断される。この場合には、クライアントが、第４の種類のメッセージ４１５０の送信後に状態４１１０「Ｃ＿Ｃｏｎｎｅｃｔｅｄ」に移行する。
【００５４】
このメッセージの流れの他の特徴は、接続の終了にあり、接続の終了の際の第３のメッセージ１１７０への適切な応答が、クライアント自身が状態４１１０「Ｃ＿ＷａｉｔＦｉｎＡｃｋ」にあるときにタイマによって監視される。ひとたび接続の終了を確認する第６の種類のメッセージ４１７０「Ｔ＿ＦＩＮ＿ＡＣＫ」がサーバ１２００から受信されると、第２のクライアントタイマが停止される。
【００５５】
信頼性に欠けるネットワークにもとづくメッセージの伝達の場合には、リンクがパケットを破棄する可能性がある。これは、メッセージのデリバリ時間を拘束する、例えば０または１の再送信の境界数を有するトラフィッククラスの場合かもしれない。この手順ゆえ、メッセージの一部分または全体が失われることがあり、あるいはメッセージが、ペイロードに既知のエラーがある状態で、届けられることがある。したがって、接続管理メッセージも、処理されずに捨てられる可能性がある。ここで、特に、サーバからの第２の種類のメッセージ１１５０を、好ましくは保護すべきである。なぜならば、喪失ゆえのエラーの場合、サーバが最初にビジーであり、そして、第２の種類のメッセージ１１５０を利用できるようになった後に、「Ｓ＿Ｃｏｎｎｅｃｔｅｄ」の状態１２３０のままになる可能性があるからである。
【００５６】
これは、サーバが接続されていると思い込み、接続されておらず、したがってデータの受信の準備ができていないクライアントへ、データの送信を開始するという事例につながりかねない。
【００５７】
図５は、図４に示したメッセージの流れに関連したクライアントにおける状態および状態間の移行の例を示す状態機械を示している。
【００５８】
この場合、この実施の形態に示される、信頼性に欠けるネットワークに存在する状況が、図２に示した信頼できるネットワークにおけるクライアントと比較した相違点として、接続「Ｃ＿ＷａｉｔＦｉｎＡｃｋ」の終了の文脈における状態４１１０の追加を示している。さらなる状態は、１１１０「Ｃ＿Ｃｏｎｎｅｃｔｅｄ」、１１３０「Ｃ＿Ｃｌｏｓｅｄ」、５１２０「Ｃ＿ＷａｉｔＳｙｎＡｃｋ」、および５６５０「Ｃ＿ＷａｉｔＣｌｏｓｅＲｓｐ」である。
【００５９】
状態１１３０から状態５１２０の移行は、５１５０：Ｔ＿ＯＰＥＮ．ｒｅｑ（ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｅｖｅｒ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＳＹＮに対応する。状態５１２０から状態１１１０への移行は、５２５０：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＡＣＫ＿ＡＣＫ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），Ｔ＿ＯＰＥＮ．ｃｎｆ（ｏｋ），ｓｔｏｐ Ｔｉｍｅｒ＿ＳＹＮに対応して生じる。状態１１１０から状態４１１０へは、移行５４５０：Ｔ＿ＣＬＯＳＥ．ｒｅｑ（）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｒｅｖｅｒ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＦＩＮに対応する。５３００：Ｔ＿ＳＹＮ＿ＥＲＲ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＦＩＮに従って、状態５１２０から状態４１１０に達することも可能である。状態４１１０から状態１１３０は、移行５５５０：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＣＬＯＳＥ．ｃｎｆ（），ｓｔｏｐ Ｔｉｍｅｒ＿ＦＩＮ、移行５５５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），Ｔ＿ＣＬＯＳＥ．ｃｎｆ（），ｓｔｏｐ Ｔｉｍｅｒ＿ＦＩＮによる。状態１１１０から状態５４２０は、移行５４６０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＣＬＯＳＥ．ｉｎｄ（）による。状態５４２０から状態１１３０は、移行５６６０：Ｔ＿ＣＬＯＳＥ．ｒｓｐ（）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）による。
【００６０】
移行５１００：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ａｎｙ＿ｓｅｒｖｅｒ）／−、移行５１００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ａｎｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）、移行５２００：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ａｎｙ＿ｓｅｒｖｅｒ）／−、移行５２００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ａｎｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）、移行５２００：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿ＳＹＮ／Ｔ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），ｒｅｓｔａｒｔ Ｔｉｍｅｒ＿ＳＹＮ、移行５４００：Ｔ＿ＤＡＴＡ．ｒｅｑ／Ｔ＿ＤＡＴＡ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ）、移行５４００：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＤＡＴＡ．ｉｎｄ、移行５４００：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）／−、移行５４００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行５４００：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＡＣＫ＿ＡＣＫ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ）、ならびに移行５５００：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ）、移行５５００：Ｔ＿ＳＹＮ＿ＥＲＲ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ）、移行５５００：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）／−、移行５５００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行５５００：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿ＦＩＮ／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），ｒｅｓｔａｒｔ Ｔｉｍｅｒ＿ＦＩＮ、移行５６５０：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）／−、および移行５６５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）のそれぞれの場合、それぞれの状態１１３０、５１２０、１１１０、および４１１０が維持される。
【００６１】
状態５１２０の場合において、第２の種類のメッセージ１１５０、あるいはエラーメッセージが受信される場合、それらは第３の種類のメッセージ１１７０によって応答される。この場合、第２のクライアントタイマが再開される。この場合には、両方のクライアントタイマが、例えば相互に排他的であり、したがって両方の機能をとる単一のタイマとして実現することができる。
【００６２】
図６が、図４に示したとおりの信頼性に欠けるネットワークの通信状況におけるサーバ１２００の状態および状態間の移行の例を示す状態機械を示している。
【００６３】
ここで、信頼できるネットワークを利用するサーバの状況との比較において、やはり第４の種類のメッセージ４１５０がクライアント１１００からの確認として受信される。同様に、第６の種類のメッセージ４１７０が発せられる。
【００６４】
図６において、状態６５５０「Ｓ＿Ｅｒｒｏｒ」および状態１２４０「Ｓ＿Ｌｉｓｔｅｎ」ならびに状態６２２０「Ｓ＿ＷａｉｔＯｐｅｎＲｓｐ」および状態６６２０「Ｓ＿ＷａｉｔＳｙｎＡｃｋ」とともに、状態６５２０「Ｓ＿ＷａｉｔＣｌｏｓｅＲｓｐＥ」が示されている。さらに、状態１２３０「Ｓ＿Ｃｏｎｎｅｃｔｅｄ」、状態６４２０「Ｓ＿ＷａｉｔＣｌｏｓｅＲｓｐ」、および状態４１１２「Ｓ＿ＷａｉｔＦｉｎＡｃｋ」も示されている。
【００６５】
状態１２４０は、６８００：Ｔ＿ＬＩＳＴＥＮ．ｒｅｑ／−によって開始され、６７５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）または６７５０：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／−の場合に維持される。そこからの状態６２２０への移行は、６８５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＯＰＥＮ．ｉｎｄ（ｍｙ＿ｃｌｉｅｎｔ），ｓｔａｒｔ Ｔｉｍｅｒ＿Ｒｓｐに従って生じ、状態６２２０は、６３００： Ｔ＿ＦＩＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）または６３００：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−の場合に維持される。そこから、６２５０：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿Ｒｓｐ／ｓｔｏｐ Ｔｉｍｅｒ＿Ｒｓｐ，Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）の場合に状態６５５０に到達でき、状態６５５０は、６１５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）、６１５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）、または６１５０：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／−に対応して維持される。この状態６５５０から、６２００：Ｔ＿ＯＰＥＮ．ｒｓｐ（）／Ｔ＿ＣＬＯＳＥ．ｉｎｄ（）によって状態６５２０に到達でき、状態６５２０は、６１００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）、６１００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）、または６１００：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／−に従って維持される。
【００６６】
状態６２２０から状態６６２０への別の移行が、６３５０：Ｔ＿ＯＰＥＮ．ｒｓｐ（）／ｓｔｏｐ Ｔｉｍｅｒ＿Ｒｓｐ，Ｔ＿ＳＹＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＡＣＫに対応して生じる。それぞれの状態が、移行６４００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）、移行６４００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行６４００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行６４００：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−、または移行６４００：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿ＡＣＫ／Ｔ＿ＳＹＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ），ｒｅｓｔａｒｔ Ｔｉｍｅｒ＿ＡＣＫに対応して維持され、ここから６４５０：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／ｓｔｏｐ Ｔｉｍｅｒ＿ＡＣＫまたは６４５０：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）／ｓｔｏｐ Ｔｉｍｅｒ＿ＡＣＫ，Ｔ＿ＤＡＴＡ．ｉｎｄ（ｄａｔａ）に従って状態１２３０が到達され、状態１２３０が、トランザクション６５５５：Ｔ＿ＤＡＴＡ．ｒｅｑ（ｄａｔａ）／Ｔ＿ＤＡＴＡ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）、トランザクション６５５５：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）／Ｔ＿ＤＡＴＡ．ｉｎｄ（ｄａｔａ）、トランザクション６５５５：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−、トランザクション６５５５：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、トランザクション６５５５：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、または移行６５５５：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−によって維持される。ここから、状態６４２０が６６００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＣＬＯＳＥ．ｉｎｄ（）に対応してとられ、移行６６５０：Ｔ＿ＤＡＴＡ．ｒｅｑ（ｄａｔａ）／Ｔ＿ＤＡＴＡ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）、移行６６５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／−、移行６６５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行６６５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、または移行６６５０：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−に従って維持される。次いで、６７００：Ｔ＿ＣＬＯＳＥ．ｒｓｐ／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）に対応する初期状態１２４０への移行が生じることで、この状態を離れることができる。
【００６７】
状態６５５５から状態６６４０への移行は、６６１０：Ｔ＿ＣＬＯＳＥ．ｒｅｑ（）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＦＩＮに対応する。状態４１１２から状態１２４０への移行は、６６４５：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＣＬＯＳＥ．ｃｎｆ（），ｓｔｏｐ Ｔｉｍｅｒ＿ＦＩＮおよび６６４５：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏＬｍｙ＿ｃｌｉｅｎｔ），Ｔ＿ＣＬＯＳＥ．ｃｎｆ（），ｓｔｏｐ Ｔｉｍｅｒ＿ＦＩＮに対応する。状態４１１２は、移行６６４０：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）、移行６６４０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行６６４０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行６６４０：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−、ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿ＦＩＮ／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ），ｒｅｓｔａｒｔ Ｔｉｍｅｒ＿ＦＩＮ、またはＴ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）／−に従って維持される。
【００６８】
状態６６２０から状態１２４０への他の移行は、６５００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）に対応して生じる。
【００６９】
図において、用語「ｍｙ＿ｃｌｉｅｎｔ」がアプリケーションクライアントを指す一方で、用語「ｍｙ＿ｓｅｒｖｅｒ」はアプリケーションサーバを指す。
【００７０】
図７が、クライアントとサーバとの間で交換されるメッセージがルータによって転送される本開示による方法の実施の形態の例を示している。この方法は、接続の確立の前に、接続のための帯域幅の予約および利用可能な帯域幅の確認を、好都合に適用する。このメッセージの図と、図４の信頼できるネットワークにおける接続管理を示したメッセージの流れを示す図との間の主たる相違点は、ルータがクライアント１１００とサーバ１２００との間に存在する場合に、ルータが図４においてクライアント１１００とサーバ１２００との間で交換されるメッセージを転送し、好都合には帯域幅の割り当てまたは帯域幅の見積りを実行し、それぞれの接続に要求される帯域幅の利用可能性を確認することにある。詳しくは、ここではルータ７５００が新規であり、それぞれの状態７５１０「Ｒ＿Ｒｅａｄｙ」および７５３０「Ｒ＿Ｂｕｓｙ」をとる。さらに、先の図において説明したメッセージ書式と比較して、第１の種類のメッセージのメッセージ書式が帯域幅の要求を含んでおり、したがって参照番号７１４０「Ｔ＿ＳＹＮ（ｂｗ）」によって指し示されている。また、第３の種類のメッセージのメッセージ書式が、今や好ましくは帯域幅の要求を含んでおり、したがって別の参照番号７１７０「Ｔ＿ＦＩＮ（ｂｗ）」によって指し示されている。ここで、クライアント１０００とサーバ１１００との間のルータ７５００が、例えば１または複数の帯域幅パラメータを使用し、リンクの帯域幅の一部がすでに他の接続のために予約されている可能性に鑑みて、要求された帯域幅がリンクの能力に適合するか否かを見積り、帯域幅の予約に成功した場合に、第１の種類のメッセージを転送し、そうでない場合には、例えばクライアント１０００またはサーバ１１００へと通信されるエラーを生成する。さらに、好都合には、ルータが、ルータがビジーであることを示す状態７５３０に入り、この状態においては、他の接続のための他の帯域幅の予約の要求を受け付けない。
【００７１】
ひとたび、ルータが第２の種類のメッセージ（同一ペアのクライアントおよびサーバに対して、サーバ１１００からクライアント１０００へ転送される確認であって、すべての含まれるルータが要求された帯域幅の予約に成功したことを確認するもの）を識別すると、レディ状態７５１０へと戻る。「Ｒ＿Ｂｕｓｙ」状態７５３０は、例えば第１の種類のメッセージ７１４０について生じうる再送信を排除するために必要とされ、ルータにおける帯域幅の予約の二重の更新を好都合に防止する。さらに、先の図との比較において、接続は第３の種類のメッセージ７１７０によって終了させられる。ここで、第３の種類のメッセージは、例えばクライアント１０００および第３の種類のメッセージ７１７０を発するサーバ１１００に保存された第１の種類のメッセージ７１４０と同じ帯域幅パラメータを含んでいる。第３の種類のメッセージ７１７０の受信の結果として、ルータ７５００は、自身の予約済みの帯域幅を減らす。メッセージの交換が信頼できるネットワークにもとづいて行われる場合、この動作が失敗する可能性はない。したがって第３の種類のメッセージ７１７０が失われる可能性はなく、したがってこの場合には、好ましくはこのメッセージの適切な取り扱いを確認するためのタイマは不要である。ルータにおける見積りのプロセスおよび保存のプロセスが、四角い囲み７５２０によって示されている。
【００７２】
図８が、メッセージの交換が信頼性に欠けるネットワークまたはリアルタイムの通信のためのトラフィッククラスをサポートしているネットワークにおいて行われる場合の本開示による方法の実施の形態のメッセージの流れの別の例を示している。
【００７３】
図４に示したメッセージの流れと比べて、やはり先のメッセージの流れと同様に、このメッセージの流れは、クライアント１０００とサーバ１１００との間で交換されるメッセージを転送するためのルータ７５００を備えている。すでに説明したように、信頼性に欠けるネットワークをサポートする図４におけるメッセージの流れをさらに詳しく述べるとき、好ましくはクライアント１０００とサーバ１１００との間で交換されるメッセージのより密接な監視およびルータ７５００における予防措置が必要である。
【００７４】
ここで、やはり第４の種類のメッセージ４１５０が、接続の終了の過程において必要とされる。理由は、３つのメッセージを必要とするあらゆるルータの更新の要件にある。３つのめっせーざいとは、第１の種類のメッセージ７１４０および第３の種類のメッセージ７１７０などの帯域幅を運ぶ通信を初期化する１つのメッセージと、メッセージ１１５０およびメッセージ８１５０「Ｔ＿ＦＩＮ＿ＡＣＫ」などの第１の種類のメッセージを確認する第２のメッセージと、メッセージ４１５０などの帯域幅の変更を委ねるための第３のメッセージと、である。この場合において、ルータがビジーであり、あるいは帯域幅の変更を支持できない場合に、ルータ７５００は「Ｒ＿Ｂｕｓｙ」を示す７５３０へと自身の状態を変化させ、空きの帯域幅が不充分である場合に、ルータはさらに後述されるように「Ｓ＿Ｅｒｒｏｒ」メッセージを生成する。ここで、帯域幅の割り当ておよび見積りは、ルータ７５００における四角囲み８５５０によってさらに示されている。
【００７５】
図９が、クライアント側から観察される図７のメッセージフローに関係する状態機械の例として状態および状態変化を示している。
【００７６】
ここで、以下の状態７１２０、１１１０、４１１０、および１１３０が可能である。
【００７７】
状態１１３０から状態７１２０への状態移行が、９１５０：Ｔ＿ＯＰＥＮ．ｒｅｑ（ｍｙ＿ｓｅｒｖｅｒ，ｂｗ）／ｃｏｎｎ＿ｂｗ＝ｂｗ，Ｔ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ，ｂｗ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＳＹＮに対応して生じる一方で、状態７１２０から状態４１１０への状態移行は、９３００：Ｔ＿ＳＹＮ＿ＥＲＲ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ，ｃｏｎｎ＿ｂｗ）に対応して可能である。他方で、クライアントについて、状態７１２０から状態１１１０への移行が、９２５０：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＡＣＫ＿ＡＣＫ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），Ｔ＿ＯＰＥＮ．ｃｎｆ（ｏｋ），ｓｔｏｐ Ｔｉｍｅｒ＿ＳＹＮに従って生じる。おそらくは状態１１１０および状態４１１０の間のさらなる移行が、９４００：Ｔ＿ＣＬＯＳＥ．ｒｅｑ（）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ，ｃｏｎｎ＿ｂｗ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＦＩＮに対応してさらに存在する。移行９１００：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ａｎｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＡＣＫ＿ＡＣＫ（ｔｏ：ａｎｙ＿ｓｅｒｖｅｒ）、移行９２００：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ａｎｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＡＣＫ＿ＡＣＫ（ｔｏ：ａｎｙ＿ｓｅｒｖｅｒ）、移行９２００：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿ＳＹＮ／Ｔ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ，ｃｏｎｎ＿ｂｗ），ｒｅｓｔａｒｔ Ｔｉｍｅｒ＿ＳＹＮ、移行９３５０：Ｔ＿ＤＡＴＡ．ｒｅｑ／Ｔ＿ＤＡＴＡ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ）、移行９３５０：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＤＡＴＡ．ｉｎｄ、移行９３５０：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）／Ｔ＿ＡＣＫ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）、移行９３５０：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＡＣＫ＿ＡＣＫ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ）、および移行９４５０：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ，ｂｗ）、移行９４５０：Ｔ＿ＳＹＮ＿ＮＡＣ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ，ｂｗ）、移行９４５０：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）／Ｔ＿ＡＣＫ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）、移行９４５０：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿ＦＩＮ／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ，ｃｏｎｎ＿ｂｗ），ｒｅｓｔａｒｔ Ｔｉｍｅｒ＿ＦＩＮの場合、それぞれの状態（それぞれ、１１３０、７１２０、９３５０、および９４５０）が維持される。
【００７８】
ここで、帯域幅の予約が接続の管理に追加される場合、好ましくは必要な帯域幅の要件が、パラメータとしてメッセージ１０１０に与えられる。例えば、帯域幅は、例えばリンクの使用割合などの代案の代わりに生の帯域幅にて表現されてよく、例えばクライアントからサーバへの方向および逆のサーバからクライアントへの方向の各々について異なる値を含むことができる。さらに、より手の込んだ帯域幅の表現も可能である。例えば、ハードな保証が提供される専用の帯域幅およびソフトな保証しか提供されない共有の帯域幅である。さらに、この帯域幅または一式の帯域幅パラメータが、第１の種類のメッセージ７１４０および第３の種類のメッセージ７１７０にも加えられる。帯域幅は、例えばメッセージ１０１０の受信時に接続の帯域幅として保存され、その後に第１の種類のメッセージ７１４０および第３の種類のメッセージ７１７０の両方に使用される。第４の種類のメッセージ４１５０が、ルータ７５００における正しい帯域幅の更新を保証する。改善として、第３の種類のメッセージ７１７０の帯域幅パラメータが０である場合、第４の種類のメッセージ４１５０を省略することができる。
【００７９】
図１０が、図８のメッセージの流れにおいて説明した本開示による方法の実施の形態においてサーバがとることができる状態および状態変化を示す状態機械の例を示している。
【００８０】
この状態機械が、以下の状態および状態変化、すなわち１００１０「Ｓ＿ＷａｉｔＣｌｏｓｅＲｓｐ」、１００２０「Ｓ＿Ｅｒｒｏｒ」、１２４０、１００３０「Ｓ＿ＷａｉｔＯｐｅｎＲｓｐ」、７５１０、８５６０、１２３０、および１００４０「Ｓ＿ＷａｉｔＣｌｏｓｅＲｓｐ」を有している。
【００８１】
状態１２４０が１０１００：Ｔ＿ＬＩＳＴＥＮ．ｒｅｑ／−によって開始され、状態１００３０への移行が、１０１５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｂｗ）／Ｔ＿ＯＰＥＮ．ｉｎｄ（ｍｙ＿ｃｌｉｅｎｔ），ｓｔａｒｔ Ｔｉｍｅｒ＿ Ｒｓｐに対応して生じる。状態１００３０から状態１００２０への移行が、１０２００：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿Ｒｓｐ／ｓｔｏｐ Ｔｉｍｅｒ＿Ｒｓｐ，Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）によって生じ、ここから状態１００１０への移行が、１０３００：Ｔ＿ＯＰＥＮ．ｒｓｐ（）／Ｔ＿ＣＬＯＳＥ．ｉｎｄ（）に対応して生じる。
【００８２】
さらに、状態１００３０および状態７５１０の間の状態移行が、１０４５０：Ｔ＿ＯＰＥＮ．ｒｓｐ（）／ｓｔｏｐ Ｔｉｍｅｒ＿Ｒｓｐ，Ｔ＿ＳＹＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＡＣＫに対応して生じる。
【００８３】
さらに、そこから状態１２３０への移行が、移行１０６００：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／ｓｔｏｐ Ｔｉｍｅｒ＿ＡＣＫおよび移行１０６００：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）／ｓｔｏｐ Ｔｉｍｅｒ＿ＡＣＫ，Ｔ＿ＤＡＴＡ．ｉｎｄ （ｄａｔａ）に従って可能であり、状態７５１０から状態８５６０へと、１０５５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｂｗ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＡＣＫに従って可能である。さらに、状態１２３０から状態１００４０への状態移行が、１０７００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｂｗ）／Ｔ＿ＣＬＯＳＥ．ｉｎｄ（）によって生じる。そこから、状態８５６０へのさらなる状態移行が、１０８００：Ｔ＿ＣＬＯＳＥ．ｒｓｐ／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＡＣＫに従って可能であり、再び出発点へと状態８５６０から状態１２４０への移行が、１０８５０：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／ｓｔｏｐ Ｔｉｍｅｒ＿ＡＣＫに従って可能である。
【００８４】
それぞれの状態（それぞれ、１００１０、１００２０、１２４０、１００３０、７５１０、１２３０、および１００４０）が、移行１０３５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ，ｂｗ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）、移行１０３５０：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／−、移行１０２５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ，ｂｗ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）、移行１０２５０：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−、移行１０９００：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／−、移行１０４００：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−、移行１０５００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｂｗ）／Ｔ＿ＳＹＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）、移行１０５００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ，ｂｗ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行１０５００：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−、移行１０５００：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿ＡＣＫ／Ｔ＿ＳＹＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ），ｒｅｓｔａｒｔ Ｔｉｍｅｒ＿ＡＣＫ、移行１０６５０：Ｔ＿ＤＡＴＡ．ｒｅｑ（ｄａｔａ）／Ｔ＿ＤＡＴＡ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）、移行１０６５０：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）／Ｔ＿ＤＡＴＡ．ｉｎｄ（ｄａｔａ），移行１０６５０：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−、移行１０６５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ，ｂｗ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行１０６５０：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−、および移行１０７５０：Ｔ＿ＤＡＴＡ．ｒｅｑ（ｄａｔａ）／Ｔ＿ＤＡＴＡ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）、移行１０７５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｂｗ）／−、移行１０７５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ，ｂｗ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行１０７５０：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−に対応して維持される。また、状態１００１０から状態１２４０への移行が、１０９５０：Ｔ＿ＣＬＯＳＥ．ｒｓｐ／−に従って生じる。
【００８５】
さらに、例えばサーバが、第１の種類のメッセージ７１４０および第３の種類のメッセージ７１７０について、帯域幅パラメータをさらに受信する。状態８５６０が、好ましくはサーバによる第４の種類のメッセージ４１５０の待機を生じさせるために、導入される。好ましくは、第６の種類のメッセージ４１７０の送信時に開始され、時間切れの場合に再送信を生じさせるタイマによって、第６の種類のメッセージ４１７０も確実な送信に保護される。サーバにおけるすべてのタイマは、並行して動作することがないため、好ましくは１つのタイマにて好都合に実現することができる。
【００８６】
図１１が、図８に示して説明した本開示による方法の実施の形態においてルータがとることができる状態および状態変化についての状態機械の例を示している。
【００８７】
以下の状態、すなわち７５１０、１１５４０「Ｒ＿Ｂｕｓｙ＿Ｆｉｎ」、および１１５３０「Ｒ＿Ｂｕｓｙ＿Ｓｙｎ」が、例えば可能である。
【００８８】
状態７５１０の開始が、１１１００：Ｒ＿ｂｗ＝０，ｅｒｒ＿ｆｌａｇ＝ｆａｌｓｅに従って生じる。ここから、状態１１５４０への状態変化が、１１４００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｃｌｉｅｎｔ，ｔｏ：ｓｅｒｖｅｒ，ｂｗ）／Ｒ＿ｃｌｉｅｎｔ＝ｃｌｉｅｎｔ，Ｒ＿ｓｅｒｖｅｒ＝ｓｅｒｖｅｒ，Ｒ＿ｂｗ−＝ｂｗ，Ｔ＿ＦＩＮ（ｆｒｏｍ：ｃｌｉｅｎｔ，ｔｏ：ｓｅｒｖｅｒ，ｂｗ）に対応して生じる。状態１１５４０から戻る移行が、１１５００：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ）／ｅｒｒ＿ｆｌａｇ＝ｆａｌｓｅ，Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ）に対応して生じることができる。また、状態７５１０から状態１１５３０への状態変化が、移行１１２００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｃｌｉｅｎｔ，ｔｏ：ｓｅｒｖｅｒ，ｂｗ），（Ｒ＿ｂｗ＋ｂｗ）≦ＭＡＸ＿ＢＷ／Ｒ＿ｃｌｉｅｎｔ＝ｃｌｉｅｎｔ，Ｒ＿ｓｅｒｖｅｒ＝ｓｅｒｖｅｒ，Ｒ＿ｂｗ＋＝ｂｗ，Ｔ＿ＳＹＮ（ｆｒｏｍ：ｃｌｉｅｎｔ，ｔｏ：ｓｅｒｖｅｒ，ｂｗ）、または移行１１２００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｃｌｉｅｎｔ，ｔｏ：ｓｅｒｖｅｒ，ｂｗ），（Ｒ＿ｂｗ＋ｂｗ）＞ＭＡＸ＿ＢＷ／Ｒ＿ｃｌｉｅｎｔ＝ｃｌｉｅｎｔ，Ｒ＿ｓｅｒｖｅｒ＝ｓｅｒｖｅｒ，ｅｒｒ＿ｆｌａｇ＝ｔｒｕｅ，Ｔ＿ＳＹＮ＿ＥＲＲ（ｆｒｏｍ：ｃｌｉｅｎｔ，ｔｏ：ｓｅｒｖｅｒ）に対応して生じることができ、状態１１５３０から出発点への状態変化が、１１３５０：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ）／ｅｒｒ＿ｆｌａｇ＝ｆａｌｓｅ，Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ）に対応して生じることができる。状態１１５３０および１１５４０の間の他の状態変化が、１１３００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｃｌｉｅｎｔ，ｔｏ：ｓｅｒｖｅｒ，ｂｗ）／Ｔ＿ＦＩＮ（ｆｒｏｍ：ｃｌｉｅｎｔ，ｔｏ：ｓｅｒｖｅｒ，ｂｗ）に対応して生じる。
【００８９】
それぞれの状態（それぞれ、７５１０、１１５４０、および１１５３０）は、移行１１１５０：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２）／Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２）、移行１１１５０：ＯＴＨＥＲ＿ＭＳＧ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２，．．．）／ＯＴＨＥＲ＿ＭＳＧ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２，．．．）、移行１１４５０：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：Ｒ＿ｓｅｒｖｅｒ，ｔｏ：Ｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：Ｒ＿ｓｅｒｖｅｒ，ｔｏ：Ｒ＿ｃｌｉｅｎｔ）、移行１１４５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ，ｂｗ）／Ｔ＿ＦＩＮ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ，ｂｗ）、移行１１４５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ，ｔｏ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ，ｂｗ）／−、移行１１４５０：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２）／Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２）、または移行１１４５０：ＯＴＨＥＲ＿ＭＳＧ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２，．．．）／ＯＴＨＥＲ＿ＭＳＧ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２，．．．）、ならびに移行１１２５０：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｓｅｒｖｅｒ，ｔｏ：ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｓｅｒｖｅｒ，ｔｏ：ｃｌｉｅｎｔ）、移行１１２５０：Ｔ＿ＳＹＮ＿ＥＲＲ（ｆｒｏｍ：ｓｅｒｖｅｒ，ｔｏ：ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｆｒｏｍ：ｓｅｒｖｅｒ，ｔｏ：ｃｌｉｅｎｔ）、移行１１２５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ，ｂｗ）＆＆（ｅｒｒ＿ｆｌａｇ＝＝ｆａｌｓｅ）／Ｔ＿ＳＹＮ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ，ｂｗ）、移行１１２５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ，ｂｗ）＆＆（ｅｒｒ＿ｆｌａｇ＝＝ｔｒｕｅ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ）、移行１１２５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ，ｔｏ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ，ｂｗ）／−、移行１１２５０：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２）／Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２）、または移行１１２５０：ＯＴＨＥＲ＿ＭＳＧ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２，．．．）／ＯＴＨＥＲ＿ＭＳＧ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２，．．．）に従って維持される。
【００９０】
例えば、ルータは、接続の開放および閉鎖のプロセス間の状態を集めなければならない。デフォルトの状態は、ルータがレディである状態７５１０であり、そこからパケットをそれぞれの宛て先へと転送する。しかしながら、ルータが第１の種類のメッセージ７１４０または第３の種類のメッセージ７１７０を受信する場合、好ましくはルータの帯域幅の予約が更新され、これを行う際に、ルータが状態１１５３０および１１５４０へとそれぞれ移行する。ルータが初期の状態７５１０にあり、割り当てるための充分な帯域幅を有するメッセージ７１４０を受信する場合、それは帯域幅を更新し、メッセージをサーバへと転送する。他方で、利用できる帯域幅が不充分である場合、ルータは、帯域幅の更新を防止するためにｅｒｒｏｒ＿ｆｌａｇを発し、メッセージ７１４０の転送の代わりにエラーメッセージがサーバへと設定される。好ましくは、ｅｒｒｏｒ＿ｆｌａｇを接続を閉じるときに帯域幅の更新を防止するために使用することができる。いずれの場合も、接続の確立に関わるクライアントおよびサーバのペアが、再送信に起因する多数の帯域幅の更新を防止するために、安全であるのが望ましい。状態７５１０にあってルータがメッセージ７１７０を受信する場合、やはりクライアントおよびサーバのペアは、メッセージ７１４０に関して安全であり、ルータの帯域幅が好ましくはｂｗによって増やされる。
【００９１】
状態１１５３０において、保存されたクライアント・サーバ・ペアに適合する第４の種類のメッセージ４１５０が受信された場合、ｅｒｒｏｒ＿ｆｌａｇが除去され、ルータが状態７５１０へと移行する。保存されたクライアント・サーバ・ペアに適合するメッセージ７１７０が受信された場合、ルータは状態１１５４０へと移行する。好ましくは、メッセージ４１５０およびメッセージ４１７０を含むすべてのメッセージが転送される。保存されたクライアント・サーバ・ペアについてメッセージ７１４０が受信される場合と、ｅｒｒｏｒ＿ｆｌａｇが設定される場合は、例外である。状態１１５４０にあるとき、保存されたクライアント・サーバ・ペアに適合するメッセージ４１５０が受信された場合、ｅｒｒｏｒ＿ｆｌａｇが除去され、ルータが状態７５１０に移行する。この状態において、メッセージ４１５０を含むすべてのメッセージが転送される。好ましくは、接続の開放／閉鎖のたびに、ルータは、アドレスおよびポートで構成され得るクライアントおよびサーバの身元を参照する接続を特定する状態を保存する必要がある。例えば、最も単純なルータの実施例は、図１１に示されるように、ただ１つの接続の身元を保存することができる。あるいは、ルータがいくつかの接続の身元を保存することができ、その場合には、保存することができる接続の身元ごとに図１１に示したとおりの１つの状態機械を使用することができる。この場合、接続の身元に保存することができるメッセージ７１４０または７１７０が受信されるたびに、ルータが、図１１に示した状態および状態変化に従事する。ルータが接続の身元を保存できない場合、好ましくは、ルータは、メッセージ７１４０または７１７０を破棄し、それ以上の行為を行わない。
【００９２】
以下の図１２〜図２１は、本開示によるシステムによって同じやり方で取り扱うことができる本開示の方法の上述の実施の形態の方法によるエラーおよびそれらエラーの取り扱いの種々の例を示している。
【００９３】
図１２が、図１のさらなる詳細における本開示による方法の実施の形態において生じうるエラーの事例の例を示している。
【００９４】
この場合、例えばサーバ１２００がビジーである可能性があり、したがって現時点においてサーバ１２００が別の接続に応対していることを示す状態１２３０にあるため、第１の種類のメッセージ１１４０を転送できない可能性がある。この場合、アプリケーションサーバ１３００との接続を確立する代わりに、エラーメッセージ１２１５０「Ｔ＿ＳＹＮ＿ＥＲＲ」が生成され、このエラーメッセージがクライアント１１００に受信されたとき、クライアントが、クライアントが接続されると状態１１１０ではなく、接続が閉じられる状態１１３０へと移行する。
【００９５】
図１３および図１４は、喪失または破棄の可能性があるメッセージの伝送を監視するためのタイマの使用を示している。
【００９６】
図１３は、図１においてさらに詳しく検討した本開示による方法の実施の形態においてエラーが生じる可能性がある事例を示している。この場合、第１の種類のメッセージが失われ（１３１４０）、結果としてサーバ１２００によって受信または処理されることがなく、サーバ１２００が状態１２１０のままとなる可能性がある。しかしながら、この場合に、第１の所定の期間を測定する第１のクライアントタイマが時間切れとなり、クライアント１１００とサーバ１２００との間の接続を確立するために、第１の種類のメッセージ１１４０の再送信を生じさせる。第１の所定の期間は、好ましくは、サーバ１２００に第２の種類のメッセージ１１５０を生成するための充分な処理時間ならびに両方向の充分な伝送時間を許すようなやり方で決められる。第２の種類のメッセージ１１５０がクライアント１１００によって受信されるとき、さらなる取り扱いは、図１において検討したとおりである。
【００９７】
図１４は、さらに詳しく図４に関して検討した本開示による方法の実施の形態において生じる可能性がある別のエラーおよびその取り扱いを説明している。この場合、参照符号１４１５０で示された第２の種類のメッセージが失われる。この場合にも、図１３と同様に参照符号１３０１０によって示される時間切れが生じ、第１の種類のメッセージ１１４０の再送信を生じさせる。これが、サーバ１２００に到着したこのメッセージが検出され、初めて受信された第１の種類のメッセージ１１４０によって引き起こされる状態１２１０から１２２０への状態変化ゆえに、このメッセージ１１４０が再送信され、このメッセージのソースが最初であることをサーバが特定することを可能にする。サーバに、再送信されたメッセージ１１４０を処理することなく破棄し、接続された状態１２３０へと状態を変化させ、確認のための第２の種類のメッセージ１１５０を送信させる。
【００９８】
図１５は、図１においてさらに詳しく検討した本開示による方法の実施の形態に関して、メッセージの交換において生じうる別のエラーの事例の例を説明している。この場合に、アプリケーションサーバ１３００におけるアプリケーションのクラッシュの場合に何が生じうるのかが検討される。ここで、サーバ１２００がメッセージ１３１０を送信しているが、クラッシュしたアプリケーション１３２０から応答を受信することはない。これは、第２の所定の期間を測定する第１のサーバタイマにおけるタイムアウト１５２５０につながるが、第２の所定の期間の大きさを決める際には、両方向のメッセージの伝達ならびにアプリケーションサーバがメッセージ１３１０を処理して応答１３２０を生成するための時間が考慮されるべきである。タイムアウト１５２５０に起因する第１のサーバタイマの時間切れが、エラーを示す状態６５５０を生成し、エラーメッセージ１５１５０をクライアントへと送信する。第１の種類のメッセージ１１４０のさらなる送信が、サーバ１２００からのエラーメッセージ１５１４０につながり、エラーメッセージ１５１５０または１５１４０に応答したアプリケーションクライアントへの対応するメッセージ１５０１０につながる。どちらの場合も、クライアントは接続を閉じ、状態１１３０に移行する。
【００９９】
アプリケーションサーバがメッセージ１３２０ Ｔ＿ＯＰＥＮ．ｒｓｐによってサーバに応答する場合、サーバが、メッセージ１３７０ Ｔ＿ＣＬＯＳＥ．ｉｎｄを使用して接続が実際に閉じられた旨をアプリケーションサーバに通知し、接続確立の要求の受信の準備ができた状態１２１０ Ｓ＿Ｌｉｓｔｅｎへと戻る。
【０１００】
図１６は、図４においてメッセージの流れを詳しく検討した本開示による方法の実施の形態においてエラーをどのように取り扱うことができるのかについての例を示している。
【０１０１】
ここでもやはり、信頼できるネットワークにおける事例においてすでに検討したように、サーバ１１００がビジーであり、要求を受けて接続を確立することができない。したがって、クライアント１１００へと知らせるべきエラーメッセージ１２１５０が生成される。これにより、第３の種類のメッセージ１１５０を発する接続閉鎖の動作がクライアント１１００において生じ、この第３の種類のメッセージ１１５０が、サーバ１２００から発せられる第６の種類のメッセージ４１７０によって確認される。次いで、クライアントが状態１１３０に移行する。
【０１０２】
図１７は、図４においてさらに詳しく検討したようにメッセージの交換が信頼性に欠けるネットワークにもとづく本開示による方法の実施の形態において生じうるエラーの事例を示している。信頼性に欠けるネットワークにおいては、あらゆるメッセージに破損または喪失の可能性があるため、第２の種類のメッセージ１１５０も、適切な取り扱いに関して監視されるのが望ましい。そうでない場合、喪失により、サーバは最初のビジーにおける「Ｓ＿Ｃｏｎｎｅｃｔｅｄ」状態１２３０のままであるかもしれず、しかし一方、接続１２１５０を確立するリクエストのエラーメッセージに応答することが、参照符号１７１５０で表される他のクライアントから切断し、状態１２１０で再び新たな接続のために利用可能となる。しかしながら、エラーメッセージのクライアント１１００への到達が遅すぎ、第１の種類のメッセージ１１４０の再送信を引き起こしたタイムアウト１３０１０の後、第１の種類のメッセージ１１４０により、サーバがアプリケーションサーバ１３００との接続を開くとともにデータ１１６０の送信を開始し、データ１１６０は、第２の種類のメッセージ１４１５０が失われたときに、プロトコルエラー１７１６０を生成する。
【０１０３】
図１８〜図２１は、図８および関連の説明においてさらに詳しく検討および図示した本開示による方法の実施の形態において生じうる別のエラーの事例を示している。
【０１０４】
そこでは、ルータ７５００がビジーであり、あるいは帯域幅を利用できないがゆえに帯域幅の変更の要求に応えることができず、この状況ゆえのエラーメッセージを生成する。
【０１０５】
図１８が、その状況を取り扱う第１の事例を示している。第１の種類のメッセージ７１４０を受信すると、ルータ２１５００が、２１５２０において帯域幅の割り当てを拒絶し、エラーフラグを設定する。これが、ルータ７５００へのエラーメッセージ２０１４０の送信につながり、これがクライアント１１００へと転送される。ルータ７５００が、２０５４０においてエラーフラグを設定する。他方で、エラーメッセージ２０５４０を受信したクライアントは、接続の終了を開始し、エラーによる終了メッセージ２０１７０「Ｔ＿ＦＩＮ＿ＥＲＲ」を送信する。これが、ルータ２１５００へと転送され、確認メッセージ４１７０が生成され、確認メッセージ４１７０がクライアント１１００に到着すると、エラーメッセージ１２０２０「Ｔ＿ＯＰＥＮ．ｅｒｒ」の生成が引き起こされる。
【０１０６】
図１９は、図１８において検討したものと同じエラーの事例の例を示しているが、メッセージの流れおよび取り扱いがわずかに変わっている。第１の種類のメッセージ７１４０の受信時に、ルータ２１５００が１９５２０においてｅｒｒｏｒ＿ｆｌａｇを設定せず、クライアントへのエラーメッセージ２１１４０において帯域幅情報を送信することがない。このように、先の例とは対照的に、クライアント１１００が、図８において述べたとおりの通常の接続終了を辿ることができる。
【０１０７】
この場合、ルータは、エラーの事例１９５３０「Ｒ＿ＢｕｓｙＥＲＲ」において異なる状態に入る。通常の接続の終了は、利用可能な場合に帯域幅の割り当てを解放する。図１９に示した例の場合には、メッセージの取り扱いがより容易であり、送信を必要とするメッセージの量がより少ない。しかしながら、図１８および１９に示したどちらの場合も、ルータを、好ましくはエラーメッセージ２１１４０および２０１４０を発するときにサーバの一部の機能を実行するように構成する必要がある。
【０１０８】
そのようなルータの変更を避けるために、考えられる代案は、エラーの取り扱いをサーバ１２００へと転送することであり、これが図２０および図２１の例で検討される。
【０１０９】
図２０は、図８において検討した本開示による方法の実施の形態においてルータがビジーであってメッセージの交換が信頼性に欠けるネットワークにもとづくエラーの事例の取り扱いの例を示している。
【０１１０】
ここで、図１８において検討した事例と同様に、ひとたび転送された第１の種類のメッセージ７１４０を受信しかつ利用可能な帯域幅を有していない場合、ルータがｅｒｒｏｒ＿ｆｌａｇを設定し、この場合には新しいエラーメッセージ２０１４０をサーバ１２００へと転送し、サーバ１２００が帯域幅パラメータを含むエラーメッセージ２０１４０を生成する。サーバによるさらなる追加の仕事は、エラーがクライアント１１００によって第７の種類のメッセージ４１５０にて発せられたときに接続の終了へと応答することである。
【０１１１】
さらに図２１が、図１９に関連して検討したエラーの取り扱いの例を示しているが、この場合にはエラーの取り扱いがサーバ１２００において行われる。変更として、図１９における手順が、エラーメッセージ２１１４０がサーバ１２００へと転送されて、サーバ１２００がエラーメッセージ２１１４０の送信および接続の終了の取り扱いを担当するようなやり方で変更される。
【０１１２】
信頼性に欠けるネットワークに関して、ルータにおける帯域幅の更新について考えられる代案は、それを７１４０の代わりの第２の種類のメッセージ１１５０および／または７１７０の代わりのメッセージ４１７０によって行うことである。ここで、第１のメッセージ７１４０および／または７１７０が受信されたとき、クライアント／サーバペアを上述のように保存でき、さらにフラグＥＲＲ＿ｆｌａｇを設定することができる。しかしながら、この場合に、帯域幅パラメータがメッセージ１１５０および４１７０によって運ばれる。エラーのこの場合に、メッセージ１１５０および／または４１７０による帯域幅の更新が行われていないため、エラーメッセージ２１１４０はいかなる帯域幅パラメータも運ばず、帯域幅なしに接続の終了につながる。したがって、メッセージ４１５０を、このエラーの場合にさらに最適化することができる。
【０１１３】
図２２が、同様の文脈において接続がメッセージ１０７０「Ｔ＿ＣＬＯＳＥ．ｒｅｑ」を送信しているアプリケーションクライアント１０００によって閉じられる場合を示している図４に加えて、別の選択肢を例示している。あるいは、接続を、メッセージ１０７０「Ｔ＿ＣＬＯＳＥ．ｒｅｑ」を送信するアプリケーションサーバ１３００によって閉じることもできる。この場合にも、結果としての工程は同じである。Ｔ／ＣＯサーバ１２００が、メッセージ１０７０「Ｔ＿ＣＬＯＳＥ．ｒｅｑ」を受信したときに、メッセージ１１７０「Ｔ＿ＦＩＮ」を送信し、タイマを開始させ、状態４１１２「Ｓ＿ＷａｉｔＦｉｎＡｃｋ」へと入る。Ｔ／ＣＯクライアント１１００が、メッセージ１１７０「Ｔ＿ＦＩＮ」を受信したときに、メッセージ１３７０「Ｔ＿ＣＬＯＳＥ．ｉｎｄ」をアプリケーションクライアントへと発し、アプリケーションクライアントが、Ｔ／ＣＯクライアント１１００へのメッセージ４３８０「Ｔ＿ＣＬＯＳＥ．ｒｓｐ」で応答し、Ｔ／ＣＯクライアント１１００が、Ｔ／ＣＯサーバへとメッセージ４１７０「Ｔ＿ＦＩＮ＿ＡＣＫ」を順に送信し、状態１１３０「Ｃ＿Ｃｌｏｓｅｄ」へと入る。Ｔ／ＣＯサーバは、メッセージ４１７０「Ｔ＿ＦＩＮ＿ＡＣＫ」を受信したとき、自身のタイマを停止させ、メッセージ４０８０「Ｔ＿ＣＬＯＳＥ．ｃｎｆ」をアプリケーションサーバ１３００へと送信し、状態１２４０「Ｓ＿Ｌｉｓｔｅｎ」へと入る。
【０１１４】
図２３が、同様の文脈における図４に加えて、接続の閉鎖がＴ／ＣＯクライアント１１００およびＴ／ＣＯサーバ１２００の両方において同時に要求される事例を示している。この場合には、Ｔ／ＣＯクライアント１１００およびＴ／ＣＯサーバ１２００からのメッセージ１０７０「Ｔ＿ＦＩＮ」がネットワークにおいて交差する。メッセージ１０７０「Ｔ＿ＦＩＮ」がＴ／ＣＯクライアント１１００において受信されるとき、Ｔ／ＣＯクライアント１１００は、タイマを停止させ、Ｔ／ＣＯサーバ１２００へとメッセージ４１７０「Ｔ＿ＦＩＮ＿ＡＣＫ」を送信し、状態１１３０「Ｃ＿Ｃｌｏｓｅｄ」へと移行する。メッセージ１０７０「Ｔ＿ＦＩＮ」がＴ／ＣＯサーバ１２００において受信されるとき、Ｔ／ＣＯサーバ１２００は、タイマを停止させ、Ｔ／ＣＯクライアント１１００へとメッセージ４１７０「Ｔ＿ＦＩＮ＿ＡＣＫ」を送信し、状態１２４０「Ｓ＿Ｌｉｓｔｅｎ」へと移行する。
【０１１５】
さらに本開示は、サーバおよび／またはクライアントにおいて具現化されるようなシステムの機能の任意のいずれかを、ハードウェア、コンピュータソフトウェア、または両者の組み合わせとして実現できることを含む。システム（例えば、クライアントおよび／またはサーバ）は、汎用のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または他のプログラマブルな論理デバイス、ディスクリートなゲートまたはトランジスタ論理回路、ディスクリートハードウェア部品、あるいは本明細書に記載の機能を実行するように設計された任意の組み合わせを含むことができる。汎用プロセッサは、マイクロプロセッサまたは状態機械であってよい。プロセッサを、例えばＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアが組み合わせられた１つ以上のマイクロプロセッサ、あるいは任意の他のそのような構成など、演算装置の組み合わせとして実現することもできる。クライアントおよび／またはサーバにおいて使用されるプロセッサが、本開示のいずれかの方法を実行するように構成される。
【０１１６】
さらに本開示は、任意の種類の演算装置上で実行されるように構成され、例えばサーバおよび／またはクライアントにおいて使用されるように構成され、すなわち処理エンジンを含んでいる装置において実行されるように構成されたコード部分を含んでいるコンピュータプログラム製品を含む。コンピュータプログラム製品のソフトウェアコードが、演算装置上で実行されたときに、第１の種類のメッセージをサーバへと送信することによって接続の確立を要求する機能をクライアントにおいて提供する。サーバにおいては、ソフトウェアが、演算装置上で実行されたときに、サーバの接続につながる第２の種類のメッセージをクライアントへと送信することによって接続を確立する能力を裏付ける。ソフトウェアは、好ましくは、第１の種類のメッセージの送信によって第１の最大応答時間としての第１の所定の期間を測定する第１のクライアントタイマが開始されるように構成され、好ましくは第２の種類のメッセージまたはデータメッセージの受信をもって第１のクライアントタイマを停止させるように構成される。さらにソフトウェアは、好ましくは、第３の種類のメッセージの送信によって接続が閉じられるように構成される。
【０１１７】
さらにソフトウェアは、好ましくは、第２の種類のメッセージが受信されることなく第１の所定の期間が過ぎた場合に別の第１の種類のメッセージが送信されるように構成される。さらにソフトウェアは、好ましくは、サーバが接続を引き受けることができない場合にエラーメッセージを返すように構成される。
【０１１８】
さらにソフトウェアは、好ましくは、
ａ）第２の種類のメッセージの受信が、クライアントの接続につながり、
ｂ）クライアントが第２の種類のメッセージの受信を確認するためにサーバへと第４の種類のメッセージを送信する
ように構成される。
【０１１９】
さらにソフトウェアは、好ましくは、第２の種類のメッセージの送信によって第２の最大応答時間としての第２の所定の期間を測定する第１のサーバタイマが開始され、第４の種類のメッセージの受信によって第１のサーバタイマが停止されるように構成される。
【０１２０】
さらにソフトウェアは、好ましくは、サーバが接続を確立できない場合にクライアントの非接続につながる第５の種類のメッセージをクライアントへと送信するように構成することができる。
【０１２１】
さらにソフトウェアは、好ましくは、第３の種類のメッセージの送信によって第３の最大応答時間としての第３の所定の期間を測定する第２のクライアントタイマが開始されるように構成される。
【０１２２】
さらにソフトウェアは、好ましくは、サーバが第６の種類のメッセージを送信することによって第３の種類のメッセージの受信を確認するように構成される。
【０１２３】
さらにソフトウェアは、好ましくは、第６の種類のメッセージの送信によって第４の最大応答時間としての第４の所定の期間を測定する第２のサーバタイマが開始されるように構成される。
【０１２４】
さらにソフトウェアは、好ましくは、クライアントにおける第６の種類のメッセージの受信によって第２のクライアントタイマが停止され、クライアントによる第４の種類のメッセージの送信が生じるように構成される。
【０１２５】
さらにソフトウェアは、好ましくは、サーバによる第３の種類のメッセージの送信によって第３の最大応答時間としての第３の所定の期間を測定する第２のサーバタイマが開始されるように構成される。
【０１２６】
さらにソフトウェアは、好ましくは、第３の種類のメッセージを受信するクライアントが、第３の種類のメッセージの受信を第６の種類のメッセージを送信することによって確認するように構成される。
【０１２７】
さらにソフトウェアは、好ましくは、第６の種類のメッセージの送信によって第４の最大応答時間としての第４の所定の期間を測定する第２のクライアントタイマが開始されるように構成される。
【０１２８】
さらにソフトウェアは、好ましくは、サーバにおける第６の種類のメッセージの受信によって第２のサーバタイマが停止され、クライアントによる第４の種類のメッセージの送信が生じるように構成される。
【０１２９】
さらにソフトウェアは、好ましくは、クライアントとサーバとの間のメッセージのうちの少なくとも１つがルータを通過でき、この少なくとも１つのメッセージが、リソース予約の要求を含んでおり、ルータが要求されたリソースを提供できる場合に限ってこの少なくとも１つのメッセージを転送する。
【０１３０】
さらにソフトウェアは、好ましくは、ルータが少なくとも１つのメッセージを転送する場合に、このリソース予約の要求に関する接続の確立に関わるクライアント・サーバ・ペアに関係する第２の種類のメッセージの受信まで、さらなるリソース予約の要求を一時的に停止するように構成される。
【０１３１】
さらにソフトウェアは、好ましくは、接続が閉じられる場合にリソースの予約を取り消すために少なくとも１つのメッセージが使用されるように構成される。
【０１３２】
さらにソフトウェアは、好ましくは、クライアントおよびサーバのそれぞれが、それぞれのアプリケーションクライアントとそれぞれのアプリケーションサーバとの間の接続を確立するように構成される。
【０１３３】
さらに本開示は、上述のコンピュータプログラム製品を保存する機械によって読み取ることができる一時的でない信号記憶媒体を含む。例えば、機械によって読み取ることができる一時的でない信号記憶媒体は、ＣＤＲＯＭまたはＤＶＤＲＯＭなどの光ディスク、磁気テープメモリ、ハードディスクまたはディスケットなどの磁気ディスクメモリ、ＵＳＢメモリスティックまたはフラッシュメモリなどの半導体メモリ、などであってよい。
【関連出願および優先権の主張】
【０００１】
本出願は、「ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＭＡＮＡＧＩＮＧ Ａ ＣＯＮＮＥＣＴＩＯＮ ＩＮ Ａ ＣＯＮＮＥＣＴＩＯＮ ＯＲＩＥＮＴＥＤ ＩＮ−ＯＲＤＥＲ ＤＥＬＩＶＥＲＹ ＥＮＶＩＲＯＮＭＥＮＴ」という名称の２００９年９月３０日付の米国特許出願第１２／５７１，０１８号の部分継続出願である。特許出願第１２／５７１，０１８号は、本出願の譲受人へと譲渡されており、ここでの言及によってあたかも全体が本明細書に記載されているかのように本出願に援用される。本出願は、米国特許出願第１２／５７１，０１８号について米国特許法第１１９条（ｅ）に規定の優先権を主張する。
【技術分野】
【０００２】
本開示は、伝達可能なアイテムの正順（ｉｎ−ｏｒｄｅｒ）デリバリを特徴とするネットワークによって互いに接続されたマルチコンポーネントシステムのコンポーネント間の通信のための方法およびシステムに関する。
【背景技術】
【０００３】
現在開発されている高度に統合されたシステムにおいては、高帯域幅の通信能力が、性能の要件としての前提条件である。さらに、セカンドソースの原理を追求するシステム開発者は、任意のあらゆる製造者から自身の設計のコンポーネントを選択できなければならないと同時に、それらがいかなる問題もなく相互運用されることを必要とする。このことが、該当の分野において活動する複数の製造者によって設立され、コンポーネントおよびコンポーネント間の相互通信についての規格を定める標準化団体の形成につながる。そのような標準化団体の１つが、モバイル・インダストリ・プロセッサ・インターフェイス・アライアンス（ＭＩＰＩ（登録商標））である。現時点において、この団体は、モバイルシステムの相互通信の詳細について作業する約１５０の製造者の集まりである。ある程度の情報が、ワールドワイドウェブ上のｈｔｔｐ：／／ｗｗｗ．ｍｉｐｉ．ｏｒｇ／において入手可能である。
【０００４】
コンポーネント間の通信を標準化するために、ＭＩＰＩ（登録商標）アライアンスは、モバイルシステムにおいてデバイスを接続するためのシリアル高速リンクとして、ＵｎｉＰｒｏＳＭを定めている。ＵｎｉＰｒｏＳＭ規格は、着実に発展中であり、現時点において規格バージョン１．０がリリースされている。この規格の種々のバージョンの特徴についてのある程度の情報が、ワールドワイドウェブ上のインターネット百科事典（ｈｔｔｐ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｕｎｉｐｒｏ）において入手可能である。
【０００５】
相互接続および通信の規格を用意することで、製造者は、自身のシステムの開発においてはるかに柔軟になることができ、種々の要件に良好に適し、種々のベンダによって提供されるコンポーネントを混ぜ合わせ、適合させることができる。ＵｎｉＰｒｏ規格またはユニファイドプロトコルは、高速シリアルリンクを利用するチップ対チップのネットワークに向けられている。エラーハンドリング、フロー制御、ルーティング、およびアービトレーションなどの一般的な相互接続の問題を解決する汎用の通信プロトコルとなるように定められている。
【０００６】
現時点において、ＵｎｉＰｒｏは、接続の確立と同時に、状態およびバッファなどの他のリソースの割り当てを必要とする接続指向の通信を提供している。通常は、接続が、通信に関わるバッファのオーバフローを防止するための、クレジット・エンド・トゥ・エンド・フロー制御を実装する。これが、データの喪失または破損がないことを保証する信頼できるネットワークの使用との組み合わせにおいて、ユーザへの信頼できる通信サービスを保証する。
【０００７】
ＵｎｉＰｒｏの将来の発展において、リアルタイムのトラフィッククラスを提供するバージョンを予測することができるが、レイヤ２の再送信の数を抑える結果となり、データのデリバリそのものについての保証を犠牲にすることによって、パケットのデリバリに関する制限時間を保証できる。なぜならば、レイヤ２の再送信の数を抑えることで、データの断片がデリバリされない可能性をきわめて小さくできるからである。ＵｎｉＰｒｏアプリケーションの上位のレイヤが、該当のレポートの受信時に、欠けた断片を処理しなければならない。接続指向の通信にもとづく信頼できるリアルタイムのトラフィッククラスは、接続を開始し、維持し、終了させるためのプロトコルを必要とする。現時点において、スリーウェイハンドシェイクが、伝送制御プロトコルＴＣＰから知られている。詳細は、ｔｈｅ ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ、ＤＡＲＰＡ Ｉｎｔｅｒｎｅｔ ｐｒｏｇｒａｍ、ｐｒｏｔｏｃｏｌ ｓｐｅｃｉｆｉｃａｔｉｏｎ ｂｙ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｃｉｅｎｃｅｓ Ｉｎｓｔｉｔｕｔｅ、Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｓｏｕｔｈｅｒｎ Ｃａｌｉｆｏｒｎｉａ、ＩＥＴＦ ｒｅｑｕｅｓｔ ｆｏｒ ｃｏｍｍｅｎｔｓ ＃７９３、Ｓｅｐｔｅｍｂｅｒ １９８１に公開されている。しかしながら、ＴＣＰは、ネットワークにつきものの低い信頼性に対処しなければならず、したがってそのような不確実性に対処するための予防措置をプロトコルにおいて講じる必要があるため、ユニファイドプロトコルとは大きく異なる。さらに、ＴＣＰは、例えばパケットがネットワークにおいてさまざまな経路をとることができるため、データのデリバリに順番がないことを前提としている。したがって、ＴＣＰは、接続の管理を保証するために、きわめて大きな続き番号および最大パケット寿命を使用する。しかしながら、ＵｎｉＰｒｏは、典型的には最大でも１０のノードからなる小さなネットワークにおいて働き、順番どおりの通信を提供する。したがって、使用されるオーバヘッドを通常のプロトコルよりも少なくすることができ、機能を犠牲にすることなく単純さを達成することができる。
【０００８】
さらに、Ｂ−ＩＳＤＮ ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｔｏｃｏｌｓ ｆｏｒ ａｃｃｅｓｓ ｓｉｇｎａｌｌｉｎｇ， ＩＴＵ−Ｔ ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｑ．２９３１， Ｆｅｂ−１９９５においてＩＴＵ−Ｔ Ｑ．２９３１に開示されているＡＴＭ接続設定も当分野において知られている。関連の接続設定は、ＡＴＭにおいてはリファレンスと呼ばれる続き番号を使用するＴＣＰにおいて使用される機構と同様の機構を使用するが、ＡＴＭも、メッセージのオーバヘッドを生じさせ、したがって通信チャネルからの帯域幅を必要とする大きな続き番号にもとづいている。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本開示の目的は、接続指向の正順デリバリ環境において接続を管理するための代案の方法およびシステムであって、最小限のメッセージのオーバヘッドでリソースの適切な割り当てならびに接続の確立および終了を可能にする方法およびシステムを提供することにある。
【課題を解決するための手段】
【００１０】
この課題は、接続指向の正順デリバリ環境において接続を管理するための方法であって、下記によって解決される。
ａ）クライアントが第１の種類のメッセージ（１１４０）をサーバへと送信することによって、接続の確立を要求し、
ｂ）サーバが、サーバの接続につながる第２の種類のメッセージをクライアントへと接続することによって接続の確立が可能であることを確認し、
ｃ）第１の種類のメッセージを送信することによって、第１の最大応答時間としての第１の所定の期間を測定する第１のクライアントタイマを始動し、第２の種類のメッセージまたはデータメッセージを受信することによって、第１のクライアントタイマが停止され、
ｄ）第３のメッセージを送信することによって接続が閉じられる。
【００１１】
さらに本開示は、接続指向の正順デリバリ環境において接続を管理するためのシステムであって、
サーバと、クライアントと、正順デリバリのネットワークと、を備えており、サーバが、上述の方法のうちのサーバに関する動作のいずれかを実行するように構成され、クライアントが、上述の方法のうちのクライアントに関する動作のいずれかを実行するように構成されているシステムを提供する。
【００１２】
本開示は、サーバ、クライアント、ルータなどにおいて本開示の方法のいずれかを実行するためのコンピュータプログラム製品を含む。
【００１３】
さらに本開示は、上述のコンピュータプログラム製品を保存する機械によって読み取ることができる一時的でない信号記憶媒体を含む。例えば、機械によって読み取ることができる一時的でない信号記憶媒体は、ＣＤＲＯＭまたはＤＶＤＲＯＭなどの光ディスク、磁気テープメモリ、ハードディスクまたはディスケットなどの磁気ディスクメモリ、ＵＳＢメモリスティックまたはフラッシュメモリなどの半導体メモリなどであってよい。
【００１４】
本開示の好都合なさらなる実施の形態が、従属請求項に提示される。
【００１５】
好都合なことに、本開示による方法は、メッセージの数を最小限にし、サーバによる第１のメッセージの脱落を防止する。このやり方で、たとえ信頼できるネットワークを使用していても、本方法は、別の接続を処理している等により接続に対応するための利用可能なリソースを有さないビジーサーバを保護する。
【００１６】
好都合には、本開示による方法のさらなる実施の形態によれば、可能な限り短い時間での接続の確立を保証すると同時に、サーバに充分な処理時間を許しつつ最初の送信における第１の種類のメッセージのサーバにおける脱落への対処を保証するために、第１の所定の期間が過ぎた場合にもう１つの第１の種類のメッセージがサーバへと送信される。
【００１７】
好都合には、本開示による方法のさらなる実施の形態によれば、第２の種類のメッセージの受信がクライアントの接続につながる一方で、第４の種類のメッセージの送信が、本方法が信頼性に欠けるネットワークまたはリアルタイムのトラフィッククラスに対応して、確認メッセージが受信された旨をサーバへと知らせることを可能にする。
【００１８】
有益には、サーバからクライアントへの第２の種類のメッセージの形式の本開示の方法のさらなる実施の形態による確認メッセージが、このメッセージの喪失から接続の確立を保護するために、第２の所定の期間を測定する第１のサーバタイマによって守られる一方で、確認メッセージがサーバから受信された旨のクライアントからの確認としての第４の種類のメッセージの受信が、第１のサーバタイマを停止させる。このやり方で、接続の確実な確立が、最小限の数のメッセージで保証される。
【００１９】
好都合には、本開示による方法のさらなる実施の形態によれば、他の接続への対応または他のアプリケーションの高い処理付加に起因してリソースが利用不可能であるがゆえに接続の確立が不可能である場合に、サーバが第５の種類のメッセージを生成し、クライアントへと送信する。このメッセージが、クライアントにおいて受信されたときに、クライアントが接続を閉じることを好都合に可能にし、サーバが利用不可能であるときにクライアントを所定の状態にする方法を提供する。
【００２０】
好都合には、本開示による方法のさらなる実施の形態によれば、第３の所定の期間を測定する第２のクライアントタイマが、第３の種類のメッセージが送信されたときに開始されることで、第３の種類のメッセージへの応答が第３の所定の期間内に受信されない場合に、接続の所定の終了が保証され、適切な対策がとられる。
【００２１】
有益には、本開示による方法のさらなる実施の形態によれば、第３の種類のメッセージの受信を確認し、したがって接続の確立および終了について綿密に構造化された取り扱いおよび管理が保証されていることを確認するために、サーバが第３の種類のメッセージの受信時に第６の種類のメッセージをクライアントへと送信する。
【００２２】
好都合には、本開示による方法のさらなる実施の形態によれば、信頼性に欠けるネットワークまたはリアルタイム通信のためのトラフィッククラスを有するネットワークがメッセージの伝達に使用される場合に、クライアントとの確実な通信を守るために、第６の種類のメッセージの送信によって第２のサーバタイマが開始される。
【００２３】
有益には、本開示の方法のさらなる実施の形態によれば、ひとたびクライアントが第６の種類のメッセージを受信し、したがってサーバが接続を閉じている旨を知ると、第２のクライアントタイマが停止されると同時に、この第６の種類のメッセージの受信を確認するため、ならびにサーバおよびクライアントにおける所定の状態を保証するために、第７の種類のメッセージがサーバへと送信される。
【００２４】
好都合には、本開示の方法のさらなる実施の形態によれば、クライアントおよびサーバの間の通信の柔軟性を高めると同時に、用途またはトラフィッククラスに応じて接続のために要求される帯域幅を定めることができるよう、クライアントおよびサーバの間で交換される任意のメッセージが、ルータを通過することができる。同時に、ルータは、受信したメッセージを、要求された帯域幅が利用できる場合に限って転送する。
【００２５】
好都合には、本開示による方法のさらなる実施の形態によれば、ルータが要求された帯域幅の提供に利用できる場合、クライアントによって指定された（addressed）サーバからの確認メッセージが受信されるまで、他のサーバおよびクライアントからの通信を拒絶しつつ、さらなる帯域幅の割り当てから保護する。このやり方で、帯域幅の割り当てが、存在しうる他の通信相手によるアクセスから保護される。
【００２６】
好都合には、本開示による方法のさらなる実施の形態は、アプリケーションクライアントとアプリケーションサーバとの間に確立される接続を介してデータの交換を提供するために、クライアントがクライアントにおいてメッセージを開始させるアプリケーションクライアントによって対処される一方で、サーバがアプリケーションサーバと通信することで、通信の確立のためのメッセージを交換するクライアントおよびサーバによってアプリケーションサーバとアプリケーションクライアントとの間の通信の確立を可能にする。
【００２７】
好都合には、本開示によるシステムは、本開示による方法の各機能を実行するために、最小限の構成においてサーバ、クライアント、および正順デリバリのネットワークを提供する。
【００２８】
好都合には、本開示によるシステムのさらなる実施の形態は、本開示による方法の実施の形態を利用しつつ、柔軟性を高め、クライアントとサーバとの間の通信距離を伸ばすためのルータを提供する。
【００２９】
好都合には、本開示のシステムのさらなる実施の形態によれば、通信の際に同時には使用されない確認メッセージが、１つのフォーマットのただ１つのメッセージへと節約され、通信の文脈においてサーバまたはクライアントにおいて正しい機能をもたらす。同様に、同時に動作することがないサーバタイマおよびクライアントタイマも、必要なときに作動させられ、本開示およびその実施の形態の方法によるメッセージ交換において第１または第２のサーバまたはクライアントタイマを実現するただ１つのサーバタイマおよびただ１つのクライアントタイマとして実現することができる。
【００３０】
以下で、本開示の実施の形態の例を、図面に示した実施例にもとづいてさらに説明する。
【図面の簡単な説明】
【００３１】
【図１】信頼できるネットワークにおいて生じる典型的なメッセージ交換を示している。
【図２】信頼できるネットワークにおける状態および状態変化の例を説明する状態機械を示している。
【図３】信頼できるネットワークにおけるサーバの状態および状態変化の例を示している。
【図４】信頼性に欠けるネットワークにおける例としてのメッセージの流れを示している。
【図５】信頼性に欠けるネットワークにおけるクライアントの例としての状態および状態変化を示している。
【図６】信頼性に欠けるネットワークにおけるサーバの状態および状態変化の例を示している。
【図７】帯域幅の割り当てを含むサーバ、クライアント、およびルータ間のメッセージの流れの例を示している。
【図８】メッセージがルータを通過するときの信頼性に欠けるネットワークにおけるクライアントとサーバとの間のメッセージの流れの例を示している。
【図９】メッセージの流れにルータを含んでいる信頼性に欠けるネットワークにおけるクライアントの例としての状態および状態変化を示している。
【図１０】メッセージの流れにルータを含んでいる信頼性に欠けるネットワークにおける例としてのサーバの状態および状態変化を示している。
【図１１】信頼性に欠けるネットワークにおけるクライアントとサーバとの間のメッセージの流れに含まれるルータの例としての状態および状態変化を示している。
【図１２】サーバがビジーであるときの信頼性に欠けるネットワークにおけるクライアントとサーバとの間のメッセージ交換の例を示している。
【図１３】第１の種類のメッセージが失われる場合のクライアントとサーバとの間のメッセージ交換の例を示している。
【図１４】第２の種類のメッセージが失われる場合のクライアントとサーバとの間のメッセージ交換の例を示している。
【図１５】サーバアプリケーションがクラッシュした場合のクライアントとサーバとの間のメッセージの流れの例を示している。
【図１６】サーバがビジーである場合の信頼性に欠けるネットワークにおけるクライアントとサーバとの間のメッセージの流れの例を示している。
【図１７】プロトコルエラーが生じる場合のクライアントとサーバとの間のメッセージ交換の例を示している。
【図１８】ルータを含む信頼性に欠けるネットワークにおいて生じる第１のエラーの例を示している。
【図１９】経路にルータを含んでいるクライアントとサーバとの間の通信において生じる例としての第２のエラーを示している。
【図２０】間にルータを有しているクライアントとサーバとの間で生じる通信エラーの第３の例を示している。
【図２１】ルータを通過するメッセージ交換に関し、クライアントとサーバとの間の通信において生じる通信エラーの第４の例を示している。
【図２２】信頼性に欠けるネットワークにおける例としてのさらなるメッセージの流れを示している。
【図２３】信頼性に欠けるネットワークにおける例としての別のメッセージの流れを示している。
【発明を実施するための形態】
【００３２】
本開示を、特定の実施の形態に関して、特定の図面を参照しつつ説明するが、本開示は、これらに限られるわけではなく、特許請求の範囲以外の何ものにも限定されない。説明される図面は、あくまでも概略図であって、本開示を限定するものではない。図面においては、説明の目的のために、一部の構成要素のサイズが誇張され、比例尺では描かれていない。
【００３３】
効率をよくする目的で、図２、図３、図５、図６、図９、図１０、および図１１のような状態機械に関する図面の説明の全体を通じて、状態変化のトリガおよびそれによって生じる事象を説明するために、以下の文法的規則が使用される。
【００３４】
＜トリガ＞／＜アクション＞などの書式が、状態機械における表記に使用される。ここで、＜トリガ＞は、対応するトランザクションへとつながるトリガとして機能する入力トリガのプレースホルダとして機能する。さらに、＜アクション＞は、トランザクションに関連付けられた一式の結果としての事象のプレースホルダとして機能する。
【００３５】
本明細書および特許請求の範囲において、用語「・・・からなる（ｃｏｍｐｒｉｓｉｎｇ）」が使用される場合、他の構成要素または工程が除外されるわけではない。さらに、本明細書および特許請求の範囲において、「第１の」、「第２の」、「第３の」、などといった用語は、類似の構成要素間の区別のために用いられ、必ずしも順番または時系列を表わすために使用されているわけではない。そのように使用される用語が、適切な状況のもとで互いに入れ換え可能であり、本明細書に記載される本開示の実施の形態が、本明細書に記載または例示の順序以外の順序でも機能できることを、理解すべきである。
【００３６】
図１が、信頼できるネットワークにおける本開示の一実施の形態による接続管理のためのメッセージの流れの例を示している。図面の説明の全体を通して、同じ参照符号が、すべての図面において、同じエンティティに使用され、その繰り返しの説明は、効率をよくする目的で省略される。
【００３７】
図１に例示されるとおり、アプリケーションクライアント１０００は、信頼できるネットワークを使用して、クライアント１１００、サーバ１２００、およびアプリケーションサーバ１３００と通信する。ネットワークは、単純なリンクであってよく、あるいは１つ以上のルータを含むことができる。しかしながら、簡単にするために、図１においてはいかなるルータも示されていない。アプリケーションクライアント１０００は、接続の確立を開始するために、「Ｃ＿Ｃｌｏｓｅｄ」の状態１１３０にあるクライアント１１００へ、メッセージ１０１０「Ｔ＿ＯＰＥＮ．ｒｅｑ」を送信する。クライアント１１００において、第１の種類のメッセージ１１４０「Ｔ＿ＳＹＮ」が「Ｓ＿Ｌｉｓｔｅｎ」状態にあるサーバ１２００へ送信された時点で、第１のタイマが開始される。サーバはアプリケーションサーバ１３００へのメッセージ「Ｔ＿ＯＰＥＮ．ｉｎｄ」１３１０を生成し、アプリケーションサーバ１３００がデータを取り扱うことができる場合には、サーバへのメッセージ１３２０「Ｔ＿ＯＰＥＮ．ｒｓｐ」にて応答する。サーバ１２００は、状態１２２０「Ｓ＿ＷａｉｔＲｓｐ」にあるときに第１のサーバタイマを用いて、メッセージ１３１０および１３２０の間の時間間隔を測定する。メッセージ１３２０を受信すると、第２の所定の期間を測定する第１のサーバタイマが停止され、第２の種類のメッセージ１１５０「Ｔ＿ＳＹＮ＿Ａｃｋ」がクライアント１１００へと送信され、クライアント１１００において、メッセージ１１４０が生成されて状態１１２０「Ｃ＿ＷａｉｔＡｃｋ」となったときに開始された第１のクライアントタイマが停止され、メッセージ１０２０「Ｔ＿ＯＰＥＮ．ｃｎｆ」が生成される。今や状態１２３０「Ｓ＿Ｃｏｎｎｅｃｔｅｄ」にあるサーバ１２００に接続が行われる。今やアプリケーションクライアントがデータ送信の要求１０３０「Ｔ＿ＤＡＴＡ．ｒｅｑ」の送信を開始し、これが確認メッセージ１０４０「Ｔ＿ＤＡＴＡ．ｃｎｆＬ」によってクライアント１１００によって確認される。サーバを「Ｓ＿Ｃｏｎｎｅｃｔｅｄ」の状態に、クライアントを「Ｔ＿Ｃｏｎｎｅｃｔｅｄ」の状態に残しつつ、サーバ１２００は送信されたデータ１１６０「Ｔ＿ＤＡＴＡ」を受信し、アプリケーションクライアントからのデータ１３３０「Ｔ＿ＤＡＴＡ．ｉｎｄ」をアプリケーションサーバへと送信し、アプリケーションサーバはメッセージ１３４０「Ｔ＿ＤＡＴＡ．ｒｓｐＬ」によって応答する。
【００３８】
データをメッセージ１３５０「Ｔ＿ＤＡＴＡ．ｒｅｑ」をサーバ１２００へと送信することによってアプリケーションサーバから要求することもでき、このメッセージはメッセージ１１６０「Ｔ＿ＤＡＴＡ」としてクライアント１１００へと転送され、そこからメッセージ「Ｔ＿ＤＡＴＡ．ｉｎｄ」１０５０としてアプリケーションクライアントへとさらに転送され、「Ｃ＿Ｃｏｎｎｅｃｔｅｄ」の状態１１１０にあるクライアント１１００へのメッセージ１０６０「Ｔ＿ＤＡＴＡ．ｒｓｐＬ」によって応答するよう、アプリケーションクライアントを促す。
【００３９】
接続を終わらせるために、アプリケーションクライアントはメッセージ１０７０「Ｔ＿ＣＬＯＳＥ．ｒｅｑ」を送信し、これがクライアント１１００によってメッセージ１０８０「Ｔ＿ＣＬＯＳＥ．ｃｎｆＬ」にて確認されるとともに、クライアント１１００はサーバ１２００への第３の種類のメッセージ１１７０「Ｔ＿ＦＩＮ」を生成し、サーバ１２００はアプリケーション１３００へと接続閉鎖１３７０「Ｔ＿ＣＬＯＳＥ．ｉｎｄ」を知らせることによって応答し、これがサーバ１３００によってメッセージ１３８０「Ｔ＿ＣＬＯＳＥ．ｒｓｐＬ」にて確認され、サーバを状態１２４０「Ｓ＿Ｌｉｓｔｅｎ」に移行させる。あるいは、接続の閉鎖がメッセージ１０７０「Ｔ＿ＣＬＯＳＥ．ｒｅｑ」にてアプリケーションサーバ１３００によって要求され（メッセージ１０８０「Ｔ＿ＣＬＯＳＥ．ｃｎｆＬ」にて確認される）、メッセージ１３７０「Ｔ＿ＣＬＯＳＥ．ｉｎｄ」にて示される（メッセージ１３８０「Ｔ＿ＣＬＯＳＥ．ｒｓｐＬ」にて応答される）場合に、メッセージ１１７０「Ｔ＿ＦＩＮ」を送信することによってサーバ１２００により、接続が閉鎖されてもよい。一般に、これらの実施の形態において説明したそれぞれのメッセージの流れを、サーバおよびクライアントに関して逆にすることができ、すなわちサーバおよびクライアントを入れ替えることができる。
【００４０】
クライアントは状態１１３０「Ｃ＿Ｃｌｏｓｅｄ」のままである。たとえ信頼できるネットワークが通信の基盤を形成している場合であっても、メッセージの処理に利用できるリソースが存在しない場合に、第１の種類のメッセージ１１４０がサーバによって落とされる可能性があるため、メッセージ１１４０および１１５０の間のタイマが必要である。随意により、メッセージ１３１０および１３２０の間でサーバによって運営されて第２の所定の期間を測定するタイマが、通信に必要とされるアプリケーションサーバのアプリケーションがクラッシュまたは他の理由で利用可能になっていないかどうかを監視するために、利用可能である。
【００４１】
便宜上、クライアント１１００は、メッセージ１１４０の送信後に到着する傾向にあるメッセージ１１５０の受信のためのリソースを提供すべきである。このやり方で、好都合なことに、サーバ１２００において、メッセージ１１５０の適切な伝送を監視するためのタイマが不要である。同様に、クライアント１１００および／またはサーバ１２００は、メッセージ１１７０の受信／取り扱いのためのリソースを提供すべきである。このやり方で、メッセージ１１７０の送信者はメッセージ１１７０の伝送損失に対する保護のためのタイマを必要としない。
【００４２】
図２は、図１に示したメッセージの流れに関係する状態機械を、クライアントがとることができる状態および状態変化の例として示している。
【００４３】
本明細書における状態機械の表記をさらに説明するために、例が図２を参照して提示されるが、これは、状態機械を表わす他の図にも同様のやり方で適用可能である。
【００４４】
ここで、図２において、状態１１３０から状態１１２０へのクライアントの移行２１００は、アプリケーションクライアント１０００からのＴ＿ＯＰＥＮ．ｒｅｑ（ｍｙ＿ｓｅｒｖｅｒ）の受信によって引き起こされ、サーバ１２００へのＴ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ）の送信およびクライアント１１００におけるＴｉｍｅｒ＿ＳＹＮの開始にもつながる。これは、上述の表記において、２１００：Ｔ＿ＯＰＥＮ．ｒｅｑ（ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＳＹＮと称される。
【００４５】
他の例として、移行２２００のトリガの事象は、Ｔｉｍｅｒ＿ＳＹＮの時間切れであり、やはりサーバ１２００へのＴ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ）の送信およびクライアント１１００におけるＴｉｍｅｒ＿ＳＹＮの再開につながる。これが、２２００：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿ＳＹＮ／Ｔ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），ｒｅｓｔａｒｔ Ｔｉｍｅｒ＿ＳＹＮと称される。
【００４６】
状態１１３０にあるとき、クライアントは、２１００：Ｔ＿ＯＰＥＮ．ｒｅｑ（ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＳＹＮに対応して、状態１１２０「Ｃ＿ＷａｉｔＳｙｎＡｃｋ」へと移行することができる。クライアントは、２２００：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿ＳＹＮ／Ｔ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），ｒｅｓｔａｒｔ Ｔｉｍｅｒ＿ＳＹＮに対応して状態１１２０のままである一方で、状態１１３０への再移行が、２１５０：Ｔ＿ＳＹＮ＿ＥＲＲ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＯＰＥＮ．ｃｎｆ（ｅｒｒｏｒ），ｓｔｏｐ Ｔｉｍｅｒ＿ＳＹＮに従って生じる。状態１１２０から状態１１１０「Ｃ＿Ｃｏｎｎｅｃｔｅｄ」への移行が、２３００：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＯＰＥＮ．ｃｎｆ（ｏｋ），ｓｔｏｐ Ｔｉｍｅｒ＿ＳＹＮまたは２３００： Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＯＰＥＮ．ｃｎｆ（ｏｋ），ｓｔｏｐ Ｔｉｍｅｒ＿ＳＹＮ， Ｔ＿ＤＡＴＡ．ｉｎｄに従って生じる一方で、クライアントは、２４００：Ｔ＿ＤＡＴＡ．ｒｅｑ／Ｔ＿ＤＡＴＡ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ）または２４００：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＤＡＴＡ．ｉｎｄに対応して状態１１１０にとどまり、２５００：Ｔ＿ＣＬＯＳＥ．ｒｅｑ（）／Ｔ＿ＣＬＯＳＥ．ｃｎｆ，Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｒｅｖｅｒ）によって状態１１３０へと移行する。
【００４７】
図３は、図１に示したメッセージの流れの文脈においてサーバがとることができる状態および状態変化の例としての状態機械を示している。
【００４８】
状態「Ｓ＿ＷａｉｔＣｌｏｓｅＲｓｐＥ」３２２０、状態３４２０「Ｓ＿Ｅｒｒｏｒ」、状態１２２０「Ｓ＿ＷａｉｔＯｐｅｎＲｓｐ」、状態１２３０「Ｓ＿Ｃｏｎｎｅｃｔｅｄ」、ならびにさらなる状態３３２０「Ｓ＿ＷａｉｔＣｌｏｓｅＲｓｐ」および状態１２１０「Ｓ＿Ｌｉｓｔｅｎ」が示されている。
【００４９】
状態１２１０から状態１２２０への移行は、３３５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＯＰＥＮ．ｉｎｄ（ｍｙ＿ｃｌｉｅｎｔ），ｓｔａｒｔ Ｔｉｍｅｒ＿ Ｒｓｐによって生じ、状態１２２０から３４２０への移行は、３２００：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿Ｒｓｐ／ｓｔｏｐ Ｔｉｍｅｒ＿Ｒｓｐ，Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）によって生じ、状態１２２０から状態１２３０への移行は、３３００：Ｔ＿ＯＰＥＮ．ｒｓｐ（）／ｓｔｏｐ Ｔｉｍｅｒ＿Ｒｓｐ，Ｔ＿ＳＹＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）に対応して生じる。状態３４２０から状態３２２０への状態変化は、３１００：Ｔ＿ＯＰＥＮ．ｒｓｐ（）／Ｔ＿ＣＬＯＳＥ．ｉｎｄ（）に従って生じる。
【００５０】
さらなる移行が、３４５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＣＬＯＳＥ．ｉｎｄ（）に対応して状態１２３０から３３２０へと生じ、３５５０：Ｔ＿ＣＬＯＳＥ．ｒｓｐ／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）によって状態３３２０から状態１２１０へと生じる。状態１２１０は、最初に事象３６５０：Ｔ＿ＬＩＳＴＥＮ．ｒｅｑ／−によってトリガされる。サーバは、移行３１５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）に従って状態３４２０にとどまる。サーバは、移行３４００：Ｔ＿ＤＡＴＡ．ｒｅｑ（ｄａｔａ）／Ｔ＿ＤＡＴＡ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）または３４００：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）／Ｔ＿ＤＡＴＡ．ｉｎｄ（ｄａｔａ）または３４００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）または３４００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）に従って状態１２３０にとどまる。サーバは、移行３５００：Ｔ＿ＤＡＴＡ．ｒｅｑ（ｄａｔａ）／Ｔ＿ＤＡＴＡ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）または３５００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）に従って状態３３２０にとどまる。
【００５１】
例えば、状態３３２０において、サーバは依然としてデータを送信することができるが、クライアントからそれ以上のデータは受信しない。
【００５２】
図４は、レイヤ２の再送信の数に制限があるネットワークなど、信頼性を欠くネットワークにおいて生じる本開示による実施の形態のメッセージの流れの例を示している。
【００５３】
図１との比較において容易に特定できるとおり、交換されるメッセージの多くは同じである。この事実ゆえ、信頼できるネットワークにおいて必要とされるメッセージを、信頼性に欠けるネットワークにおける接続の確立に必要なメッセージから隔てる、メッセージの流れにおける相違に注目する。信頼性に欠けるネットワークの場合には、好ましくは、追加のタイマおよびメッセージが、信頼性の欠如を補償し、かつ、接続の確立を確実にするために、用意される。この場合、クライアント１１００が、第４の種類のメッセージ４１５０「Ｔ＿ＡＣＫ＿ＡＣＫ」を生成する。この第４の種類のメッセージは、信頼性に欠けるネットワークの場合に用意され、第２の種類のメッセージ１１５０の適切な伝達を監視するためのメッセージの流れを実行する。第４の種類のメッセージの適切かつ時機を得た伝達は、サーバ１２００が状態７５１０「Ｓ＿ＷａｉｔＳｙｎＡｃｋ」にある間に、サーバ１２００において動作する第２のサーバタイマによって判断される。この場合には、クライアントが、第４の種類のメッセージ４１５０の送信後に状態４１１０「Ｃ＿Ｃｏｎｎｅｃｔｅｄ」に移行する。
【００５４】
このメッセージの流れの他の特徴は、接続の終了にあり、接続の終了の際の第３のメッセージ１１７０への適切な応答が、クライアント自身が状態４１１０「Ｃ＿ＷａｉｔＦｉｎＡｃｋ」にあるときにタイマによって監視される。ひとたび接続の終了を確認する第６の種類のメッセージ４１７０「Ｔ＿ＦＩＮ＿ＡＣＫ」がサーバ１２００から受信されると、第２のクライアントタイマが停止される。
【００５５】
信頼性に欠けるネットワークにもとづくメッセージの伝達の場合には、リンクがパケットを破棄する可能性がある。これは、メッセージのデリバリ時間を拘束する、例えば０または１の再送信の境界数を有するトラフィッククラスの場合かもしれない。この手順ゆえ、メッセージの一部分または全体が失われることがあり、あるいはメッセージが、ペイロードに既知のエラーがある状態で、届けられることがある。したがって、接続管理メッセージも、処理されずに捨てられる可能性がある。ここで、特に、サーバからの第２の種類のメッセージ１１５０を、好ましくは保護すべきである。なぜならば、喪失ゆえのエラーの場合、サーバが最初にビジーであり、そして、第２の種類のメッセージ１１５０を利用できるようになった後に、「Ｓ＿Ｃｏｎｎｅｃｔｅｄ」の状態１２３０のままになる可能性があるからである。
【００５６】
これは、サーバが接続されていると思い込み、接続されておらず、したがってデータの受信の準備ができていないクライアントへ、データの送信を開始するという事例につながりかねない。
【００５７】
図５は、図４に示したメッセージの流れに関連したクライアントにおける状態および状態間の移行の例を示す状態機械を示している。
【００５８】
この場合、この実施の形態に示される、信頼性に欠けるネットワークに存在する状況が、図２に示した信頼できるネットワークにおけるクライアントと比較した相違点として、接続「Ｃ＿ＷａｉｔＦｉｎＡｃｋ」の終了の文脈における状態４１１０の追加を示している。さらなる状態は、１１１０「Ｃ＿Ｃｏｎｎｅｃｔｅｄ」、１１３０「Ｃ＿Ｃｌｏｓｅｄ」、５１２０「Ｃ＿ＷａｉｔＳｙｎＡｃｋ」、および５６５０「Ｃ＿ＷａｉｔＣｌｏｓｅＲｓｐ」である。
【００５９】
状態１１３０から状態５１２０の移行は、５１５０：Ｔ＿ＯＰＥＮ．ｒｅｑ（ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｅｖｅｒ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＳＹＮに対応する。状態５１２０から状態１１１０への移行は、５２５０：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＡＣＫ＿ＡＣＫ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），Ｔ＿ＯＰＥＮ．ｃｎｆ（ｏｋ），ｓｔｏｐ Ｔｉｍｅｒ＿ＳＹＮに対応して生じる。状態１１１０から状態４１１０へは、移行５４５０：Ｔ＿ＣＬＯＳＥ．ｒｅｑ（）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｒｅｖｅｒ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＦＩＮに対応する。５３００：Ｔ＿ＳＹＮ＿ＥＲＲ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＦＩＮに従って、状態５１２０から状態４１１０に達することも可能である。状態４１１０から状態１１３０は、移行５５５０：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＣＬＯＳＥ．ｃｎｆ（），ｓｔｏｐ Ｔｉｍｅｒ＿ＦＩＮ、移行５５５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），Ｔ＿ＣＬＯＳＥ．ｃｎｆ（），ｓｔｏｐ Ｔｉｍｅｒ＿ＦＩＮによる。状態１１１０から状態５４２０は、移行５４６０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＣＬＯＳＥ．ｉｎｄ（）による。状態５４２０から状態１１３０は、移行５６６０：Ｔ＿ＣＬＯＳＥ．ｒｓｐ（）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）による。
【００６０】
移行５１００：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ａｎｙ＿ｓｅｒｖｅｒ）／−、移行５１００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ａｎｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）、移行５２００：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ａｎｙ＿ｓｅｒｖｅｒ）／−、移行５２００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ａｎｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）、移行５２００：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿ＳＹＮ／Ｔ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），ｒｅｓｔａｒｔ Ｔｉｍｅｒ＿ＳＹＮ、移行５４００：Ｔ＿ＤＡＴＡ．ｒｅｑ／Ｔ＿ＤＡＴＡ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ）、移行５４００：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＤＡＴＡ．ｉｎｄ、移行５４００：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）／−、移行５４００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行５４００：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＡＣＫ＿ＡＣＫ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ）、ならびに移行５５００：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ）、移行５５００：Ｔ＿ＳＹＮ＿ＥＲＲ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ）、移行５５００：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）／−、移行５５００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行５５００：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿ＦＩＮ／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），ｒｅｓｔａｒｔ Ｔｉｍｅｒ＿ＦＩＮ、移行５６５０：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）／−、および移行５６５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）のそれぞれの場合、それぞれの状態１１３０、５１２０、１１１０、および４１１０が維持される。
【００６１】
状態５１２０の場合において、第２の種類のメッセージ１１５０、あるいはエラーメッセージが受信される場合、それらは第３の種類のメッセージ１１７０によって応答される。この場合、第２のクライアントタイマが再開される。この場合には、両方のクライアントタイマが、例えば相互に排他的であり、したがって両方の機能をとる単一のタイマとして実現することができる。
【００６２】
図６が、図４に示したとおりの信頼性に欠けるネットワークの通信状況におけるサーバ１２００の状態および状態間の移行の例を示す状態機械を示している。
【００６３】
ここで、信頼できるネットワークを利用するサーバの状況との比較において、やはり第４の種類のメッセージ４１５０がクライアント１１００からの確認として受信される。同様に、第６の種類のメッセージ４１７０が発せられる。
【００６４】
図６において、状態６５５０「Ｓ＿Ｅｒｒｏｒ」および状態１２４０「Ｓ＿Ｌｉｓｔｅｎ」ならびに状態６２２０「Ｓ＿ＷａｉｔＯｐｅｎＲｓｐ」および状態６６２０「Ｓ＿ＷａｉｔＳｙｎＡｃｋ」とともに、状態６５２０「Ｓ＿ＷａｉｔＣｌｏｓｅＲｓｐＥ」が示されている。さらに、状態１２３０「Ｓ＿Ｃｏｎｎｅｃｔｅｄ」、状態６４２０「Ｓ＿ＷａｉｔＣｌｏｓｅＲｓｐ」、および状態４１１２「Ｓ＿ＷａｉｔＦｉｎＡｃｋ」も示されている。
【００６５】
状態１２４０は、６８００：Ｔ＿ＬＩＳＴＥＮ．ｒｅｑ／−によって開始され、６７５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）または６７５０：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／−の場合に維持される。そこからの状態６２２０への移行は、６８５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＯＰＥＮ．ｉｎｄ（ｍｙ＿ｃｌｉｅｎｔ），ｓｔａｒｔ Ｔｉｍｅｒ＿Ｒｓｐに従って生じ、状態６２２０は、６３００： Ｔ＿ＦＩＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）または６３００：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−の場合に維持される。そこから、６２５０：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿Ｒｓｐ／ｓｔｏｐ Ｔｉｍｅｒ＿Ｒｓｐ，Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）の場合に状態６５５０に到達でき、状態６５５０は、６１５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）、６１５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）、または６１５０：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／−に対応して維持される。この状態６５５０から、６２００：Ｔ＿ＯＰＥＮ．ｒｓｐ（）／Ｔ＿ＣＬＯＳＥ．ｉｎｄ（）によって状態６５２０に到達でき、状態６５２０は、６１００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）、６１００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）、または６１００：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／−に従って維持される。
【００６６】
状態６２２０から状態６６２０への別の移行が、６３５０：Ｔ＿ＯＰＥＮ．ｒｓｐ（）／ｓｔｏｐ Ｔｉｍｅｒ＿Ｒｓｐ，Ｔ＿ＳＹＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＡＣＫに対応して生じる。それぞれの状態が、移行６４００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）、移行６４００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行６４００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行６４００：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−、または移行６４００：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿ＡＣＫ／Ｔ＿ＳＹＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ），ｒｅｓｔａｒｔ Ｔｉｍｅｒ＿ＡＣＫに対応して維持され、ここから６４５０：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／ｓｔｏｐ Ｔｉｍｅｒ＿ＡＣＫまたは６４５０：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）／ｓｔｏｐ Ｔｉｍｅｒ＿ＡＣＫ，Ｔ＿ＤＡＴＡ．ｉｎｄ（ｄａｔａ）に従って状態１２３０が到達され、状態１２３０が、トランザクション６５５５：Ｔ＿ＤＡＴＡ．ｒｅｑ（ｄａｔａ）／Ｔ＿ＤＡＴＡ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）、トランザクション６５５５：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）／Ｔ＿ＤＡＴＡ．ｉｎｄ（ｄａｔａ）、トランザクション６５５５：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−、トランザクション６５５５：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、トランザクション６５５５：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、または移行６５５５：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−によって維持される。ここから、状態６４２０が６６００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＣＬＯＳＥ．ｉｎｄ（）に対応してとられ、移行６６５０：Ｔ＿ＤＡＴＡ．ｒｅｑ（ｄａｔａ）／Ｔ＿ＤＡＴＡ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）、移行６６５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／−、移行６６５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行６６５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、または移行６６５０：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−に従って維持される。次いで、６７００：Ｔ＿ＣＬＯＳＥ．ｒｓｐ／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）に対応する初期状態１２４０への移行が生じることで、この状態を離れることができる。
【００６７】
状態６５５５から状態６６４０への移行は、６６１０：Ｔ＿ＣＬＯＳＥ．ｒｅｑ（）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＦＩＮに対応する。状態４１１２から状態１２４０への移行は、６６４５：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＣＬＯＳＥ．ｃｎｆ（），ｓｔｏｐ Ｔｉｍｅｒ＿ＦＩＮおよび６６４５：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏＬｍｙ＿ｃｌｉｅｎｔ），Ｔ＿ＣＬＯＳＥ．ｃｎｆ（），ｓｔｏｐ Ｔｉｍｅｒ＿ＦＩＮに対応する。状態４１１２は、移行６６４０：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）、移行６６４０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行６６４０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行６６４０：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−、ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿ＦＩＮ／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ），ｒｅｓｔａｒｔ Ｔｉｍｅｒ＿ＦＩＮ、またはＴ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）／−に従って維持される。
【００６８】
状態６６２０から状態１２４０への他の移行は、６５００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）に対応して生じる。
【００６９】
図において、用語「ｍｙ＿ｃｌｉｅｎｔ」がアプリケーションクライアントを指す一方で、用語「ｍｙ＿ｓｅｒｖｅｒ」はアプリケーションサーバを指す。
【００７０】
図７が、クライアントとサーバとの間で交換されるメッセージがルータによって転送される本開示による方法の実施の形態の例を示している。この方法は、接続の確立の前に、接続のための帯域幅の予約および利用可能な帯域幅の確認を、好都合に適用する。このメッセージの図と、図４の信頼できるネットワークにおける接続管理を示したメッセージの流れを示す図との間の主たる相違点は、ルータがクライアント１１００とサーバ１２００との間に存在する場合に、ルータが図４においてクライアント１１００とサーバ１２００との間で交換されるメッセージを転送し、好都合には帯域幅の割り当てまたは帯域幅の見積りを実行し、それぞれの接続に要求される帯域幅の利用可能性を確認することにある。詳しくは、ここではルータ７５００が新規であり、それぞれの状態７５１０「Ｒ＿Ｒｅａｄｙ」および７５３０「Ｒ＿Ｂｕｓｙ」をとる。さらに、先の図において説明したメッセージ書式と比較して、第１の種類のメッセージのメッセージ書式が帯域幅の要求を含んでおり、したがって参照番号７１４０「Ｔ＿ＳＹＮ（ｂｗ）」によって指し示されている。また、第３の種類のメッセージのメッセージ書式が、今や好ましくは帯域幅の要求を含んでおり、したがって別の参照番号７１７０「Ｔ＿ＦＩＮ（ｂｗ）」によって指し示されている。ここで、クライアント１０００とサーバ１１００との間のルータ７５００が、例えば１または複数の帯域幅パラメータを使用し、リンクの帯域幅の一部がすでに他の接続のために予約されている可能性に鑑みて、要求された帯域幅がリンクの能力に適合するか否かを見積り、帯域幅の予約に成功した場合に、第１の種類のメッセージを転送し、そうでない場合には、例えばクライアント１０００またはサーバ１１００へと通信されるエラーを生成する。さらに、好都合には、ルータが、ルータがビジーであることを示す状態７５３０に入り、この状態においては、他の接続のための他の帯域幅の予約の要求を受け付けない。
【００７１】
ひとたび、ルータが第２の種類のメッセージ（同一ペアのクライアントおよびサーバに対して、サーバ１１００からクライアント１０００へ転送される確認であって、すべての含まれるルータが要求された帯域幅の予約に成功したことを確認するもの）を識別すると、レディ状態７５１０へと戻る。「Ｒ＿Ｂｕｓｙ」状態７５３０は、例えば第１の種類のメッセージ７１４０について生じうる再送信を排除するために必要とされ、ルータにおける帯域幅の予約の二重の更新を好都合に防止する。さらに、先の図との比較において、接続は第３の種類のメッセージ７１７０によって終了させられる。ここで、第３の種類のメッセージは、例えばクライアント１０００および第３の種類のメッセージ７１７０を発するサーバ１１００に保存された第１の種類のメッセージ７１４０と同じ帯域幅パラメータを含んでいる。第３の種類のメッセージ７１７０の受信の結果として、ルータ７５００は、自身の予約済みの帯域幅を減らす。メッセージの交換が信頼できるネットワークにもとづいて行われる場合、この動作が失敗する可能性はない。したがって第３の種類のメッセージ７１７０が失われる可能性はなく、したがってこの場合には、好ましくはこのメッセージの適切な取り扱いを確認するためのタイマは不要である。ルータにおける見積りのプロセスおよび保存のプロセスが、四角い囲み７５２０によって示されている。
【００７２】
図８が、メッセージの交換が信頼性に欠けるネットワークまたはリアルタイムの通信のためのトラフィッククラスをサポートしているネットワークにおいて行われる場合の本開示による方法の実施の形態のメッセージの流れの別の例を示している。
【００７３】
図４に示したメッセージの流れと比べて、やはり先のメッセージの流れと同様に、このメッセージの流れは、クライアント１０００とサーバ１１００との間で交換されるメッセージを転送するためのルータ７５００を備えている。すでに説明したように、信頼性に欠けるネットワークをサポートする図４におけるメッセージの流れをさらに詳しく述べるとき、好ましくはクライアント１０００とサーバ１１００との間で交換されるメッセージのより密接な監視およびルータ７５００における予防措置が必要である。
【００７４】
ここで、やはり第４の種類のメッセージ４１５０が、接続の終了の過程において必要とされる。理由は、３つのメッセージを必要とするあらゆるルータの更新の要件にある。３つのめっせーざいとは、第１の種類のメッセージ７１４０および第３の種類のメッセージ７１７０などの帯域幅を運ぶ通信を初期化する１つのメッセージと、メッセージ１１５０およびメッセージ８１５０「Ｔ＿ＦＩＮ＿ＡＣＫ」などの第１の種類のメッセージを確認する第２のメッセージと、メッセージ４１５０などの帯域幅の変更を委ねるための第３のメッセージと、である。この場合において、ルータがビジーであり、あるいは帯域幅の変更を支持できない場合に、ルータ７５００は「Ｒ＿Ｂｕｓｙ」を示す７５３０へと自身の状態を変化させ、空きの帯域幅が不充分である場合に、ルータはさらに後述されるように「Ｓ＿Ｅｒｒｏｒ」メッセージを生成する。ここで、帯域幅の割り当ておよび見積りは、ルータ７５００における四角囲み８５５０によってさらに示されている。
【００７５】
図９が、クライアント側から観察される図７のメッセージフローに関係する状態機械の例として状態および状態変化を示している。
【００７６】
ここで、以下の状態７１２０、１１１０、４１１０、および１１３０が可能である。
【００７７】
状態１１３０から状態７１２０への状態移行が、９１５０：Ｔ＿ＯＰＥＮ．ｒｅｑ（ｍｙ＿ｓｅｒｖｅｒ，ｂｗ）／ｃｏｎｎ＿ｂｗ＝ｂｗ，Ｔ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ，ｂｗ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＳＹＮに対応して生じる一方で、状態７１２０から状態４１１０への状態移行は、９３００：Ｔ＿ＳＹＮ＿ＥＲＲ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ，ｃｏｎｎ＿ｂｗ）に対応して可能である。他方で、クライアントについて、状態７１２０から状態１１１０への移行が、９２５０：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＡＣＫ＿ＡＣＫ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ），Ｔ＿ＯＰＥＮ．ｃｎｆ（ｏｋ），ｓｔｏｐ Ｔｉｍｅｒ＿ＳＹＮに従って生じる。おそらくは状態１１１０および状態４１１０の間のさらなる移行が、９４００：Ｔ＿ＣＬＯＳＥ．ｒｅｑ（）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ，ｃｏｎｎ＿ｂｗ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＦＩＮに対応してさらに存在する。移行９１００：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ａｎｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＡＣＫ＿ＡＣＫ（ｔｏ：ａｎｙ＿ｓｅｒｖｅｒ）、移行９２００：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ａｎｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＡＣＫ＿ＡＣＫ（ｔｏ：ａｎｙ＿ｓｅｒｖｅｒ）、移行９２００：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿ＳＹＮ／Ｔ＿ＳＹＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ，ｃｏｎｎ＿ｂｗ），ｒｅｓｔａｒｔ Ｔｉｍｅｒ＿ＳＹＮ、移行９３５０：Ｔ＿ＤＡＴＡ．ｒｅｑ／Ｔ＿ＤＡＴＡ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ）、移行９３５０：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＤＡＴＡ．ｉｎｄ、移行９３５０：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）／Ｔ＿ＡＣＫ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）、移行９３５０：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＡＣＫ＿ＡＣＫ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ）、および移行９４５０：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ，ｂｗ）、移行９４５０：Ｔ＿ＳＹＮ＿ＮＡＣ（ｆｒｏｍ：ｍｙ＿ｓｅｒｖｅｒ）／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ，ｂｗ）、移行９４５０：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）／Ｔ＿ＡＣＫ＿ＡＣＫ（ｔｏ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ）、移行９４５０：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿ＦＩＮ／Ｔ＿ＦＩＮ（ｔｏ：ｍｙ＿ｓｅｒｖｅｒ，ｃｏｎｎ＿ｂｗ），ｒｅｓｔａｒｔ Ｔｉｍｅｒ＿ＦＩＮの場合、それぞれの状態（それぞれ、１１３０、７１２０、９３５０、および９４５０）が維持される。
【００７８】
ここで、帯域幅の予約が接続の管理に追加される場合、好ましくは必要な帯域幅の要件が、パラメータとしてメッセージ１０１０に与えられる。例えば、帯域幅は、例えばリンクの使用割合などの代案の代わりに生の帯域幅にて表現されてよく、例えばクライアントからサーバへの方向および逆のサーバからクライアントへの方向の各々について異なる値を含むことができる。さらに、より手の込んだ帯域幅の表現も可能である。例えば、ハードな保証が提供される専用の帯域幅およびソフトな保証しか提供されない共有の帯域幅である。さらに、この帯域幅または一式の帯域幅パラメータが、第１の種類のメッセージ７１４０および第３の種類のメッセージ７１７０にも加えられる。帯域幅は、例えばメッセージ１０１０の受信時に接続の帯域幅として保存され、その後に第１の種類のメッセージ７１４０および第３の種類のメッセージ７１７０の両方に使用される。第４の種類のメッセージ４１５０が、ルータ７５００における正しい帯域幅の更新を保証する。改善として、第３の種類のメッセージ７１７０の帯域幅パラメータが０である場合、第４の種類のメッセージ４１５０を省略することができる。
【００７９】
図１０が、図８のメッセージの流れにおいて説明した本開示による方法の実施の形態においてサーバがとることができる状態および状態変化を示す状態機械の例を示している。
【００８０】
この状態機械が、以下の状態および状態変化、すなわち１００１０「Ｓ＿ＷａｉｔＣｌｏｓｅＲｓｐ」、１００２０「Ｓ＿Ｅｒｒｏｒ」、１２４０、１００３０「Ｓ＿ＷａｉｔＯｐｅｎＲｓｐ」、７５１０、８５６０、１２３０、および１００４０「Ｓ＿ＷａｉｔＣｌｏｓｅＲｓｐ」を有している。
【００８１】
状態１２４０が１０１００：Ｔ＿ＬＩＳＴＥＮ．ｒｅｑ／−によって開始され、状態１００３０への移行が、１０１５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｂｗ）／Ｔ＿ＯＰＥＮ．ｉｎｄ（ｍｙ＿ｃｌｉｅｎｔ），ｓｔａｒｔ Ｔｉｍｅｒ＿ Ｒｓｐに対応して生じる。状態１００３０から状態１００２０への移行が、１０２００：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿Ｒｓｐ／ｓｔｏｐ Ｔｉｍｅｒ＿Ｒｓｐ，Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）によって生じ、ここから状態１００１０への移行が、１０３００：Ｔ＿ＯＰＥＮ．ｒｓｐ（）／Ｔ＿ＣＬＯＳＥ．ｉｎｄ（）に対応して生じる。
【００８２】
さらに、状態１００３０および状態７５１０の間の状態移行が、１０４５０：Ｔ＿ＯＰＥＮ．ｒｓｐ（）／ｓｔｏｐ Ｔｉｍｅｒ＿Ｒｓｐ，Ｔ＿ＳＹＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＡＣＫに対応して生じる。
【００８３】
さらに、そこから状態１２３０への移行が、移行１０６００：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／ｓｔｏｐ Ｔｉｍｅｒ＿ＡＣＫおよび移行１０６００：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）／ｓｔｏｐ Ｔｉｍｅｒ＿ＡＣＫ，Ｔ＿ＤＡＴＡ．ｉｎｄ （ｄａｔａ）に従って可能であり、状態７５１０から状態８５６０へと、１０５５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｂｗ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＡＣＫに従って可能である。さらに、状態１２３０から状態１００４０への状態移行が、１０７００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｂｗ）／Ｔ＿ＣＬＯＳＥ．ｉｎｄ（）によって生じる。そこから、状態８５６０へのさらなる状態移行が、１０８００：Ｔ＿ＣＬＯＳＥ．ｒｓｐ／Ｔ＿ＦＩＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ），ｓｔａｒｔ Ｔｉｍｅｒ＿ＡＣＫに従って可能であり、再び出発点へと状態８５６０から状態１２４０への移行が、１０８５０：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ）／ｓｔｏｐ Ｔｉｍｅｒ＿ＡＣＫに従って可能である。
【００８４】
それぞれの状態（それぞれ、１００１０、１００２０、１２４０、１００３０、７５１０、１２３０、および１００４０）が、移行１０３５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ，ｂｗ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）、移行１０３５０：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／−、移行１０２５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ，ｂｗ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ａｎｙ＿ｃｌｉｅｎｔ）、移行１０２５０：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−、移行１０９００：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ａｎｙ＿ｃｌｉｅｎｔ）／−、移行１０４００：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−、移行１０５００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｂｗ）／Ｔ＿ＳＹＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ）、移行１０５００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ，ｂｗ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行１０５００：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−、移行１０５００：ｔｉｍｅｏｕｔ Ｔｉｍｅｒ＿ＡＣＫ／Ｔ＿ＳＹＮ＿ＡＣＫ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ），ｒｅｓｔａｒｔ Ｔｉｍｅｒ＿ＡＣＫ、移行１０６５０：Ｔ＿ＤＡＴＡ．ｒｅｑ（ｄａｔａ）／Ｔ＿ＤＡＴＡ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）、移行１０６５０：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）／Ｔ＿ＤＡＴＡ．ｉｎｄ（ｄａｔａ），移行１０６５０：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−、移行１０６５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ，ｂｗ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行１０６５０：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−、および移行１０７５０：Ｔ＿ＤＡＴＡ．ｒｅｑ（ｄａｔａ）／Ｔ＿ＤＡＴＡ（ｔｏ：ｍｙ＿ｃｌｉｅｎｔ，ｄａｔａ）、移行１０７５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｍｙ＿ｃｌｉｅｎｔ，ｂｗ）／−、移行１０７５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ，ｂｗ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｔｏ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）、移行１０７５０：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ）／−に対応して維持される。また、状態１００１０から状態１２４０への移行が、１０９５０：Ｔ＿ＣＬＯＳＥ．ｒｓｐ／−に従って生じる。
【００８５】
さらに、例えばサーバが、第１の種類のメッセージ７１４０および第３の種類のメッセージ７１７０について、帯域幅パラメータをさらに受信する。状態８５６０が、好ましくはサーバによる第４の種類のメッセージ４１５０の待機を生じさせるために、導入される。好ましくは、第６の種類のメッセージ４１７０の送信時に開始され、時間切れの場合に再送信を生じさせるタイマによって、第６の種類のメッセージ４１７０も確実な送信に保護される。サーバにおけるすべてのタイマは、並行して動作することがないため、好ましくは１つのタイマにて好都合に実現することができる。
【００８６】
図１１が、図８に示して説明した本開示による方法の実施の形態においてルータがとることができる状態および状態変化についての状態機械の例を示している。
【００８７】
以下の状態、すなわち７５１０、１１５４０「Ｒ＿Ｂｕｓｙ＿Ｆｉｎ」、および１１５３０「Ｒ＿Ｂｕｓｙ＿Ｓｙｎ」が、例えば可能である。
【００８８】
状態７５１０の開始が、１１１００：Ｒ＿ｂｗ＝０，ｅｒｒ＿ｆｌａｇ＝ｆａｌｓｅに従って生じる。ここから、状態１１５４０への状態変化が、１１４００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｃｌｉｅｎｔ，ｔｏ：ｓｅｒｖｅｒ，ｂｗ）／Ｒ＿ｃｌｉｅｎｔ＝ｃｌｉｅｎｔ，Ｒ＿ｓｅｒｖｅｒ＝ｓｅｒｖｅｒ，Ｒ＿ｂｗ−＝ｂｗ，Ｔ＿ＦＩＮ（ｆｒｏｍ：ｃｌｉｅｎｔ，ｔｏ：ｓｅｒｖｅｒ，ｂｗ）に対応して生じる。状態１１５４０から戻る移行が、１１５００：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ）／ｅｒｒ＿ｆｌａｇ＝ｆａｌｓｅ，Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ）に対応して生じることができる。また、状態７５１０から状態１１５３０への状態変化が、移行１１２００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｃｌｉｅｎｔ，ｔｏ：ｓｅｒｖｅｒ，ｂｗ），（Ｒ＿ｂｗ＋ｂｗ）≦ＭＡＸ＿ＢＷ／Ｒ＿ｃｌｉｅｎｔ＝ｃｌｉｅｎｔ，Ｒ＿ｓｅｒｖｅｒ＝ｓｅｒｖｅｒ，Ｒ＿ｂｗ＋＝ｂｗ，Ｔ＿ＳＹＮ（ｆｒｏｍ：ｃｌｉｅｎｔ，ｔｏ：ｓｅｒｖｅｒ，ｂｗ）、または移行１１２００：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｃｌｉｅｎｔ，ｔｏ：ｓｅｒｖｅｒ，ｂｗ），（Ｒ＿ｂｗ＋ｂｗ）＞ＭＡＸ＿ＢＷ／Ｒ＿ｃｌｉｅｎｔ＝ｃｌｉｅｎｔ，Ｒ＿ｓｅｒｖｅｒ＝ｓｅｒｖｅｒ，ｅｒｒ＿ｆｌａｇ＝ｔｒｕｅ，Ｔ＿ＳＹＮ＿ＥＲＲ（ｆｒｏｍ：ｃｌｉｅｎｔ，ｔｏ：ｓｅｒｖｅｒ）に対応して生じることができ、状態１１５３０から出発点への状態変化が、１１３５０：Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ）／ｅｒｒ＿ｆｌａｇ＝ｆａｌｓｅ，Ｔ＿ＡＣＫ＿ＡＣＫ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ）に対応して生じることができる。状態１１５３０および１１５４０の間の他の状態変化が、１１３００：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｃｌｉｅｎｔ，ｔｏ：ｓｅｒｖｅｒ，ｂｗ）／Ｔ＿ＦＩＮ（ｆｒｏｍ：ｃｌｉｅｎｔ，ｔｏ：ｓｅｒｖｅｒ，ｂｗ）に対応して生じる。
【００８９】
それぞれの状態（それぞれ、７５１０、１１５４０、および１１５３０）は、移行１１１５０：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２）／Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２）、移行１１１５０：ＯＴＨＥＲ＿ＭＳＧ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２，．．．）／ＯＴＨＥＲ＿ＭＳＧ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２，．．．）、移行１１４５０：Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：Ｒ＿ｓｅｒｖｅｒ，ｔｏ：Ｒ＿ｃｌｉｅｎｔ）／Ｔ＿ＦＩＮ＿ＡＣＫ（ｆｒｏｍ：Ｒ＿ｓｅｒｖｅｒ，ｔｏ：Ｒ＿ｃｌｉｅｎｔ）、移行１１４５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ，ｂｗ）／Ｔ＿ＦＩＮ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ，ｂｗ）、移行１１４５０：Ｔ＿ＦＩＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ，ｔｏ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ，ｂｗ）／−、移行１１４５０：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２）／Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２）、または移行１１４５０：ＯＴＨＥＲ＿ＭＳＧ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２，．．．）／ＯＴＨＥＲ＿ＭＳＧ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２，．．．）、ならびに移行１１２５０：Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｓｅｒｖｅｒ，ｔｏ：ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＡＣＫ（ｆｒｏｍ：ｓｅｒｖｅｒ，ｔｏ：ｃｌｉｅｎｔ）、移行１１２５０：Ｔ＿ＳＹＮ＿ＥＲＲ（ｆｒｏｍ：ｓｅｒｖｅｒ，ｔｏ：ｃｌｉｅｎｔ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｆｒｏｍ：ｓｅｒｖｅｒ，ｔｏ：ｃｌｉｅｎｔ）、移行１１２５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ，ｂｗ）＆＆（ｅｒｒ＿ｆｌａｇ＝＝ｆａｌｓｅ）／Ｔ＿ＳＹＮ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ，ｂｗ）、移行１１２５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ，ｂｗ）＆＆（ｅｒｒ＿ｆｌａｇ＝＝ｔｒｕｅ）／Ｔ＿ＳＹＮ＿ＥＲＲ（ｆｒｏｍ：Ｒ＿ｃｌｉｅｎｔ，ｔｏ：Ｒ＿ｓｅｒｖｅｒ）、移行１１２５０：Ｔ＿ＳＹＮ（ｆｒｏｍ：ｏｔｈｅｒ＿ｃｌｉｅｎｔ，ｔｏ：ｏｔｈｅｒ＿ｓｅｒｖｅｒ，ｂｗ）／−、移行１１２５０：Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２）／Ｔ＿ＤＡＴＡ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２）、または移行１１２５０：ＯＴＨＥＲ＿ＭＳＧ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２，．．．）／ＯＴＨＥＲ＿ＭＳＧ（ｆｒｏｍ：ｎｏｄｅ１，ｔｏ：ｎｏｄｅ２，．．．）に従って維持される。
【００９０】
例えば、ルータは、接続の開放および閉鎖のプロセス間の状態を集めなければならない。デフォルトの状態は、ルータがレディである状態７５１０であり、そこからパケットをそれぞれの宛て先へと転送する。しかしながら、ルータが第１の種類のメッセージ７１４０または第３の種類のメッセージ７１７０を受信する場合、好ましくはルータの帯域幅の予約が更新され、これを行う際に、ルータが状態１１５３０および１１５４０へとそれぞれ移行する。ルータが初期の状態７５１０にあり、割り当てるための充分な帯域幅を有するメッセージ７１４０を受信する場合、それは帯域幅を更新し、メッセージをサーバへと転送する。他方で、利用できる帯域幅が不充分である場合、ルータは、帯域幅の更新を防止するためにｅｒｒｏｒ＿ｆｌａｇを発し、メッセージ７１４０の転送の代わりにエラーメッセージがサーバへと設定される。好ましくは、ｅｒｒｏｒ＿ｆｌａｇを接続を閉じるときに帯域幅の更新を防止するために使用することができる。いずれの場合も、接続の確立に関わるクライアントおよびサーバのペアが、再送信に起因する多数の帯域幅の更新を防止するために、安全であるのが望ましい。状態７５１０にあってルータがメッセージ７１７０を受信する場合、やはりクライアントおよびサーバのペアは、メッセージ７１４０に関して安全であり、ルータの帯域幅が好ましくはｂｗによって増やされる。
【００９１】
状態１１５３０において、保存されたクライアント・サーバ・ペアに適合する第４の種類のメッセージ４１５０が受信された場合、ｅｒｒｏｒ＿ｆｌａｇが除去され、ルータが状態７５１０へと移行する。保存されたクライアント・サーバ・ペアに適合するメッセージ７１７０が受信された場合、ルータは状態１１５４０へと移行する。好ましくは、メッセージ４１５０およびメッセージ４１７０を含むすべてのメッセージが転送される。保存されたクライアント・サーバ・ペアについてメッセージ７１４０が受信される場合と、ｅｒｒｏｒ＿ｆｌａｇが設定される場合は、例外である。状態１１５４０にあるとき、保存されたクライアント・サーバ・ペアに適合するメッセージ４１５０が受信された場合、ｅｒｒｏｒ＿ｆｌａｇが除去され、ルータが状態７５１０に移行する。この状態において、メッセージ４１５０を含むすべてのメッセージが転送される。好ましくは、接続の開放／閉鎖のたびに、ルータは、アドレスおよびポートで構成され得るクライアントおよびサーバの身元を参照する接続を特定する状態を保存する必要がある。例えば、最も単純なルータの実施例は、図１１に示されるように、ただ１つの接続の身元を保存することができる。あるいは、ルータがいくつかの接続の身元を保存することができ、その場合には、保存することができる接続の身元ごとに図１１に示したとおりの１つの状態機械を使用することができる。この場合、接続の身元に保存することができるメッセージ７１４０または７１７０が受信されるたびに、ルータが、図１１に示した状態および状態変化に従事する。ルータが接続の身元を保存できない場合、好ましくは、ルータは、メッセージ７１４０または７１７０を破棄し、それ以上の行為を行わない。
【００９２】
以下の図１２〜図２１は、本開示によるシステムによって同じやり方で取り扱うことができる本開示の方法の上述の実施の形態の方法によるエラーおよびそれらエラーの取り扱いの種々の例を示している。
【００９３】
図１２が、図１のさらなる詳細における本開示による方法の実施の形態において生じうるエラーの事例の例を示している。
【００９４】
この場合、例えばサーバ１２００がビジーである可能性があり、したがって現時点においてサーバ１２００が別の接続に応対していることを示す状態１２３０にあるため、第１の種類のメッセージ１１４０を転送できない可能性がある。この場合、アプリケーションサーバ１３００との接続を確立する代わりに、エラーメッセージ１２１５０「Ｔ＿ＳＹＮ＿ＥＲＲ」が生成され、このエラーメッセージがクライアント１１００に受信されたとき、クライアントが、クライアントが接続されると状態１１１０ではなく、接続が閉じられる状態１１３０へと移行する。
【００９５】
図１３および図１４は、喪失または破棄の可能性があるメッセージの伝送を監視するためのタイマの使用を示している。
【００９６】
図１３は、図１においてさらに詳しく検討した本開示による方法の実施の形態においてエラーが生じる可能性がある事例を示している。この場合、第１の種類のメッセージが失われ（１３１４０）、結果としてサーバ１２００によって受信または処理されることがなく、サーバ１２００が状態１２１０のままとなる可能性がある。しかしながら、この場合に、第１の所定の期間を測定する第１のクライアントタイマが時間切れとなり、クライアント１１００とサーバ１２００との間の接続を確立するために、第１の種類のメッセージ１１４０の再送信を生じさせる。第１の所定の期間は、好ましくは、サーバ１２００に第２の種類のメッセージ１１５０を生成するための充分な処理時間ならびに両方向の充分な伝送時間を許すようなやり方で決められる。第２の種類のメッセージ１１５０がクライアント１１００によって受信されるとき、さらなる取り扱いは、図１において検討したとおりである。
【００９７】
図１４は、さらに詳しく図４に関して検討した本開示による方法の実施の形態において生じる可能性がある別のエラーおよびその取り扱いを説明している。この場合、参照符号１４１５０で示された第２の種類のメッセージが失われる。この場合にも、図１３と同様に参照符号１３０１０によって示される時間切れが生じ、第１の種類のメッセージ１１４０の再送信を生じさせる。これが、サーバ１２００に到着したこのメッセージが検出され、初めて受信された第１の種類のメッセージ１１４０によって引き起こされる状態１２１０から１２２０への状態変化ゆえに、このメッセージ１１４０が再送信され、このメッセージのソースが最初であることをサーバが特定することを可能にする。サーバに、再送信されたメッセージ１１４０を処理することなく破棄し、接続された状態１２３０へと状態を変化させ、確認のための第２の種類のメッセージ１１５０を送信させる。
【００９８】
図１５は、図１においてさらに詳しく検討した本開示による方法の実施の形態に関して、メッセージの交換において生じうる別のエラーの事例の例を説明している。この場合に、アプリケーションサーバ１３００におけるアプリケーションのクラッシュの場合に何が生じうるのかが検討される。ここで、サーバ１２００がメッセージ１３１０を送信しているが、クラッシュしたアプリケーション１３２０から応答を受信することはない。これは、第２の所定の期間を測定する第１のサーバタイマにおけるタイムアウト１５２５０につながるが、第２の所定の期間の大きさを決める際には、両方向のメッセージの伝達ならびにアプリケーションサーバがメッセージ１３１０を処理して応答１３２０を生成するための時間が考慮されるべきである。タイムアウト１５２５０に起因する第１のサーバタイマの時間切れが、エラーを示す状態６５５０を生成し、エラーメッセージ１５１５０をクライアントへと送信する。第１の種類のメッセージ１１４０のさらなる送信が、サーバ１２００からのエラーメッセージ１５１４０につながり、エラーメッセージ１５１５０または１５１４０に応答したアプリケーションクライアントへの対応するメッセージ１５０１０につながる。どちらの場合も、クライアントは接続を閉じ、状態１１３０に移行する。
【００９９】
アプリケーションサーバがメッセージ１３２０ Ｔ＿ＯＰＥＮ．ｒｓｐによってサーバに応答する場合、サーバが、メッセージ１３７０ Ｔ＿ＣＬＯＳＥ．ｉｎｄを使用して接続が実際に閉じられた旨をアプリケーションサーバに通知し、接続確立の要求の受信の準備ができた状態１２１０ Ｓ＿Ｌｉｓｔｅｎへと戻る。
【０１００】
図１６は、図４においてメッセージの流れを詳しく検討した本開示による方法の実施の形態においてエラーをどのように取り扱うことができるのかについての例を示している。
【０１０１】
ここでもやはり、信頼できるネットワークにおける事例においてすでに検討したように、サーバ１１００がビジーであり、要求を受けて接続を確立することができない。したがって、クライアント１１００へと知らせるべきエラーメッセージ１２１５０が生成される。これにより、第３の種類のメッセージ１１５０を発する接続閉鎖の動作がクライアント１１００において生じ、この第３の種類のメッセージ１１５０が、サーバ１２００から発せられる第６の種類のメッセージ４１７０によって確認される。次いで、クライアントが状態１１３０に移行する。
【０１０２】
図１７は、図４においてさらに詳しく検討したようにメッセージの交換が信頼性に欠けるネットワークにもとづく本開示による方法の実施の形態において生じうるエラーの事例を示している。信頼性に欠けるネットワークにおいては、あらゆるメッセージに破損または喪失の可能性があるため、第２の種類のメッセージ１１５０も、適切な取り扱いに関して監視されるのが望ましい。そうでない場合、喪失により、サーバは最初のビジーにおける「Ｓ＿Ｃｏｎｎｅｃｔｅｄ」状態１２３０のままであるかもしれず、しかし一方、接続１２１５０を確立するリクエストのエラーメッセージに応答することが、参照符号１７１５０で表される他のクライアントから切断し、状態１２１０で再び新たな接続のために利用可能となる。しかしながら、エラーメッセージのクライアント１１００への到達が遅すぎ、第１の種類のメッセージ１１４０の再送信を引き起こしたタイムアウト１３０１０の後、第１の種類のメッセージ１１４０により、サーバがアプリケーションサーバ１３００との接続を開くとともにデータ１１６０の送信を開始し、データ１１６０は、第２の種類のメッセージ１４１５０が失われたときに、プロトコルエラー１７１６０を生成する。
【０１０３】
図１８〜図２１は、図８および関連の説明においてさらに詳しく検討および図示した本開示による方法の実施の形態において生じうる別のエラーの事例を示している。
【０１０４】
そこでは、ルータ７５００がビジーであり、あるいは帯域幅を利用できないがゆえに帯域幅の変更の要求に応えることができず、この状況ゆえのエラーメッセージを生成する。
【０１０５】
図１８が、その状況を取り扱う第１の事例を示している。第１の種類のメッセージ７１４０を受信すると、ルータ２１５００が、２１５２０において帯域幅の割り当てを拒絶し、エラーフラグを設定する。これが、ルータ７５００へのエラーメッセージ２０１４０の送信につながり、これがクライアント１１００へと転送される。ルータ７５００が、２０５４０においてエラーフラグを設定する。他方で、エラーメッセージ２０５４０を受信したクライアントは、接続の終了を開始し、エラーによる終了メッセージ２０１７０「Ｔ＿ＦＩＮ＿ＥＲＲ」を送信する。これが、ルータ２１５００へと転送され、確認メッセージ４１７０が生成され、確認メッセージ４１７０がクライアント１１００に到着すると、エラーメッセージ１２０２０「Ｔ＿ＯＰＥＮ．ｅｒｒ」の生成が引き起こされる。
【０１０６】
図１９は、図１８において検討したものと同じエラーの事例の例を示しているが、メッセージの流れおよび取り扱いがわずかに変わっている。第１の種類のメッセージ７１４０の受信時に、ルータ２１５００が１９５２０においてｅｒｒｏｒ＿ｆｌａｇを設定せず、クライアントへのエラーメッセージ２１１４０において帯域幅情報を送信することがない。このように、先の例とは対照的に、クライアント１１００が、図８において述べたとおりの通常の接続終了を辿ることができる。
【０１０７】
この場合、ルータは、エラーの事例１９５３０「Ｒ＿ＢｕｓｙＥＲＲ」において異なる状態に入る。通常の接続の終了は、利用可能な場合に帯域幅の割り当てを解放する。図１９に示した例の場合には、メッセージの取り扱いがより容易であり、送信を必要とするメッセージの量がより少ない。しかしながら、図１８および１９に示したどちらの場合も、ルータを、好ましくはエラーメッセージ２１１４０および２０１４０を発するときにサーバの一部の機能を実行するように構成する必要がある。
【０１０８】
そのようなルータの変更を避けるために、考えられる代案は、エラーの取り扱いをサーバ１２００へと転送することであり、これが図２０および図２１の例で検討される。
【０１０９】
図２０は、図８において検討した本開示による方法の実施の形態においてルータがビジーであってメッセージの交換が信頼性に欠けるネットワークにもとづくエラーの事例の取り扱いの例を示している。
【０１１０】
ここで、図１８において検討した事例と同様に、ひとたび転送された第１の種類のメッセージ７１４０を受信しかつ利用可能な帯域幅を有していない場合、ルータがｅｒｒｏｒ＿ｆｌａｇを設定し、この場合には新しいエラーメッセージ２０１４０をサーバ１２００へと転送し、サーバ１２００が帯域幅パラメータを含むエラーメッセージ２０１４０を生成する。サーバによるさらなる追加の仕事は、エラーがクライアント１１００によって第７の種類のメッセージ４１５０にて発せられたときに接続の終了へと応答することである。
【０１１１】
さらに図２１が、図１９に関連して検討したエラーの取り扱いの例を示しているが、この場合にはエラーの取り扱いがサーバ１２００において行われる。変更として、図１９における手順が、エラーメッセージ２１１４０がサーバ１２００へと転送されて、サーバ１２００がエラーメッセージ２１１４０の送信および接続の終了の取り扱いを担当するようなやり方で変更される。
【０１１２】
信頼性に欠けるネットワークに関して、ルータにおける帯域幅の更新について考えられる代案は、それを７１４０の代わりの第２の種類のメッセージ１１５０および／または７１７０の代わりのメッセージ４１７０によって行うことである。ここで、第１のメッセージ７１４０および／または７１７０が受信されたとき、クライアント／サーバペアを上述のように保存でき、さらにフラグＥＲＲ＿ｆｌａｇを設定することができる。しかしながら、この場合に、帯域幅パラメータがメッセージ１１５０および４１７０によって運ばれる。エラーのこの場合に、メッセージ１１５０および／または４１７０による帯域幅の更新が行われていないため、エラーメッセージ２１１４０はいかなる帯域幅パラメータも運ばず、帯域幅なしに接続の終了につながる。したがって、メッセージ４１５０を、このエラーの場合にさらに最適化することができる。
【０１１３】
図２２が、同様の文脈において接続がメッセージ１０７０「Ｔ＿ＣＬＯＳＥ．ｒｅｑ」を送信しているアプリケーションクライアント１０００によって閉じられる場合を示している図４に加えて、別の選択肢を例示している。あるいは、接続を、メッセージ１０７０「Ｔ＿ＣＬＯＳＥ．ｒｅｑ」を送信するアプリケーションサーバ１３００によって閉じることもできる。この場合にも、結果としての工程は同じである。Ｔ／ＣＯサーバ１２００が、メッセージ１０７０「Ｔ＿ＣＬＯＳＥ．ｒｅｑ」を受信したときに、メッセージ１１７０「Ｔ＿ＦＩＮ」を送信し、タイマを開始させ、状態４１１２「Ｓ＿ＷａｉｔＦｉｎＡｃｋ」へと入る。Ｔ／ＣＯクライアント１１００が、メッセージ１１７０「Ｔ＿ＦＩＮ」を受信したときに、メッセージ１３７０「Ｔ＿ＣＬＯＳＥ．ｉｎｄ」をアプリケーションクライアントへと発し、アプリケーションクライアントが、Ｔ／ＣＯクライアント１１００へのメッセージ４３８０「Ｔ＿ＣＬＯＳＥ．ｒｓｐ」で応答し、Ｔ／ＣＯクライアント１１００が、Ｔ／ＣＯサーバへとメッセージ４１７０「Ｔ＿ＦＩＮ＿ＡＣＫ」を順に送信し、状態１１３０「Ｃ＿Ｃｌｏｓｅｄ」へと入る。Ｔ／ＣＯサーバは、メッセージ４１７０「Ｔ＿ＦＩＮ＿ＡＣＫ」を受信したとき、自身のタイマを停止させ、メッセージ４０８０「Ｔ＿ＣＬＯＳＥ．ｃｎｆ」をアプリケーションサーバ１３００へと送信し、状態１２４０「Ｓ＿Ｌｉｓｔｅｎ」へと入る。
【０１１４】
図２３が、同様の文脈における図４に加えて、接続の閉鎖がＴ／ＣＯクライアント１１００およびＴ／ＣＯサーバ１２００の両方において同時に要求される事例を示している。この場合には、Ｔ／ＣＯクライアント１１００およびＴ／ＣＯサーバ１２００からのメッセージ１０７０「Ｔ＿ＦＩＮ」がネットワークにおいて交差する。メッセージ１０７０「Ｔ＿ＦＩＮ」がＴ／ＣＯクライアント１１００において受信されるとき、Ｔ／ＣＯクライアント１１００は、タイマを停止させ、Ｔ／ＣＯサーバ１２００へとメッセージ４１７０「Ｔ＿ＦＩＮ＿ＡＣＫ」を送信し、状態１１３０「Ｃ＿Ｃｌｏｓｅｄ」へと移行する。メッセージ１０７０「Ｔ＿ＦＩＮ」がＴ／ＣＯサーバ１２００において受信されるとき、Ｔ／ＣＯサーバ１２００は、タイマを停止させ、Ｔ／ＣＯクライアント１１００へとメッセージ４１７０「Ｔ＿ＦＩＮ＿ＡＣＫ」を送信し、状態１２４０「Ｓ＿Ｌｉｓｔｅｎ」へと移行する。
【０１１５】
さらに本開示は、サーバおよび／またはクライアントにおいて具現化されるようなシステムの機能の任意のいずれかを、ハードウェア、コンピュータソフトウェア、または両者の組み合わせとして実現できることを含む。システム（例えば、クライアントおよび／またはサーバ）は、汎用のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または他のプログラマブルな論理デバイス、ディスクリートなゲートまたはトランジスタ論理回路、ディスクリートハードウェア部品、あるいは本明細書に記載の機能を実行するように設計された任意の組み合わせを含むことができる。汎用プロセッサは、マイクロプロセッサまたは状態機械であってよい。プロセッサを、例えばＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアが組み合わせられた１つ以上のマイクロプロセッサ、あるいは任意の他のそのような構成など、演算装置の組み合わせとして実現することもできる。クライアントおよび／またはサーバにおいて使用されるプロセッサが、本開示のいずれかの方法を実行するように構成される。
【０１１６】
さらに本開示は、任意の種類の演算装置上で実行されるように構成され、例えばサーバおよび／またはクライアントにおいて使用されるように構成され、すなわち処理エンジンを含んでいる装置において実行されるように構成されたコード部分を含んでいるコンピュータプログラム製品を含む。コンピュータプログラム製品のソフトウェアコードが、演算装置上で実行されたときに、第１の種類のメッセージをサーバへと送信することによって接続の確立を要求する機能をクライアントにおいて提供する。サーバにおいては、ソフトウェアが、演算装置上で実行されたときに、サーバの接続につながる第２の種類のメッセージをクライアントへと送信することによって接続を確立する能力を裏付ける。ソフトウェアは、好ましくは、第１の種類のメッセージの送信によって第１の最大応答時間としての第１の所定の期間を測定する第１のクライアントタイマが開始されるように構成され、好ましくは第２の種類のメッセージまたはデータメッセージの受信をもって第１のクライアントタイマを停止させるように構成される。さらにソフトウェアは、好ましくは、第３の種類のメッセージの送信によって接続が閉じられるように構成される。
【０１１７】
さらにソフトウェアは、好ましくは、第２の種類のメッセージが受信されることなく第１の所定の期間が過ぎた場合に別の第１の種類のメッセージが送信されるように構成される。さらにソフトウェアは、好ましくは、サーバが接続を引き受けることができない場合にエラーメッセージを返すように構成される。
【０１１８】
さらにソフトウェアは、好ましくは、
ａ）第２の種類のメッセージの受信が、クライアントの接続につながり、
ｂ）クライアントが第２の種類のメッセージの受信を確認するためにサーバへと第４の種類のメッセージを送信する
ように構成される。
【０１１９】
さらにソフトウェアは、好ましくは、第２の種類のメッセージの送信によって第２の最大応答時間としての第２の所定の期間を測定する第１のサーバタイマが開始され、第４の種類のメッセージの受信によって第１のサーバタイマが停止されるように構成される。
【０１２０】
さらにソフトウェアは、好ましくは、サーバが接続を確立できない場合にクライアントの非接続につながる第５の種類のメッセージをクライアントへと送信するように構成することができる。
【０１２１】
さらにソフトウェアは、好ましくは、第３の種類のメッセージの送信によって第３の最大応答時間としての第３の所定の期間を測定する第２のクライアントタイマが開始されるように構成される。
【０１２２】
さらにソフトウェアは、好ましくは、サーバが第６の種類のメッセージを送信することによって第３の種類のメッセージの受信を確認するように構成される。
【０１２３】
さらにソフトウェアは、好ましくは、第６の種類のメッセージの送信によって第４の最大応答時間としての第４の所定の期間を測定する第２のサーバタイマが開始されるように構成される。
【０１２４】
さらにソフトウェアは、好ましくは、クライアントにおける第６の種類のメッセージの受信によって第２のクライアントタイマが停止され、クライアントによる第４の種類のメッセージの送信が生じるように構成される。
【０１２５】
さらにソフトウェアは、好ましくは、サーバによる第３の種類のメッセージの送信によって第３の最大応答時間としての第３の所定の期間を測定する第２のサーバタイマが開始されるように構成される。
【０１２６】
さらにソフトウェアは、好ましくは、第３の種類のメッセージを受信するクライアントが、第３の種類のメッセージの受信を第６の種類のメッセージを送信することによって確認するように構成される。
【０１２７】
さらにソフトウェアは、好ましくは、第６の種類のメッセージの送信によって第４の最大応答時間としての第４の所定の期間を測定する第２のクライアントタイマが開始されるように構成される。
【０１２８】
さらにソフトウェアは、好ましくは、サーバにおける第６の種類のメッセージの受信によって第２のサーバタイマが停止され、クライアントによる第４の種類のメッセージの送信が生じるように構成される。
【０１２９】
さらにソフトウェアは、好ましくは、クライアントとサーバとの間のメッセージのうちの少なくとも１つがルータを通過でき、この少なくとも１つのメッセージが、リソース予約の要求を含んでおり、ルータが要求されたリソースを提供できる場合に限ってこの少なくとも１つのメッセージを転送する。
【０１３０】
さらにソフトウェアは、好ましくは、ルータが少なくとも１つのメッセージを転送する場合に、このリソース予約の要求に関する接続の確立に関わるクライアント・サーバ・ペアに関係する第２の種類のメッセージの受信まで、さらなるリソース予約の要求を一時的に停止するように構成される。
【０１３１】
さらにソフトウェアは、好ましくは、接続が閉じられる場合にリソースの予約を取り消すために少なくとも１つのメッセージが使用されるように構成される。
【０１３２】
さらにソフトウェアは、好ましくは、クライアントおよびサーバのそれぞれが、それぞれのアプリケーションクライアントとそれぞれのアプリケーションサーバとの間の接続を確立するように構成される。
【０１３３】
さらに本開示は、上述のコンピュータプログラム製品を保存する機械によって読み取ることができる一時的でない信号記憶媒体を含む。例えば、機械によって読み取ることができる一時的でない信号記憶媒体は、ＣＤＲＯＭまたはＤＶＤＲＯＭなどの光ディスク、磁気テープメモリ、ハードディスクまたはディスケットなどの磁気ディスクメモリ、ＵＳＢメモリスティックまたはフラッシュメモリなどの半導体メモリ、などであってよい。
【特許請求の範囲】
【請求項１】
接続指向の正順デリバリ環境における接続を管理するための方法であって、
ａ）クライアントが第１の種類のメッセージをサーバへと送信することによって、接続の確立を要求し、
ｂ）サーバが、サーバの接続につながる第２の種類のメッセージをクライアントへと送信することによって、接続の確立が可能であることを確認し、
ｃ）前記第１の種類のメッセージを送信することによって、第１の最大応答時間としての第１の所定の期間を測定する第１のクライアントタイマを始動し、前記第２の種類のメッセージまたはデータメッセージを受信することによって、前記第１のクライアントタイマが停止され、
ｄ）第３の種類のメッセージを送信することによって接続が閉じられる、方法。
【請求項２】
第２の種類のメッセージが受信されることなく前記第１の所定の期間が過ぎた場合に、別の第１の種類のメッセージが送信される請求項１に記載の方法。
【請求項３】
サーバが接続を引き受けることができない場合に、サーバがエラーメッセージを返す請求項１に記載の方法。
【請求項４】
ａ）前記第２の種類のメッセージを受信することが、クライアントの接続につながり、
ｂ）前記第２の種類のメッセージの受信を確認するための第４の種類のメッセージを、該クライアントがサーバに送信する、請求項１に記載の方法。
【請求項５】
前記第２の種類のメッセージを送信することによって、第２の最大応答時間としての第２の所定の期間を測定する第１のサーバタイマを始動し、前記第４の種類のメッセージを受信することによって、該第１のサーバタイマが停止される請求項４に記載の方法。
【請求項６】
サーバが接続を確立できない場合に、サーバがクライアントの非接続につながる第５の種類のメッセージをクライアントへと送信する請求項１に記載の方法。
【請求項７】
前記第３の種類のメッセージの送信により、第３の最大応答時間としての第３の所定の期間を測定する第２のクライアントタイマが始動される請求項１に記載の方法。
【請求項８】
サーバが第６の種類のメッセージを送信することによって、前記第３の種類のメッセージの受信を確認する請求項１に記載の方法。
【請求項９】
前記第６の種類のメッセージの送信により、第４の最大応答時間としての第４の所定の期間を測定する第２のサーバタイマが始動される請求項８に記載の方法。
【請求項１０】
クライアントにおける第６の種類のメッセージの受信により、前記第２のクライアントタイマが停止されるとともに、
クライアントが第４の種類のメッセージを送信する請求項７に記載の方法。
【請求項１１】
サーバによる前記第３の種類のメッセージの送信により、第５の最大応答時間としての第３の所定の期間を測定する第２のサーバタイマが始動される請求項１に記載の方法。
【請求項１２】
前記第３の種類のメッセージを受信するクライアントが第６の種類のメッセージを送信することによって、該第３の種類のメッセージの受信を確認する請求項１に記載の方法。
【請求項１３】
前記第６の種類のメッセージの送信により、第４の最大応答時間としての第４の所定の期間を測定する第２のクライアントタイマが始動される請求項１２に記載の方法。
【請求項１４】
サーバにおける前記第３の種類のメッセージの受信により、前記第２のサーバタイマが停止される請求項１１に記載の方法。
【請求項１５】
クライアントとサーバとの間の前記メッセージのうちの少なくとも１つが、ルータを通過し、
該少なくとも１つのメッセージが、リソース予約の要求を含んでおり、
前記ルータが、要求されたリソースを提供できる場合に限って前記少なくとも１つのメッセージを転送する、請求項１に記載の方法。
【請求項１６】
ルータが前記少なくとも１つのメッセージを転送する場合に、該ルータは該リソース予約の要求に関する接続の確立に関わるクライアント・サーバ・ペアに関係する第２の種類のメッセージの受信まで、さらなるリソース予約の要求を一時的に停止する請求項１５に記載の方法。
【請求項１７】
接続が閉じられる場合に、少なくとも１つのメッセージがリソースの予約を取り消すために使用される請求項１５に記載の方法。
【請求項１８】
予約されるリソースが帯域幅である請求項１５に記載の方法。
【請求項１９】
クライアントおよびサーバのそれぞれが、それぞれのアプリケーションクライアントとそれぞれのアプリケーションサーバとの間の接続を確立する請求項１に記載の方法。
【請求項２０】
接続指向の正順デリバリ環境において接続を管理するためのシステムであって、
サーバと、
クライアントと、
正順デリバリのネットワークと、 を備えており、
前記サーバが、請求項１に記載の方法のうちのサーバに関する動作のいずれかを実行するように構成され、
前記クライアントが、請求項１に記載の方法のうちのクライアントに関する動作のいずれかを実行するように構成されているシステム。
【請求項２１】
ルータを備えており、
クライアントとサーバとの間の前記メッセージのうちの少なくとも１つが、該ルータを通過しており、
該少なくとも１つのメッセージが、リソース予約の要求を含んでおり、
前記ルータが、要求されたリソースを提供できる場合に限って前記少なくとも１つのメッセージを転送する、請求項２０に記載のシステム。
【請求項２２】
前記ルータが前記少なくとも１つのメッセージを転送する場合に、該ルータは該リソース予約の要求に関する接続の確立に関わるクライアント・サーバ・ペアに関係する第２の種類のメッセージの受信まで、さらなるリソース予約の要求を一時的に停止する請求項２１に記載のシステム。
【請求項２３】
前記サーバおよび前記クライアントの各々が、前記サーバタイマおよび前記クライアントタイマのそれぞれを実現するためのただ１つのタイマを備えている請求項２０に記載のシステム。
【請求項２４】
サーバにおける前記第３の種類のメッセージの受信により、サーバは第４の種類のメッセージを送信する請求項１１に記載の方法。
【請求項２５】
サーバにおける第６の種類のメッセージの受信により、サーバは第４の種類のメッセージを送信する請求項１１に記載の方法。
【請求項２６】
前記第４の種類のメッセージの受信により、前記第２のサーバタイマが停止される請求項２４または２５に記載の方法。
【請求項２７】
サーバにおける第６の種類のメッセージの受信により、前記第２のサーバタイマが停止される請求項１１に記載の方法。
【請求項２８】
クライアントにおける前記第３の種類のメッセージの受信により、前記第２のクライアントタイマが停止される請求項７に記載の方法。
【請求項２９】
クライアントにおける第６の種類のメッセージの受信により、前記第２のクライアントタイマが停止される請求項７に記載の方法。
【請求項３０】
前記第４の種類のメッセージの受信により、前記第２のサーバタイマが停止される請求項１０に記載の方法。
【請求項１】
接続指向の正順デリバリ環境における接続を管理するための方法であって、
ａ）クライアントが第１の種類のメッセージをサーバへと送信することによって、接続の確立を要求し、
ｂ）サーバが、サーバの接続につながる第２の種類のメッセージをクライアントへと送信することによって、接続の確立が可能であることを確認し、
ｃ）前記第１の種類のメッセージを送信することによって、第１の最大応答時間としての第１の所定の期間を測定する第１のクライアントタイマを始動し、前記第２の種類のメッセージまたはデータメッセージを受信することによって、前記第１のクライアントタイマが停止され、
ｄ）第３の種類のメッセージを送信することによって接続が閉じられる、方法。
【請求項２】
第２の種類のメッセージが受信されることなく前記第１の所定の期間が過ぎた場合に、別の第１の種類のメッセージが送信される請求項１に記載の方法。
【請求項３】
サーバが接続を引き受けることができない場合に、サーバがエラーメッセージを返す請求項１に記載の方法。
【請求項４】
ａ）前記第２の種類のメッセージを受信することが、クライアントの接続につながり、
ｂ）前記第２の種類のメッセージの受信を確認するための第４の種類のメッセージを、該クライアントがサーバに送信する、請求項１に記載の方法。
【請求項５】
前記第２の種類のメッセージを送信することによって、第２の最大応答時間としての第２の所定の期間を測定する第１のサーバタイマを始動し、前記第４の種類のメッセージを受信することによって、該第１のサーバタイマが停止される請求項４に記載の方法。
【請求項６】
サーバが接続を確立できない場合に、サーバがクライアントの非接続につながる第５の種類のメッセージをクライアントへと送信する請求項１に記載の方法。
【請求項７】
前記第３の種類のメッセージの送信により、第３の最大応答時間としての第３の所定の期間を測定する第２のクライアントタイマが始動される請求項１に記載の方法。
【請求項８】
サーバが第６の種類のメッセージを送信することによって、前記第３の種類のメッセージの受信を確認する請求項１に記載の方法。
【請求項９】
前記第６の種類のメッセージの送信により、第４の最大応答時間としての第４の所定の期間を測定する第２のサーバタイマが始動される請求項８に記載の方法。
【請求項１０】
クライアントにおける第６の種類のメッセージの受信により、前記第２のクライアントタイマが停止されるとともに、
クライアントが第４の種類のメッセージを送信する請求項７に記載の方法。
【請求項１１】
サーバによる前記第３の種類のメッセージの送信により、第５の最大応答時間としての第３の所定の期間を測定する第２のサーバタイマが始動される請求項１に記載の方法。
【請求項１２】
前記第３の種類のメッセージを受信するクライアントが第６の種類のメッセージを送信することによって、該第３の種類のメッセージの受信を確認する請求項１に記載の方法。
【請求項１３】
前記第６の種類のメッセージの送信により、第４の最大応答時間としての第４の所定の期間を測定する第２のクライアントタイマが始動される請求項１２に記載の方法。
【請求項１４】
サーバにおける前記第３の種類のメッセージの受信により、前記第２のサーバタイマが停止される請求項１１に記載の方法。
【請求項１５】
クライアントとサーバとの間の前記メッセージのうちの少なくとも１つが、ルータを通過し、
該少なくとも１つのメッセージが、リソース予約の要求を含んでおり、
前記ルータが、要求されたリソースを提供できる場合に限って前記少なくとも１つのメッセージを転送する、請求項１に記載の方法。
【請求項１６】
ルータが前記少なくとも１つのメッセージを転送する場合に、該ルータは該リソース予約の要求に関する接続の確立に関わるクライアント・サーバ・ペアに関係する第２の種類のメッセージの受信まで、さらなるリソース予約の要求を一時的に停止する請求項１５に記載の方法。
【請求項１７】
接続が閉じられる場合に、少なくとも１つのメッセージがリソースの予約を取り消すために使用される請求項１５に記載の方法。
【請求項１８】
予約されるリソースが帯域幅である請求項１５に記載の方法。
【請求項１９】
クライアントおよびサーバのそれぞれが、それぞれのアプリケーションクライアントとそれぞれのアプリケーションサーバとの間の接続を確立する請求項１に記載の方法。
【請求項２０】
接続指向の正順デリバリ環境において接続を管理するためのシステムであって、
サーバと、
クライアントと、
正順デリバリのネットワークと、 を備えており、
前記サーバが、請求項１に記載の方法のうちのサーバに関する動作のいずれかを実行するように構成され、
前記クライアントが、請求項１に記載の方法のうちのクライアントに関する動作のいずれかを実行するように構成されているシステム。
【請求項２１】
ルータを備えており、
クライアントとサーバとの間の前記メッセージのうちの少なくとも１つが、該ルータを通過しており、
該少なくとも１つのメッセージが、リソース予約の要求を含んでおり、
前記ルータが、要求されたリソースを提供できる場合に限って前記少なくとも１つのメッセージを転送する、請求項２０に記載のシステム。
【請求項２２】
前記ルータが前記少なくとも１つのメッセージを転送する場合に、該ルータは該リソース予約の要求に関する接続の確立に関わるクライアント・サーバ・ペアに関係する第２の種類のメッセージの受信まで、さらなるリソース予約の要求を一時的に停止する請求項２１に記載のシステム。
【請求項２３】
前記サーバおよび前記クライアントの各々が、前記サーバタイマおよび前記クライアントタイマのそれぞれを実現するためのただ１つのタイマを備えている請求項２０に記載のシステム。
【請求項２４】
サーバにおける前記第３の種類のメッセージの受信により、サーバは第４の種類のメッセージを送信する請求項１１に記載の方法。
【請求項２５】
サーバにおける第６の種類のメッセージの受信により、サーバは第４の種類のメッセージを送信する請求項１１に記載の方法。
【請求項２６】
前記第４の種類のメッセージの受信により、前記第２のサーバタイマが停止される請求項２４または２５に記載の方法。
【請求項２７】
サーバにおける第６の種類のメッセージの受信により、前記第２のサーバタイマが停止される請求項１１に記載の方法。
【請求項２８】
クライアントにおける前記第３の種類のメッセージの受信により、前記第２のクライアントタイマが停止される請求項７に記載の方法。
【請求項２９】
クライアントにおける第６の種類のメッセージの受信により、前記第２のクライアントタイマが停止される請求項７に記載の方法。
【請求項３０】
前記第４の種類のメッセージの受信により、前記第２のサーバタイマが停止される請求項１０に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公表番号】特表２０１３−５０７０２３（Ｐ２０１３−５０７０２３Ａ）
【公表日】平成２５年２月２８日（２０１３．２．２８）
【国際特許分類】
【出願番号】特願２０１２−５３１４３６（Ｐ２０１２−５３１４３６）
【出願日】平成２２年９月３０日（２０１０．９．３０）
【国際出願番号】ＰＣＴ／ＥＰ２０１０／０６４６０５
【国際公開番号】ＷＯ２０１１／０３９３３２
【国際公開日】平成２３年４月７日（２０１１．４．７）
【出願人】（５１００００６３３）エスティー‐エリクソン、ソシエテ、アノニム (59)
【Ｆターム（参考）】
【公表日】平成２５年２月２８日（２０１３．２．２８）
【国際特許分類】
【出願日】平成２２年９月３０日（２０１０．９．３０）
【国際出願番号】ＰＣＴ／ＥＰ２０１０／０６４６０５
【国際公開番号】ＷＯ２０１１／０３９３３２
【国際公開日】平成２３年４月７日（２０１１．４．７）
【出願人】（５１００００６３３）エスティー‐エリクソン、ソシエテ、アノニム (59)
【Ｆターム（参考）】
[ Back to top ]