(57)【特許請求の範囲】
【請求項１】
コンピュータ実行方法であって、
第１のサーバ上の第１のアプリケーションから送信され、第２のサーバ上の第２のアプリケーションに指定されたデータパケットを受信することと、
前記第２のサーバに関連付けられた宛先アドレスを判断するために前記データパケットを解析することと、
前記宛先アドレスに基づいて、前記第１のサーバ上の第１の通信プロキシと前記第２のサーバ上の第２の通信プロキシとの間に位置し、前記第２のアプリケーションに対応するキュー内に、前記データパケットを配置することと、
前記第１の通信プロキシと前記第２の通信プロキシとの間の事前に確立されたデータ接続を経由して前記データパケットを前記第２の通信プロキシに伝送することと、
前記第１のアプリケーションが終了したことを判断することと、
前記第１のアプリケーションが終了したことを示すブロードキャストメッセージを前記第１の通信プロキシに接続された１つ以上の通信プロキシに送信することと
を含む、コンピュータ実行方法。
【請求項２】
前記データパケットは、ソースフィールド、宛先フィールドおよびデータパケット優先度を含み、前記キュー内に前記データパケットを配置することは、前記データパケット優先度に基づいて前記キュー内に前記データパケットを配置することを含む、請求項１のコンピュータ実行方法。
【請求項３】
前記データパケットは、前記第１のアプリケーションを示す２個組を含むソースフィールドと、前記第２のアプリケーションを示す別の２個組を含む宛先フィールドとを含む、請求項１のコンピュータ実行方法。
【請求項４】
前記データパケットは、ソースフィールドと宛先フィールドとを含み、前記ソースフィールドは、インターネットプロトコル（ＩＰ）アドレスと前記第１のアプリケーションに関連付けられた固有のアプリケーションＩＤとを含む２個組を含み、前記宛先フィールドは、別のＩＰアドレスと前記第２のアプリケーションに関連付けられた別の固有のアプリケーションＩＤとを含む別の２個組を含む、請求項１のコンピュータ実行方法。
【請求項５】
前記データパケットを受信することは、前記第１の通信プロキシと前記第１のアプリケーションとの間の事前に確立されたプロセス間通信接続を経由して前記データパケットを受信することを含む、請求項１のコンピュータ実行方法。
【請求項６】
前記事前に確立されたデータ接続が帯域幅要件を満たすことを判断することと、
先入れ先出し技術に基づいて前記キューから前記データパケットを取り出すことと、
を更に含む、請求項１のコンピュータ実行方法。
【請求項７】
前記キュー内のデータパケットの量が、第１の事前に設定された閾値を超えることを判断することと、
前記キュー内のデータパケットの量が第１の事前に設定された閾値を超えるという判断に応じて、前記データパケットの前記伝送を終了するために、第１の制御信号を前記第１のアプリケーションに送信することと、
を更に含む、請求項１のコンピュータ実行方法。
【請求項８】
前記キュー内の前記データパケットの前記量が、前記第１の事前に設定された閾値よりも少ない第２の事前に設定された閾値内にあることを判断することと、
前記キュー内の前記データパケットの前記量が前記第２の事前に設定された閾値内にあるという判断に応じて、前記データパケットの前記伝送を再開するために、第２の制御信号を前記第１のアプリケーションに送信することと、
を更に含む、請求項７のコンピュータ実行方法。
【請求項９】
前記第１の通信プロキシが、前記第１の通信プロキシと前記第２の通信プロキシとの間の事前に確立された制御接続を経由して、データパケットの伝送の終了を示す第１の制御信号を受信することを判断することと、
前記第１の通信プロキシが前記第１の制御信号を受信するという判断に応じて、前記キュー内の前記データパケットの前記伝送を終了することと、
を更に含む、請求項１のコンピュータ実行方法。
【請求項１０】
前記第１の通信プロキシが、前記第１の通信プロキシと前記第２の通信プロキシとの間の前記事前に確立された制御接続を経由して、前記データパケットの前記伝送の再開を示す第２の制御信号を受信することを判断することと、
前記第１の通信プロキシが第２の制御信号を受信するという判断に応じて、前記キュー内の前記データパケットの前記伝送を再開することと、
を更に含む、請求項９のコンピュータ実行方法。
【請求項１１】
コンピュータ実行方法であって、
第１のサーバ上の第１の通信プロキシによって、前記第１の通信プロキシと第２のサーバ上の第２の通信プロキシとの間の事前に確立されたデータ接続を経由して、前記第１のサーバ上の第１のアプリケーションに関連付けられた宛先アドレスを含むデータパケットを前記第２のサーバ上の第２のアプリケーションから受信することと、
前記第１の通信プロキシによって、前記宛先アドレスを判断することと、
前記第１の通信プロキシによって、前記宛先アドレスに基づいて前記第１の通信プロキシと前記第１のアプリケーションとの間のキュー内に前記データパケットを配置することと、
前記第１の通信プロキシによって、前記第１の通信プロキシと前記第１のアプリケーションとの間の事前に確立されたプロセス間通信接続を経由して、前記データパケットを前記第１のアプリケーションに伝送することと、
前記第１の通信プロキシによって、前記第２のアプリケーションが終了したことを判断することと、
前記第１の通信プロキシによって、前記第２のアプリケーションが終了したことを示すブロードキャストメッセージを、前記第１の通信プロキシに接続され、かつ前記第１のサーバ上にある前記第１のアプリケーションに送信することと、
を含む、コンピュータ実行方法。
【請求項１２】
前記事前に確立されたデータ接続が帯域幅要件を満たすことを判断することと、
先入れ先出し技術に基づいて前記キューから前記データパケットを取り出すことと、
を更に含む、請求項１１のコンピュータ実行方法。
【請求項１３】
前記第１の通信プロキシによって、前記キュー内のデータパケットの量が第１の事前に設定された閾値を超えることを判断することと、
前記キュー内のデータパケットの量が第１の事前に設定された閾値を超えるという判断に応じて、前記データパケットの前記伝送を終了するために、前記事前に確立されたデータ接続を経由して第１の制御信号を前記第２の通信プロキシに送信することと、
を更に含む、請求項１１のコンピュータ実行方法。
【請求項１４】
前記キュー内の前記データパケットの前記量が、前記第１の事前に設定された閾値よりも少ない第２の事前に設定された閾値内にあることを判断することと、
前記キュー内の前記データパケットの前記量が前記第２の事前に設定された閾値内にあるという判断に応じて、前記データパケットの前記伝送を再開するために、第２の制御信号を第２の通信プロキシに送信することと、を更に含む、請求項１３のコンピュータ実行方法。
【請求項１５】
前記第１の通信プロキシが、前記事前に確立されたプロセス間通信接続を経由して、データパケットの伝送の終了を示す第１の制御信号を受信することを判断することと、
前記第１の通信プロキシが前記第１の制御信号を受信するという判断に応じて、前記キュー内の前記データパケットの前記伝送を一時的に終了することと、
を更に含む、請求項１１のコンピュータ実行方法。
【請求項１６】
前記第１の通信プロキシが、前記事前に確立されたプロセス間通信接続を経由して、前記データパケットの前記伝送の再開を示す第２の制御信号を受信することを判断することと、
前記第１の通信プロキシが第２の制御信号を受信するという判断に応じて、前記キュー内の前記データパケットの前記伝送を一時的に再開することと、
を更に含む、請求項１５のコンピュータ実行方法。
【請求項１７】
システムであって、
メモリと、
１つ以上のプロセッサと、
前記メモリ内に記憶され、かつ前記１つ以上のプロセッサによって実行可能な、第１のサーバ上の第１のアプリケーションからデータパケットを受信するための受信ユニットであって、前記データパケットが、前記データパケットが指定される第２のアプリケーションを含む第２のサーバに関連付けられた宛先アドレスを含む、受信ユニットと、
前記メモリ内に記憶され、かつ前記１つ以上のプロセッサによって実行可能な、前記宛先アドレスを判断するためのアドレス解析ユニットと、
前記メモリ内に記憶され、かつ前記１つ以上のプロセッサによって実行可能な、伝送ユニットであって、
前記宛先アドレスに基づいて、前記第１のサーバ上の第１の通信プロキシと、前記第２のサーバ上にある第２の通信プロキシとの間に位置し、前記第２のアプリケーションに対応するキュー内に前記データパケットを配置し、かつ
前記第１の通信プロキシと前記第２の通信プロキシとの間の事前に確立されたデータ接続を経由して前記データパケットを前記第２の通信プロキシに伝送する、伝送ユニットと、を備え、
前記伝送ユニットは、前記第１のアプリケーションが終了したという判断に応答して、前記第１のアプリケーションが終了したことを示すブロードキャストメッセージを前記第１の通信プロキシに接続された１つ以上の通信プロキシに送信するようにさらに構成される、システム。
【請求項１８】
システムであって、
メモリと、
１つ以上のプロセッサと、
前記メモリ内に記憶され、かつ前記１つ以上のプロセッサによって実行可能な、第１のサーバ上の第１の通信プロキシと第２のサーバ上の第２の通信プロキシとの間の事前に確立されたデータ接続を経由して前記第２のサーバ上の第２のアプリケーションからデータパケットを受信するための受信ユニットであって、前記データパケットが前記第１のサーバ上の第１のアプリケーションに指定される、受信ユニットと、
前記メモリ内に記憶され、かつ前記１つ以上のプロセッサによって実行可能な、前記第１のアプリケーションに関連付けられた宛先アドレスを判断するように前記データパケットを解析するためのアドレス解析ユニットと、
前記メモリ内に記憶され、かつ前記１つ以上のプロセッサによって実行可能な、伝送ユニットであって、
前記宛先アドレスに基づいて、前記第１の通信プロキシと前記第１のサーバ上の前記第１のアプリケーションとの間のキュー内に前記データパケットを配置し、かつ
前記第１の通信プロキシと前記第１のアプリケーションとの間の事前に確立されたプロセス間通信接続を経由して前記データパケットを前記第１のアプリケーションに伝送する、伝送ユニットと、を備え、
前記伝送ユニットは、前記第２のアプリケーションが終了したという判断に応答して、前記第２のアプリケーションが終了したことを示すブロードキャストメッセージを、前記第１のサーバ上の前記第１のアプリケーションに送信するようにさらに構成される、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、ネットワーク通信技術に関するものである。より具体的には、本開示は、伝送制御プロトコル（ＴＣＰ）通信の方法とＴＣＰ通信のためのサーバに関するものである。
【背景技術】
【０００２】
伝送制御プロトコル（ＴＣＰ）を使用する二者間の通信の間、ＴＣＰ接続が、データを双方向的に伝送するためにこれらの二者（例えば、クライアントアプリケーションとサーバアプリケーション）間に確立される。ＴＣＰに従って、ＩＰアドレスおよびポートＩＤは、通信相手を識別するために使用され、ポートＩＤは、１から６５５３５までの符号なしの１６桁の整数である。
【０００３】
ＴＣＰ接続をサーバアプリケーションとクライアントアプリケーションとの間に確立するために、サーバアプリケーションはまずポートを開放し、そのポートで待ち受ける。クライアントアプリケーションもまた、ポートを開放し、そのポートを経由してサーバアプリケーションの待ち受けポートと接続する。したがって、ＴＣＰ接続を確立することは、サーバアプリケーションとクライアントアプリケーションとの間に少なくとも３回のハンドシェイクを必要とする。しかしながら、従来の技術に基づいて確立される大量のＴＣＰ接続に問題が生じる場合がある。結果として、過剰なシステムリソースが伝送の間に消費されることがある。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
この発明の概要は、発明を実施するための形態において以下に更に記載される概念の選択を簡易化された形式で紹介するために提供される。この発明の概要は、特許請求された対象の重要な特徴または不可欠な特徴を明らかにすることを意図するものではなく、また、特許請求された対象の範囲を限定するために使用されることを意図するものでもない。
【０００５】
本開示は、例えば伝送制御プロトコル（ＴＣＰ）接続を経由してデータパケットを伝送するための方法およびサーバを提供する。
【課題を解決するための手段】
【０００６】
いくつかの態様では、データパケットを伝送することは、データパケットを第１のサーバ上の第１のアプリケーションから受信することを含む。データパケットは、次いで、データパケットを受信するための第２のアプリケーションを含む第２のサーバに関連付けられた宛先アドレスを判断するために、第１のサーバ上の第１の通信プロキシによって解析される。アドレスの判断の後、データパケットは、第１の通信プロキシと第２のサーバ上の第２の通信プロキシとの間のキュー内に配置され、第２の通信プロキシに送信される。
【０００７】
いくつかの態様では、データパケットを伝送することは、データパケットを第２のサーバ上の第２のアプリケーションから受信することを含む。データパケットは、次いで、データパケットを受信し、かつ第１のサーバ上に位置する第１のアプリケーションに関連付けられた宛先アドレスを判断するために、第１のサーバ上の第１の通信によって解析される。アドレスの判断の後、データパケットは、第１の通信プロキシと第１のアプリケーションとの間のキュー内に配置され、第１のアプリケーションに送信される。いくつかの態様では、データパケットを伝送することは、データ伝送を制御するためのフロー制御機構を含む。
【図面の簡単な説明】
【０００８】
【図１】サーバ間の例示的なＴＣＰ接続を示す概略図である。
【図２】サーバ間の例示的なＴＣＰ接続を示す概略図である。
【図３】データパケットを第１のサーバ上の第１のアプリケーションから第２のサーバ上の第２の通信プロキシに伝送する例示的なプロセスを示すフローチャートである。
【図４】説明的なデータパケット形式の概略的なブロック図である。
【図５】データパケットを第１のサーバの第１の通信プロキシから第２のサーバの第２の通信プロキシに送信する例示的なプロセスを示す概略図である。
【図６】キューのいくつかのデータパケットを送信し、かつ制御信号を送信する例示的なプロセスを示す概略図である。
【図７】データパケットを第１のサーバ上で第１の通信プロキシから第１のアプリケーションに伝送する例示的なプロセスを示すフローチャートである。
【図８】データパケットを第１のサーバ上の第１の通信プロキシから第１のサーバ上の第１のアプリケーションに送信する例示的なプロセスを示す概略図である。
【図９】例示的なＴＣＰ通信サーバの詳細を示す概略的なブロック図である。
【図１０】ＴＣＰ通信サーバの例示的なプログラムユニットの詳細を示す概略的なブロック図である。
【発明を実施するための形態】
【０００９】
ＴＣＰの方法およびＴＣＰのためのサーバの発明を実施するための形態は、添付の図面を参照にして説明される。
【００１０】
図１は、サーバ間の例示的なＴＣＰ接続を示す概略図である。２つのサーバ上のアプリケーション（例えば、クライアントアプリケーションとサーバアプリケーション）間でＴＣＰ通信を行うために、ＴＣＰ接続は、通常、２つのサーバ上のアプリケーション間に確立される。図１に示されるように、サーバ１内のアプリケーションＡ〜Ｄのそれぞれは、サーバ２内のアプリケーションＥ〜Ｈ）のそれぞれとＴＣＰ接続を確立する。
【００１１】
アプリケーションＡ〜ＤがアプリケーションＥ〜Ｈと通信する限り、ＴＣＰ接続は、２つのサーバ間に確立される必要がある。２つのサーバがあり、各サーバが１００個のアプリケーションを実行することを仮定する。ＴＣＰ接続は２つのサーバの２つの個々のアプリケーション間に確立される必要があるので、２つのサーバ間で合計１０，０００個のＴＣＰ接続があることになる。オペレーティングシステムとプロトコルスタックの観点からすれば、これほど多くのＴＣＰ接続を維持することは、大量のシステムリソースを消費することになる。この状況を避けるために、提案された１つの解決法は、アプリケーションがＴＣＰ接続の使用を終了した後にＴＣＰ接続を直ちに終了させて、アプリケーションが接続を再度必要とする場合にＴＣＰ接続を再度確立することである。接続を再度確立するプロセスは、少なくとも３回のハンドシェイクを必要とし、したがって、アプリケーションの実行に遅延を生じさせることがある。
【００１２】
このことは、大規模のサーバクラスタに対してより大きな問題を生じさせる可能性さえある。クラスタが５０００個のサーバを有し、各サーバが、平均して、１００個のアプリケーションを実行することを仮定する。結果として、クラスタは合計で５００，０００個のＴＣＰ接続を確立するかもしれない。これほど多くのＴＣＰ接続を維持することは、大量のシステムリソースを消費することになる。更に、たとえこれらのＴＣＰ接続の全てが同時に維持されるわけではないとしても、これらのアプリケーションの実行は、これらのＴＣＰ接続の終了および／または開始のプロセスによって遅延されることになる。
【００１３】
上記のように、従来の技術は、異なるサーバ間で別のアプリケーションと通信するアプリケーションごとにＴＣＰ接続を確立し、これらのアプリケーションの実行に遅延を生じさせる場合がある。本開示は、ＴＣＰ通信を改善し、かつ上記の問題を避ける様々な例示的方法を記載する。
【００１４】
図２は、サーバ間の例示的なＴＣＰ接続を示す概略図である。図示されるように、第１の通信プロキシおよび第２の通信プロキシは、２つの通信相手（すなわち、第１のアプリケーションＡ〜Ｄおよび第２のアプリケーションＥ〜Ｈ）が位置する第１のサーバおよび第２のサーバにそれぞれインストールされる。第１の通信プロキシおよび第２の通信プロキシは、特定の機能を実行するソフトウェアモジュールである。
【００１５】
第１のサーバ上の第１のアプリケーションＡ〜Ｄは、プロセス間通信接続を経由して第１の通信プロキシと接続する。同様に、第２のサーバ上の第２のアプリケーションＥ〜Ｈは、プロセス間通信接続を経由して第２の通信プロキシと接続する。これらのプロセス間通信接続は、サーバのオペレーティングシステムによって提供されるいくつかのプロセス間通信方法のうちの１つを使用してもよい。限定ではない一例として、その通信方法は、ユニックスドメインソケット（Ｕｎｉｘ（登録商標）  Ｄｏｍａｉｎ  Ｓｏｃｋｅｔ）、ローカルＴＣＰ、共用メモリおよびメッセージキュー、ならびにパイプ（Ｐｉｐｅ）を含んでもよい。
【００１６】
第１のサーバ内の第１の通信プロキシおよび第２のサーバ内の第２の通信プロキシは、２つのアプリケーション間にＴＣＰ接続を確立する従来のＴＣＰ技術とは異なり事前に確立されたデータ接続を使用する。本開示によって提供されるデータ接続は、固定した、かつ非常に安定した接続である。その接続を通じて、第１のサーバ内の全てのアプリケーションは、第１の通信プロキシと第２の通信プロキシとの間に確立されたＴＣＰ接続を経由して第２のサーバ内のアプリケーションに接続してもよい。そしてまた、第２のサーバ内の全てのアプリケーションは、そのＴＣＰを経由して第１のサーバ内のアプリケーションに接続してもよい。図２に示されるように、第１の通信プロキシと第２の通信プロキシとの間のデータ接続は、第１のサーバ内の第１のアプリケーションと第２のサーバ内の第２のアプリケーションとの間にデータ通信チャネルを提供する。データ接続は、従来の技術に従って多数のＴＣＰ通信相手間に確立されることになるいくつかのＴＣＰ接続に実際に取って代わる。いくつかの実施形態では、確立された単一のデータ接続は、第１のサーバ内の第１のアプリケーションと第２のサーバ内の第２のアプリケーションとの間のデータ転送を実施してもよい。第１のアプリケーションと第２のアプリケーションとの間に直接的な接続がないので、実際の接続量は、従来の技術に従う接続量よりもはるかに少なく、したがって、システムリソースを大幅に節約することができる。
【００１７】
いくつかの実施形態では、大規模のクラスタ化アプリケーションのために、図２に示される第１のサーバおよび第２のサーバに類似した多くのサーバがある場合がある。サーバクラスタの各サーバ内の通信プロキシは、データ接続を経由してサーバクラスタの別のサーバ内の通信プロキシと個別に接続してもよい。
【００１８】
いくつかの実施形態では、第１のサーバ内のアプリケーション（以下、「第１のアプリケーション」）は、データパケットを第１のサーバ内の第１の通信プロキシに送信する。この第１の通信プロキシは、データパケットを第２のサーバ内の第２の通信プロキシに送信する。その後、第２の通信プロキシは、データパケットを第２のサーバ内の別のアプリケーション（以下、「第２のアプリケーション」）に送信する。
【００１９】
いくつかの実施形態では、第２のアプリケーションは、データパケットを第２のサーバ内の第２の通信プロキシに送信する。この第２の通信プロキシは、データパケットを第１のサーバ内の第１の通信プロキシに送信する。その後、第１の通信プロキシは、データパケットを第１のアプリケーションに送信する。
【００２０】
いくつかの実施形態では、第１のサーバ内の第１の通信プロキシと第２のサーバ内の第２の通信プロキシは、ＴＣＰ接続における反対端（ｏｐｐｏｓｉｔｅ  ｅｎｄ）であり、したがって、これらのネットワーク状況は対称的である。第１のアプリケーションは、データパケットを第１の通信プロキシに送信し、次いで、第１の通信プロキシは、データパケットを第２の通信プロキシに送信する。このプロセスは、第２のアプリケーションがデータパケットを第２の通信プロキシに送信し、次いで、第２の通信プロキシがデータパケットを第１の通信プロキシに送信するプロセスに類似する。同様に、第２の通信プロキシは、受信したデータパケットを第２のアプリケーションに送信する。このプロセスもまた、第１の通信プロキシが受信したデータパケットを第１のアプリケーションに送信するプロセスに類似する。
【００２１】
いくつかの実施形態では、第１の通信プロキシは、第１のアプリケーションから受信したデータパケットを第２の通信プロキシに伝送する。第１の通信プロキシは、第２のアプリケーションによって送信されたデータパケットを第２の通信プロキシから受信する。次いで、第１の通信プロキシは、そのデータパケットを第１のアプリケーションに送信する。双方向的なＴＣＰ通信を本開示に基づいて実施することができることが理解される。双方向的なＴＣＰ通信は、第１の通信プロキシから第２の通信プロキシにあるいは第２の通信プロキシから第１の通信プロキシに確立されてもよい。
【００２２】
図３は、第１のサーバ上の第１のアプリケーションから第２のサーバ内の第２の通信プロキシにデータパケットを伝送する例示的なプロセスを示すフローチャートである。
【００２３】
ブロック３０１では、第１のサーバの第１の通信プロキシは、第１の通信プロキシと第１のアプリケーションとの間の事前に確立されたプロセス間通信接続を経由して、第１のサーバ上の第１のアプリケーションによって送信されたデータパケットを受信する。ブロック３０２では、第１の通信プロキシは、データパケットを受信する第２のアプリケーションが位置する第２のサーバの宛先アドレスを判断するためにデータパケットを解析する。ブロック３０３では、第１の通信プロキシは、第１のサーバのキュー内にデータパケットを配置する。キューは、第２のサーバ上の第２のアプリケーションに対応する。ブロック３０４では、第１の通信プロキシは、キューからデータパケットを取り出し、次いで、第１の通信プロキシと第２の通信プロキシとの間の事前に確立されたデータ接続を経由してデータパケットを第２の通信プロキシに送信する。
【００２４】
図４は、説明的なデータパケット形式の概略図である。第１のサーバのアプリケーションは、データパケットを第１のサーバ内で送信するために第１のサーバのアプリケーションのプロセス間通信接続を使用する一方で、それらは、データ接続を経由してデータパケットを第２のサーバ上の第２の通信プロキシに送信する。また、第２の通信プロキシは、各データパケットに対応するプロセス間通信接続をそのデータパケットの宛先アドレスに基づいて区別し、したがって、データパケットを第２のサーバ上の対応する第２のアプリケーションに正確に伝送することができる。いくつかの実施形態では、サーバ内の様々なアプリケーションは、対応する固有のアプリケーションＩＤ（以下、「ＡｐｐＩＤ」）（例えば、１６ビットの整数）に基づいて区別されてもよい。例えば、第１のサーバ上および第２のサーバ上の各アプリケーションは、ＡｐｐＩＤを割り当てられる。いくつかの実施形態では、ＩＰアドレスとＡｐｐＩＤを組み合わせることを、アプリケーションを位置させるために使用することができる。すなわち、２個組（ｔｗｏ−ｔｕｐｌｅ）（すなわち、ＩＰ、ＡｐｐＩＤ）は、サーバ上のアプリケーションのアドレスを表わすことができる。
【００２５】
図４に図示されるように、いくつかの実施形態では、データパケットは、ＳＲＣフィールド（すなわち、ソースアドレス）、ＤＳＴフィールド（すなわち、宛先アドレス）、およびペイロードフィールドを含んでもよい。これらの実施形態では、ＳＲＣフィールドは、データパケットを送信する第１のアプリケーションの（ＩＰ、ＡｐｐＩＤ）を含むソースアドレスを表わす。ＤＳＴフィールドは、データパケットを受信する第２のアプリケーションの（ＩＰ、ＡｐｐＩＤ）を含む宛先アドレスを表わす。データパケットは、例えば、データパケット番号フィールドおよびデータパケットフラグフィールドを含んでもよい。データパケットフラグフィールドは、例えば、データパケット優先度およびデータパケットの種類（例えば、データニュース）を含んでもよい。したがって、第１の通信プロキシはデータパケット内の宛先アドレスを解析すると、この通信プロキシは、データパケットを受信する第２のアプリケーションの対応する第２の通信プロキシを判断することができる。第１の通信プロキシは、次いで、データパケットを第２の通信プロキシに送信する。第２の通信プロキシはデータパケットを一旦受信すると、第２の通信プロキシは、データパケット内に含まれる宛先アドレスに基づいて、対応する第２のアプリケーションにデータパケットを送信することができる。
【００２６】
図５は、第１のサーバの第１の通信プロキシから第２のサーバの第２の通信プロキシにデータパケットを送信する例示的なプロセス（例えば、図３のブロック３０３および３０４）を示す概略図である。図５に図示されるように、第１の通信プロキシは、第１のサーバの第１のアプリケーションによって送信されたデータパケットを一旦受信すると、第１の通信プロキシは、キューが第１の通信プロキシと第２の通信プロキシとの間に確立されているかどうかを判断する場合がある。キューは、データパケットを受信する第２のアプリケーションに対応しており、データパケットを第２の通信プロキシに送信するために使用される。いくつかの実施形態では、第１の通信プロキシは、キューが確立されていないことを判断する。次いで、キューは確立されて、データパケットがキュー内に配置される。限定ではない一例として、データパケットは、キュー内の配置のタイムスタンプ順またはデータパケットの優先度に基づいてキュー内に配置されてもよい。キューは、データパケットを受信する第２のアプリケーションに対応するので、第１の通信プロキシは、データパケット内に含まれる宛先アドレスを用いて第２のアプリケーションを判断し、データパケットが配置されるべきキューを判断してもよい。
【００２７】
いくつかの実施形態では、第１の通信プロキシは、データ接続が帯域幅要件内に入る場合、データパケットをキューから取り出してもよい。限定ではない一例として、データパケットは、先入れ先出し技術またはデータパケットの優先度に基づいて取り出されてもよい。取り出されたデータパケットは、第１の通信プロキシと第２の通信プロキシとの間のデータ接続を経由して第２の通信プロキシに伝送されてもよい。
【００２８】
いくつかの実施形態では、データパケットの一定の受信側（例えば、第２の通信プロキシおよび第２のアプリケーション）が、その受信側の受信するデータ速度を落とす一方で、他方側は他方側の受信するデータ速度を落とさないので、データ接続は、全体として、速度を落とされない。第１のサーバ内の第１のアプリケーションが大量のデータパケットを生成する場合、そのことは、キューが完全に埋められ、その結果、データパケットがオーバーフローするという状況を作るかもしれない。そのような状況が生じる場合、キュー内の後続のデータパケットを、正常に伝送することができない。同様の状況を避けるために、フロー制御機構が、本開示に提供される。
【００２９】
いくつかの実施形態では、フロー制御機構は、第１のサーバ内の第１の通信プロキシと第２のサーバ内の第２の通信プロキシとの間に確立された制御接続を含んでもよい。この制御接続は、固定し、かつ安定した接続である上記データ接続に類似する。この状況において、データ接続がデータ伝送を制御する一方で、制御接続はフロー制御信号を制御する。この制御接続は、従来のＴＣＰ技術に従って両者間に確立されるＴＣＰ接続とは異なる。本開示によって提供されるこのデータ接続は、フロー制御に関して２つのデータ接続と比較して少々効果が低い一方で、ＴＣＰ接続の数を更に減らす。
【００３０】
図５に図示されるように、データパケットを第２の通信プロキシに伝送するとき、第１の通信プロキシは、キュー内のデータパケットの量を監視する。いくつかの実施形態では、キュー内のデータのオーバーフローを避けるために、第１の通信プロキシが、キュー内のデータパケットの量が事前に設定された閾値よりも多いことを判断した後に、制御信号（すなわち、第１の制御信号）が、データパケットの伝送を停止するために第１のアプリケーションに送信される。
【００３１】
いくつかの実施形態では、第１のアプリケーションが第１の制御信号を受信した後に、第１のアプリケーションは、データパケットを第１の通信プロキシに伝送することを停止する。第１の通信プロキシは、キュー内にあるデータパケットを伝送し続けて、その後、キュー内のデータパケットの量は徐々に減少する。第１の制御信号を第１のアプリケーションに送信した後、第１の通信プロキシは、キュー内のデータパケットの量を監視する。第１の通信が、キュー内のデータパケットの量が事前に設定された閾値の範囲内にあることを判断した後に、第２の制御信号（すなわち、第２の制御信号）が、データパケットの伝送を再開するために第１のアプリケーションに送信される。
【００３２】
例えば、第１の通信プロキシが、キュー内のデータパケットがキューの長さ（すなわち、受信することができるデータパケットの合計数）の２／３以上であることを監視すると、第１の通信プロキシは、データパケットの伝送を停止する信号メッセージＸＯＦＦ（すなわち、第１の制御信号）を送信する。第１の通信プロキシが、キュー内のデータパケットの量がキューの長さの１／３以下であることを監視すると、第１の通信プロキシは、データパケットの伝送を再開する信号メッセージＸＯＮ（すなわち、第２の制御信号）を送信する。
【００３３】
いくつかの実施形態では、第１の通信プロキシがデータパケットを第２の通信プロキシに伝送すると、第１の通信プロキシは、第３の制御信号が、データパケットの伝送を停止するために第２の通信プロキシから、第１の通信プロキシと第２の通信プロキシとの間の事前に確立された制御接続を経由して受信されたかどうかを判断する。第３の制御信号を受信すると、第１の通信プロキシは、例えばキュー内の全てのデータパケットを、伝送することを一時的に停止する。第１の通信プロキシは、キュー内の全てのデータパケットを伝送することを一時的に停止した後に、第２の通信プロキシからの第４の制御信号が、データパケットの伝送を再開するかどうかの判断を、事前に確立された制御接続で受信することによって、継続する。第４の制御信号を受信すると、第１の通信プロキシは、例えばキュー内の全てのデータパケットを、伝送することを再開する。
【００３４】
限定ではない一例として、第１の、第２の、第３の、および第４の制御信号は、データを伝送する際に使用されるデータパケットの形式に類似のデータ形式または他の形式を使用してもよい。例えば、制御信号は、データパケットが制御信号であることを示すデータパケットの種類フィールドを含んでもよい。
【００３５】
いくつかの実施形態では、２つの接続が確立されるとき、制御信号キュー方法が、制御接続で制御信号を伝送するために使用されてもよい。制御信号キューは、制御信号がデータ伝送よりも高い伝送優先度を有することを確実にするように制御信号を伝送するためだけに使用される。第１の通信プロキシまたは第２の通信プロキシは、制御信号キュー内に制御信号を配置することができる。伝送基準（例えば、帯域幅要件）が満たされる場合、第１の通信プロキシまたは第２の通信プロキシは、制御キューが制御信号を含むかどうかを判断する。制御キューが制御信号を含む場合、制御キューは、伝送されるための優先権を与えられる。この制御信号キューは、制御信号がそれらの宛先に時間通りに届くことが可能であることを確実にする。
【００３６】
図６は、キューのいくつかのデータパケットを送信すること、および制御信号キューの制御信号を送信することの例示的なプロセスを示す概略図である。図６に図示されるように、キューおよび第２のキュー内の量は、受信側の第２のアプリケーション内の量に基づいて判断される。第２の通信プロキシが３つの第２のアプリケーション（すなわち、図６におけるＡｐｐ１、Ａｐｐ２およびＡｐｐ３）に接続することを仮定する。更に、第１の通信プロキシが２つの第１のアプリケーション（すなわち、クライアントＡｐｐ１およびクライアントＡｐｐ１）に接続することを仮定する。結果として、第１の通信プロキシは、クライアントＡｐｐ１およびクライアントＡｐｐ２によって送信されたデータパケットを受信する。第１の通信プロキシは、データパケットの宛先アドレスに基づいて、Ａｐｐ１、Ａｐｐ２およびＡｐｐ３にそれぞれ対応する３つの第１のキュー（すなわち、図６におけるＡｐｐ１＿Ｑ、Ａｐｐ２＿ＱおよびＡｐｐ３＿Ｑ）内にこれらのデータパケットを個別に配置する。次いで、第１の通信プロキシは、３つの第１のキュー内のデータパケットを第２の通信プロキシに伝送する。第２の通信プロキシがデータパケットを一旦受信すると、第２の通信プロキシは、Ａｐｐ１、Ａｐｐ２およびＡｐｐ３にそれぞれ対応する３つの第２のキュー（Ａｐｐ１＿Ｑ、Ａｐｐ２＿ＱおよびＡｐｐ３＿Ｑ）内にそれらのデータパケットを配置する。これらの３つの第２のアプリケーションは、それら自体のデータパケットを３つの第２のキューからそれぞれ取り出す。
【００３７】
いくつかの実施形態では、上記ブロック３０１から３０４までを実行する際に、第１の通信プロキシが、第１のサーバ内の第１のアプリケーションが判断されたことを検出する場合、第１の通信プロキシは、第１のアプリケーションが決定されたことを示すブロードキャストメッセージを第１の通信プロキシとの確立されたデータ接続を有する第２の通信プロキシの全てに送信してもよい。それに対応して、ブロードキャストメッセージを受信する第２の通信プロキシのそれぞれは、メッセージを第２のアプリケーションの全てに伝送する。したがって、第１の通信プロキシは、第１のアプリケーションのそれぞれの状態を記録する必要はない。いくつかの実施形態では、ブロードキャストメッセージのデータ量を減らすために、第１の通信は、ブロードキャストメッセージを定期的に（例えば、毎週）送信してもよい。それに対応して、第１のアプリケーションが判断されるとき、第１のアプリケーションの対応するキューによってデータ接続内に占められたスペースもまた、リソースの無駄使いを避けるように開放されることができる。
【００３８】
図７は、第１のサーバ内で第１の通信プロキシから第１のアプリケーションにデータパケットを伝送する例示的なプロセスを示すフローチャートである。ブロック７０１では、第１のサーバ内の第１の通信プロキシは、第２のサーバ内の第２のアプリケーションによって送信された第２の通信プロキシの伝送したデータパケットを、第１の通信プロキシと第２のサーバ内の第２の通信プロキシとの間の事前に確立されたデータ接続を経由して受信する。
【００３９】
ブロック７０２では、第１の通信プロキシは、データパケットの宛先アドレスを解析する。その宛先アドレスに基づいて、第１の通信プロキシは、データパケットを受信する第１のサーバ上の第１のアプリケーションを判断する。いくつかの実施形態では、データパケットは、図４に上記したように２個組（すなわち、ＩＰ、ＡｐｐＩＤ）を含んでもよい。例えば、第１の通信プロキシは、データパケットに含まれる第１のアプリケーションのＡｐｐＩＤに基づいて第１のアプリケーションのアドレスを判断してもよい。
【００４０】
ブロック７０３では、第１の通信プロキシは、受信したデータパケットを第１の通信プロキシと第１のアプリケーションとの間の第２のキュー内に配置する。ブロック７０４では、第１の通信プロキシは、第１の通信プロキシと第１のアプリケーションとの間の事前に確立されたプロセス間通信接続を経由してデータパケットを第１のアプリケーションに送信する。いくつかの実施形態では、第１の通信プロキシは、第１のアプリケーションに送信されたデータパケットを第１の通信プロキシと第１のアプリケーションとの間の事前に確立されたプロセス間通信接続を経由して伝送してもよい。
【００４１】
図８は、データパケットを第１のサーバ上の第１の通信プロキシから第２のサーバ上の第１のアプリケーションに送信する例示的なプロセス（例えば、図７のブロック７０３および７０４）を示す概略図である。図８に図示されるように、第１の通信プロキシがデータパケットを一旦受信すると、第１の通信プロキシは、プロセス間通信接続が、データパケットを受信する第１のアプリケーションと第１の通信プロキシとの間に確立されたかどうかを判断してもよい。いくつかの実施形態では、第１の通信プロキシは接続が確立したことを判断する。次いで、第１の通信プロキシは、第１の通信プロキシと第１のアプリケーションとの間の第２のキュー内にデータパケットを配置してもよい。いくつかの実施形態では、第１の通信は、接続が確立していないことを判断する。次いで、第２のキューが、データパケットを受信する第１のアプリケーションと第１の通信プロキシとの間にまず確立される。第１の通信プロキシは、その後、第２のキュー内にデータパケットを配置する。限定ではない一例として、データパケットは、キュー内の配置のタイムスタンプ順またはデータパケットの優先度に基づいてキュー内に配置されてもよい。いくつかの実施形態では、第２のキューは、データパケットを受信する実際の第１のアプリケーションのみに対応してもよい。
【００４２】
いくつかの実施形態では、第１の通信プロキシは、データ接続の帯域幅要件内に入る場合、データパケットをキューから取り出してもよい。限定ではない一例として、データパケットは、先入れ先出し技術またはデータパケットの優先度に基づいて取り出されてもよい。取り出されたデータパケットは、第１の通信プロキシと第１のアプリケーションとの間のプロセス間通信接続を経由して第１のアプリケーションに伝送されてもよい。
【００４３】
図８に図示されるように、データパケットを第１のアプリケーションに伝送する際（例えば、図７のブロック７０３および７０４）、第１の通信プロキシは、第２のキュー内のデータパケットの量を監視する。いくつかの実施形態では、第１の通信プロキシが、第２のキュー内のデータパケットの量が事前に設定された閾値よりも多いことを判断した後に、フロー信号（すなわち、図８の第１の制御信号）が、データパケットの伝送を停止するために第２の通信プロキシに送信される。
【００４４】
いくつかの実施形態では、第２の通信プロキシが第１の制御信号を受信した後に、第２の通信プロキシは、データパケットを第１の通信プロキシに伝送することを停止する。第１の通信プロキシは、第１のキュー内にあるデータパケットを伝送し続けて、その後、第２のキュー内のデータパケットの量は徐々に減少する。第１の制御信号を第２の通信プロキシに送信した後、第１の通信プロキシは、第２のキュー内のデータパケットの量を監視する。第１の通信が、第２のキュー内のデータパケットの量が事前に設定された閾値内にあることを判断した後に、第２の制御信号（すなわち、図８の第２の制御信号）は、データパケットの伝送を再開するために第２の通信プロキシに送信される。
【００４５】
いくつかの実施形態では、第１のサーバ内の第１のアプリケーションは、データ受信速度を落とすために、対応するフロー制御信号を第１の通信プロキシに送信してもよい。第２のキュー内のデータパケットの量を先を見越して監視することに加えて、第１の通信プロキシは、フロー制御信号が、第１の通信プロキシと第１のアプリケーションとの間の事前に確立されたプロセス間通信接続を経由して第１のアプリケーションによって送信されたかどうかを判断してもよい。第１の通信プロキシが、データパケットの伝送を停止することを示すフロー制御を一旦判断すると、第１の通信プロキシは、例えば第２のキュー内の全てのデータパケットを、伝送することを一時的に停止する。
【００４６】
いくつかの実施形態では、第１の通信プロキシが第２のキュー内のデータパケットの伝送を停止した後に、第１の通信プロキシは、第１の通信プロキシと第１のアプリケーションとの間の事前に確立されたプロセス間通信接続を経由して、データパケットを伝送することを再開するフロー制御信号を受信する。フロー制御信号を受信すると、第１の通信プロキシは、例えば第２のキュー内の全てのデータパケットを、伝送することを再開する。
【００４７】
いくつかの実施形態では、ブロック７０１〜７０４を実行するプロセスにおいて、第１の通信プロキシは、第２の通信プロキシが位置する第２のサーバからブロードキャストメッセージを受信してもよい。ブロードキャストメッセージは、第２のサーバ内の第２のアプリケーションが終了したことを示す。第１の通信プロキシは、受信したブロードキャストメッセージを第１のサーバ内のアプリケーションに送信してもよい。したがって、第２のアプリケーションが判断された場合、第２のアプリケーションの対応する第２のキューによってデータ接続内に占められたスペースもまた、リソースの無駄使いを避けるように開放することができる。
【００４８】
図９および図１０は、ＴＣＰ通信のための例示的なサーバを示すブロック図である。説明のために、サーバは、図３、図５および図６〜図８に示されたプロセス、図４におけるデータパケット形式、ならびに図２におけるＴＣＰ接続を参照して記載される。しかしながら、サーバは、異なるデータパケット形式および接続を含む異なるプロセスを実行してもよい。
【００４９】
いくつかの実施形態では、サーバは、組み込み型の双方向通信機能を有する。結果として、データパケットは、第１のサーバ内の第１のアプリケーションによって第２の通信プロキシに伝送されてもよいし、データパケットはまた、第２の通信プロキシによって第１のサーバ内の第１のアプリケーションにも伝送されてもよい。また説明のために、以下の段落では、第１のアプリケーションから第２の通信プロキシにデータパケットを伝送する機能モジュール、および第２の通信から第１のアプリケーションにデータパケットを伝送する機能モジュールを有するサーバをまず記載する。
【００５０】
図９は、例示的なＴＣＰ通信サーバ９００の詳細を示す概略的なブロック図である。通信サーバ９００は、任意の適切なシステムとして構成されてもよい。１つの例示的な構成において、通信サーバ９００は、１つ以上のプロセッサ９０１、ネットワークインタフェース９０２、入出力インタフェース９０４、およびメモリ９０３を含む。
【００５１】
メモリ９０３は、ランダムアクセスメモリ（ＲＡＭ）などの揮発性メモリおよび／または読み出し専用メモリ（ＲＯＭ）もしくはフラッシュＲＡＭなどの不揮発性メモリの形式のコンピュータ可読媒体を含んでもよい。メモリ９０３は、コンピュータ可読媒体の一例である。
【００５２】
コンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、もしくは他のデータなどの情報の記憶のために任意の方法または技術で実装された、揮発性および不揮発性の、取り外し可能および取り外し不可能な媒体を含む。コンピュータ記憶媒体の例としては、相変化メモリ（ＰＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、他の種類のランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、電気的消去可能でプログラム可能な読み出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリもしくは他のメモリ技術、コンパクトディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学式ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、またはコンピューティングデバイスによるアクセスのための情報を記憶するために使用することができる任意の他の非伝送媒体が挙げられるが、これらに限定されない。本明細書中で定義されるように、コンピュータ可読媒体は、変調されたデータ信号および搬送波などの一時的な媒体を含まない。
【００５３】
メモリ９０３は、プログラムユニット９０５およびプログラムデータ９１１を含んでもよい。いくつかの実施形態では、プログラムユニット９０５は、受信ユニット９０６、アドレス解析ユニット９０７、伝送ユニット９０８、監視ユニット９０９および評価ユニット９１０を含んでもよい。
【００５４】
いくつかの実施形態では、受信ユニット９０６は、データパケットを第１のサーバ内の第１のアプリケーションから受信する。例えば、受信ユニット９０６は、第１の通信プロキシと第１のアプリケーションとの間の事前に確立されたプロセス間通信接続を経由して第１のアプリケーションによって伝送されたデータパケットを受信する。
【００５５】
アドレス解析ユニット９０７は、データパケット内の宛先アドレスを解析し、データパケットを受信する第２のアプリケーションが位置する第２のサーバのアドレスを判断してもよい。
【００５６】
伝送ユニット９０８は、第１の通信プロキシと第２の通信プロキシとの間の対応するキュー内にデータパケットを配置し、第１の通信プロキシと第２の通信プロキシとの間の事前に確立されたデータ接続を経由してデータパケットを第２の通信プロキシに伝送してもよい。例えば、データ接続が帯域幅要件内に入る場合、データパケットは、先入れ先出し技術を用いてキューから取り出されてもよい。次いで、データパケットはデータ接続を経由して第２の通信プロキシに伝送される。
【００５７】
いくつかの実施形態では、伝送ユニット９０８がデータパケットを伝送するとき、監視ユニット９０４はキュー内のデータパケットの量を監視してもよい。その量が、事前に規定された第１の閾値以上の場合、監視ユニット９０９は、データパケットの伝送を停止するために第１の制御信号を第１のアプリケーションに送信する。監視ユニット９０９が、データパケットの量が事前に規定された第２の閾値内にあることを判断すると、データパケットを伝送することを再開するために第２の制御信号を第１のアプリケーションに送信する。
【００５８】
いくつかの実施形態では、評価ユニット９１０は、第１の通信プロキシと第２の通信プロキシとの間の事前に確立された制御接続を経由してデータパケットを伝送することを停止するために、第３の制御信号が第２の通信プロキシから送信されたかどうかを判断してもよい。評価ユニット９１０が、そのような第３の制御信号が出ることを判断する場合、例えばデータパケットの全てをキューから伝送することを一時的に停止する。データパケットの伝送を再開することを示す第４の制御信号を第１の通信プロキシと第２の通信プロキシとの間の制御接続から受信すると、評価ユニット９１０は、例えばデータパケットの全てを、伝送することを再開する。
【００５９】
いくつかの実施形態では、第１のアプリケーションが終了したことを判断すると、伝送ユニット９０８は、第１の通信プロキシとの確立されたデータ接続を有する第２の通信プロキシを示すブロードキャストメッセージを送信してもよい。
【００６０】
図１０は、ＴＣＰ通信サーバの例示的なプログラムユニット１０００の詳細を示す概略的なブロック図である。プログラムユニット１０００は、受信ユニット１００１、アドレス解析ユニット１００２、伝送ユニット１００３、監視ユニット１００４および評価ユニット１００５を含んでもよい。
【００６１】
受信ユニット１００１は、第２のサーバ内の第２のアプリケーションからの、第２の通信プロキシの伝送したデータパケットを第１の通信プロキシと第２の通信プロキシとの間の事前に確立されたデータ接続を経由して受信する。
【００６２】
アドレス解析ユニット１００２は、受信ユニット９０１から受信されたデータパケット内の宛先アドレスを解析し、第１のアプリケーションのそのアドレスを判断してもよい。
【００６３】
伝送ユニット１００３は、受信されたデータパケットを第１の通信プロキシと第１のアプリケーションとの間の第２のキュー内に配置し、第１の通信プロキシと第１のアプリケーションとの間の事前に確立されたプロセス間通信接続を経由してデータパケットを第１のアプリケーションに送信してもよい。
【００６４】
いくつかの実施形態では、伝送ユニット１００３は、第１の通信プロキシと第１のアプリケーションとの間のプロセス間通信接続が帯域幅要件を満たす場合、先入れ先出し技術を用いてデータパケットを第２のキューから取り出してもよい。伝送ユニット１００３は、第１の通信プロキシと第１のアプリケーションとの間のプロセス間通信接続を用いてデータパケットを第１のアプリケーションに送信してもよい。
【００６５】
いくつかの実施形態では、伝送ユニット１００３が、第１の通信プロキシと第１のアプリケーションとの間のプロセス間通信接続を経由してデータパケットを第１のアプリケーションに伝送する場合、監視ユニット１００４は、第２の値（ｖａｌｕｅ）内のデータパケットの量を監視する。データパケットの量が第１の規定された閾値以上の場合、監視ユニット１００４は、第１の通信プロキシと第２の通信プロキシとの間の事前に確立された制御接続を経由してデータパケットを伝送することを停止するために、第１の制御信号を第２の通信プロキシに送信する。データパケットの量が第２の事前に規定された閾値内にある場合、監視ユニット１００４は、第１の通信プロキシと第２の通信プロキシとの間の事前に確立された制御接続を経由してデータパケットを伝送することを再開するために、第２の制御信号を第２の通信プロキシに送信する。
【００６６】
いくつかの実施形態では、伝送ユニット１００３が、第１の通信プロキシと第１のアプリケーションとの間の事前に確立されたプロセス間通信接続を経由してデータパケットを第１のアプリケーションに送信する場合、評価ユニット１００５は、事前に確立されたプロセス間通信接続を経由するデータパケットの伝送を停止することを示す第３の制御信号を判断する。評価ユニット１００５が、第３の制御信号が受信されたことを判断する場合、伝送ユニット１００３は、例えば第２のキューからのデータパケットの全てを、伝送することを一時的に停止する。
【００６７】
いくつかの実施形態では、評価ユニット１００５は、事前に確立されたプロセス間通信プロセスを経由する全てのデータパケットの伝送の再開を示す第４の制御信号を判断する。第８の制御信号が受信された後、伝送ユニット１０３は、例えば第２のキュー内の全てのデータパケットを、伝送することを再開する。
【００６８】
いくつかの実施形態では、受信ユニット１００１は、第２のアプリケーションが終了したというブロードキャストメッセージを第２のサーバから受信してもよい。受信ユニット１００１によって、ブロードキャストメッセージを受信すると、伝送ユニット１００３は、受信されたブロードキャストメッセージをサーバ内の第１のアプリケーション（例えば、図２内のＡ〜Ｄ）に送信してもよい。
【００６９】
説明のために、図９および図１０において記載されたブロックの任意の番号は、上記プロセスを実施するために任意の順で、および／または並行して組み合わされることができる。例えば、機能モジュールは、９０６および１００１を含む受信ユニット、９０７および１００２を含むアドレス解析ユニット、９０８および１００３を含む伝送ユニット、９０９および１００４を含む監視ユニットならびに９１０および１００５を含む評価ユニットを含むことができる。
【００７０】
本開示は、第１のサーバ内の全てのアプリケーションおよび第２のサーバ内の全てのアプリケーションが、第１の通信プロキシと第２の通信プロキシとの間のデータ接続を経由してデータを交換することが可能な、伝送制御プロトコルおよびサーバを提供する。
【００７１】
本開示はまた、第１の通信プロキシと第２の通信との間の確立されたデータ接続を経由する、第１のサーバ内の第１のアプリケーションと第２のサーバ内の第２のアプリケーションとの間のデータ通信チャネルも提供する。多くのＴＣＰ接続がＴＣＰ通信相手間に確立されることが必要である従来の技術と比較して、本開示によって提供されたＴＣＰ通信プロトコルおよびサーバは、第１のアプリケーションと第２のアプリケーションとの間の接続の実際の数を大幅に減らして、ＴＣＰ接続を維持するシステムリソースを効果的に節約する。更に、データ接続が安定しているので、従来の技術の下で生じる２つのアプリケーション間の頻繁な接続および切断によってもたらされる遅延を阻止する。したがって、本開示によって提供されたＴＣＰ通信プロトコルおよびサーバは、通信効率も高める。
【００７２】
更に、本開示によって提供されたＴＣＰ通信プロトコルおよびサーバは、第１の通信プロキシと第２の通信プロキシとの間の制御接続を同時に確立することを可能にする。制御接続において、フロー制御信号は、データ伝送フローが許容範囲を超えないこと、および、データパケットの伝送が第１のアプリケーションと第２のアプリケーションとの間で信頼性の高いことを確実にするために伝送される。
【００７３】
当業者は、本開示に提供された実施形態に変更および改変を行うことが可能であろう。当業者が理解するであろういかなる変更および改変も、本開示の範囲内にある。
【図１】
0005908915.tif 000002
【図２】
0005908915.tif 000003
【図３】
0005908915.tif 000004
【図４】
0005908915.tif 000005
【図５】
0005908915.tif 000006
【図６】
0005908915.tif 000007
【図７】
0005908915.tif 000008
【図８】
0005908915.tif 000009
【図９】
0005908915.tif 000010
【図１０】
0005908915.tif 000011