JP2012257288A - セッション接続の持続 - Google Patents

Abstract

【課題】セッション接続を持続するための技術を提供する。
【解決手段】タイム・アウト条件のため、メッセージを送信しないことが、セッション接続が閉じる結果を招くことになる場合に、ハートビート・メッセージを送信する。ハートビート・メッセージは、データ通信スタックのより高いレベルのプロトコルによっては無視される、有効なトランスポート層メッセージであり、そのペイロード内にキャリッジ・リターンおよび改行（「ＣＲＬＦ」）だけを収容するＴＣＰメッセージを送信することができる。ＴＣＰ層は、ＣＲＬＦだけを含むメッセージを有効なＴＣＰメッセージであると見なすので、プロキシ・サーバなどの中間のコンピューティング装置は、ハートビート・メッセージを「キープ・アライブ」メッセージとして解釈しないことになり、したがってセッション接続を持続することが可能になる。
【選択図】図１０

Description

記載の技術は、一般には、データ・ネットワーク通信に関し、より詳細には、セッション接続の持続（sustaining）に関する。

コンピューティング装置のユーザは時々、そのコンピューティング装置を使用して、他のユーザと通信する。一例として、ユーザは、ＭＩＣＲＯＳＯＦＴ ＭＥＳＳＥＮＧＥＲ（「ＭＥＳＳＥＮＧＥＲ」）インスタント・メッセージング製品を使用するなどして、タイプされたメッセージを送信し、または受信することによって、コンピューティング装置を使用する別のユーザと通信することができる。別の例では、ユーザは、ボイス・オーバ・インターネット・プロトコル（「ＶｏＩＰ」：Voice over Internet Protocol）アプリケーションを使用するなどして、マイクに向かって話し掛け、またスピーカまたはハンドセットで他のユーザの話を聞くことによって、別のユーザと通信することができる。こうしたユーザは、パーソナル・コンピュータ、携帯情報端末、携帯電話、ＶｏＩＰ対応電話など、様々なコンピューティング装置を使用することができる。

ユーザへのこうしたタイプの通信サービスを提供するアプリケーションは、プレゼンス（presence）情報を提供することも必要とすることがある。プレゼンス情報は、ユーザがコンピューティング装置を使用して通信する能力または意思を伝える。プレゼンス情報は、コンピューティング装置によって自動的に検出され、またはユーザによって能動的に選択することができる。コンピューティング装置は、ユーザの「状況（status）」などのプレゼンス情報を自動的に観察し、通信することができる。一例として、ユーザがどのコンピューティング装置にもログオンしていない、またはプレゼンス情報を観察し伝えるアプリケーションを使用（またはそれにログオン）していない場合、ユーザの状況は、「オフライン（off-line）」として自動的に指し示すことができる。ユーザがＭＥＳＳＥＮＧＥＲなど、プレゼンス情報を観察し伝えるアプリケーションを開始し、またはそれにログオンするときに、ユーザ状況は、「オンライン（on-line）」として自動的に指し示すことができる。ユーザがある時間の間、コンピューティング装置上で動作を行わない場合、アプリケーションは、ユーザが「不在」であることを自動的に指し示すことができる。ユーザは、その状態を能動的に選択することもできる。たとえば、ユーザは、「昼食のため外出中である（out for lunch）」または「多忙である（busy）」ことを指し示すことができ、これらは、他のユーザからのメッセージに直ぐに応答することができないことの指標（indication）であるとすることができる。

ユーザの状態を決定したいと望むアプリケーションである「ウォッチャー（watcher）」が、自動的にプレゼンス情報を受信するために登録サーバに問い合わせし、またはそれに加入することによって有意義なプレゼンス情報を決定することができるように、複数のコンピューティング装置が、登録サーバ・コンピューティング装置にプレゼンス情報を登録することができる。一例として、ＭＥＳＳＥＮＧＥＲは、ユーザがコンピューティング装置上である時間の間操作を行っていないので、したがってユーザのプレゼンス情報は「不在（away）」である可能性があることを登録サーバに指し示すことができる。ＶｏＩＰ対応電話は、ユーザが電話を掛けたので、したがってユーザのプレゼンス情報は「電話中（on the telephone）」である可能性があることを登録サーバに指し示すことができる。ウォッチャーは、登録サーバからこのプレゼンス情報を受信するときに、ユーザ状況は「電話中であり、コンピューティング装置上のメッセージに応答することができない」と決定することができる。しかし、ユーザがコンピューティング装置上で動作を実施し始める場合、ウォッチャーは、ユーザ状況は「電話中であるが、コンピューティング装置上のメッセージに応答することができる」と決定することができる。ユーザが、ユーザ状況が「不在（away）」であり、またＶｏＩＰ対応電話を使用していることをコンピューティング装置上に能動的に指し示す場合、ウォッチャーは、ユーザ状況は「ローミング中（roaming）」であると決定することができる。

通信アプリケーションは時々、コンピューティング装置間のセッションを確立し管理することが必要である。セッションは、ある時間にわたって発生する、コンピューティング装置間の１組の対話である。一例として、ＭＥＳＳＥＮＧＥＲやＶｏＩＰなどのリアルタイム通信アプリケーションは、ユーザに代わって通信装置間のセッションを確立する。こうしたアプリケーションは、「セッション開始プロトコル」（「ＳＩＰ」：Session Initiation Protocol）など、セッションを確立するための様々な機構を使用することが可能である。ＳＩＰは、コンピューティング装置が、互いを発見し、コンピューティング装置間でセッションを確立し、変更し、終了するために使用することができるアプリケーション層の制御プロトコルである。

アプリケーションは、情報を送信しまたは受信するために、ＳＩＰを別のプロトコルと共に使用することができる。ＳＩＰを他のプロトコルと共に使用することによって、アプリケーションは、セッションを作成し管理し、またセッション中に情報を交換することができる。情報を交換するためにＳＩＰと共に用いられるプロトコルは、情報をメッセージにセグメント化することができる。一例として、ＶｏＩＰアプリケーションは、長い話をより短いメッセージにセグメント化することができる。セッション中のメッセージ交換は、「ダイアログ（dialog）」と称される。ＳＩＰは、ダイアログのメッセージを移送するために、さらに下のレベルの通信層、たとえば伝送制御プロトコル／インターネット・プロトコル（「ＴＣＰ／ＩＰ」：Transmission Control Protocol/Internet Protocol）を使用することができる。このＴＣＰ／ＩＰは、一般的に使用されるトランスポートおよびネットワーク層のプロトコルである。

伝送制御プロトコル（「ＴＣＰ」）は、コネクション型（connection-oriented）の信頼できる配信のトランスポート層プロトコルである。ＴＣＰは一般に、トランスポート層と記載され、これはアプリケーション層（ＳＩＰを使用するアプリケーションなど）とネットワーク層の間のインターフェースを提供する。アプリケーション層は、一般に、データのストリーム（複数バイトのデータなど）を送信しまたは受信する際に、ＴＣＰ層と通信する。ＴＣＰは、このデータストリームを、インターネットプロトコル（「ＩＰ」）などの、ネットワーク層で使用されるプロトコルによって運ばれることが可能なセグメントに編成する。こうしたデータ・セグメントは一般に、「パケット」、「フレーム」または「メッセージ」と称される。それぞれのメッセージは一般に、ヘッダおよびペイロードを含む。ヘッダは、メッセージをルーティングし、解釈するのに必要なデータを含む。ペイロードは、送信されまたは受信される実際のデータを含む。他の層と共に、アプリケーション層、トランスポート層およびネットワーク層はまとめて、データ通信スタックと称される。

ある接続内のメッセージは、中間のコンピューティング装置を通過する可能性がある。送信側コンピューティング装置のデータ通信スタックのトランスポートまたはネットワーク層が、受信側コンピューティング装置内のデータ通信スタックの対応する層と接続を確立するときに、コンピューティング装置によって交換されるメッセージは、複数の中間コンピューティング装置を通過する可能性がある。たとえば、メッセージは、プロキシ・サーバ、ネットワーク・アドレス・トランスレータ、またはゲートウェイを通過する可能性がある。こうした中間コンピューティング装置は、メッセージを受信し、処理し、転送する。一例として、プロキシ・サーバは、イントラネットに接続されたコンピューティング装置と、インターネットに接続されたコンピューティング装置の間の仲介役であることが可能である。このプロキシ・サーバは、たとえば、イントラネットの外部からの接続要求を無視するなどによって、イントラネットをより安全なものにしようと試み得る。

中間コンピューティング装置は、ネットワーク・リソースを効率的に使用するために、２つのコンピューティング装置間のアイドル状態の接続を終了させることがある。一例として、イントラネットに接続されたユーザ・コンピューティング装置（「コンピューティング装置Ａ」）上で実行されるＭＥＳＳＥＮＧＥＲまたはＶｏＩＰアプリケーションは、インターネットに接続された別のコンピューティング装置（「コンピューティング装置Ｂ」）上で実行されるアプリケーションとＳＩＰベースのセッションを確立することができる。このセッションは、コンピューティング装置ＡとＢの間のＴＣＰ／ＩＰ接続を使用することができ、コンピューティング装置によって交換されるメッセージは、プロキシ・サーバを通過することになる。ある時間の間、接続内でメッセージが交換されない場合、プロキシ・サーバは、ネットワーク・リソースを保存するために、それとコンピューティング装置Ｂの間の接続を閉じることができる。しかし、コンピューティング装置Ａは、プロキシ・サーバとのその接続は開いているので、その接続が閉じていることを認識しないことがある。その結果、コンピューティング装置Ｂ上で実行されるアプリケーションは、コンピューティング装置Ａのアプリケーション（またはユーザ）がもはやオンライン状態ではなく、または接続を使用していないと、誤って決め込む可能性がある。さらに、プロキシ・サーバが接続されるイントラネットをより安全なものにするために、プロキシ・サーバは、インターネットに接続されたコンピューティング装置など、イントラネットに接続されていない装置からの接続要求を無視することができる。したがって、インターネットに接続されたコンピューティング装置Ｂ上で実行するアプリケーションは、その状況を求めて、またはセッションの再確立を要求するために、コンピューティング装置Ａ上で実行されるアプリケーションに問い合わせることが不可能になる可能性がある。

中間のコンピューティング装置は、コンピューティング装置が「キープ・アライブ」機構を使用する場合であっても、接続を閉じる可能性がある。コンピューティング装置によっては、キープ・アライブ機構を使用して、メッセージが無いにも拘らず、接続を存続状態に保つ。この機構は、送信側が接続を閉じていないことを指し示すための「キープ・アライブ」メッセージを送信することを伴う。しかし、効率的な中間コンピューティング装置は、キープ・アライブ・メッセージを認識することができ、送信側コンピューティング装置と中間コンピューティング装置の間の接続を存続状態に保ちながら、キープ・アライブ・メッセージ内に示された受信側（インターネットに接続されたコンピューティング装置など）との接続を終了させる可能性がある。

接続は、アプリケーション層の有効なメッセージを送信することによって持続することができる。一例として、トランスポート層のＴＣＰを使用するＳＩＰアプリケーションは、ＲＥＧＩＳＴＥＲメッセージなどの有効なＳＩＰメッセージを定期的に送信することができる。ＲＥＧＩＳＴＥＲメッセージを使用して、ＳＩＰサーバが、メッセージ送信側のユニフォーム・リソース識別子（「ＵＲＩ」：Uniform Resource Identifier）を、送信側によって使用されるコンピューティング装置に関連付けることを可能にすることができる。有効なＳＩＰメッセージが送信したりまたは受信したりすることができない場合、ＳＩＰアプリケーションは、そのＴＣＰ接続が使用不可能であることを検出することができる。

ＳＩＰは、インターネット提案規格である。その仕様、「ＲＦＣ３２６１」は、非特許文献１で入手可能である。イベント通知に関するＳＩＰ拡張に関する仕様、「ＲＦＣ３２６５」は、非特許文献２で入手可能である。インスタントメッセージング・システム内のプレゼンス情報に関する仕様、「ＲＦＣ２７７８」は、非特許文献３で入手可能である。ＳＩＰ内のプレゼンス情報に関する提案仕様のドラフトは、非特許文献４で入手可能である。その４つのすべての仕様全体を本明細書中で参考として援用する。

http://www.ietf.org/rfc/rfc3261.txt http://www.ietf.org/rfc/rfc3265.txt http://www.ietf.org/rfc/rfc2778.txt ttp://www.ietf.org/internet-drafts/draft-ietf-simple-presence-l0.txt

ＲＥＧＩＳＴＥＲの送信、または実際に有効なデータを含む任意の有効なＳＩＰメッセージを送信することに関する問題は、複数のクライアントおよびサーバが接続を持続するために送信することを必要とする場合に、送信することは、計算処理上集中的（computationally intensive）になる可能性があることである。ＲＥＧＩＳＴＥＲメッセージの場合、こうしたメッセージを受信するサーバは、送信側のコンピューティング装置のＵＲＩおよびＩＤを決定するために、メッセージの解析を必要とすることがあり、またおそらくは別のサーバ上にあるデータベース内にデータを格納することをさらに必要とする可能性がある。

したがって、ＴＣＰキープ・アライブに依存したり、またはメッセージに集中的な計算処理を要しないセッション接続を持続することに対する有効な手法は、非常に有用である。

セッション接続を持続するための技術が、ある実施形態で、提供される。この技術は、タイム・アウト条件のため、メッセージを送信しないことがセッション接続を閉じる原因になる可能性がある場合に、ハートビート・メッセージを送信する。ハートビート・メッセージは、データ通信スタックのより高いレベルのプロトコルによって無視されることになる有効なトランスポート層メッセージである。一例として、この技術は、ペイロード内にキャリッジ・リターンおよび改行（「ＣＲＬＦ」：carriage return and line feed）だけを含むＴＣＰメッセージを送信することができる。ＴＣＰ層は、ＣＲＬＦだけを含むメッセージを有効なＴＣＰメッセージであると見なすので、プロキシ・サーバなどの中間コンピューティング装置は、ハートビート・メッセージを「キープ・アライブ」メッセージとして解釈しないことができ、セッション接続を持続することができる。

セッション接続を持続するためのシステムの一実施形態を示すブロック図である。 図１のネットワークの一実施形態を示すブロック図である。 コンピューティング装置によって使用されるデータ通信スタックの一実施形態を示すブロック図である。 ｓｅｎｄ＿ｍｅｓｓａｇｅルーチンの一実施形態を示す流れ図である。 ｓｕｓｔａｉｎ＿ｃｏｎｎｅｃｔｉｏｎルーチンの一実施形態を示す流れ図である。 ｓｅｎｄ＿ｈｅａｒｔｂｅａｔサブ・ルーチンの一実施形態を示す流れ図である。 ｒｅｃｅｉｖｅ＿ｍｅｓｓａｇｅサブ・ルーチンの一実施形態を示す流れ図である。 ある実施形態におけるメッセージ・フローを示すメッセージ流れ図である。 ある実施形態におけるメッセージ・フローを示すメッセージ流れ図である。 ある実施形態におけるメッセージ・フローを示すブロック図である。

セッション接続を持続するための技術が、ある実施形態で、提供される。この技術は、
タイム・アウト条件のため、メッセージを送信しないことがセッション接続を閉じる原因になる可能性がある場合に、ハートビート・メッセージを送信する。ハートビート・メッセージは、データ通信スタックのより高いレベルのプロトコルによって無視されることになる空でないペイロードを収容する有効なトランスポート層メッセージである。一例として、この技術は、ペイロード内にキャリッジ・リターンおよび改行（「ＣＲＬＦ」）だけを含むＴＣＰメッセージを送信することができる。ＴＣＰ層は、ＣＲＬＦだけを含むメッセージを有効なＴＣＰメッセージであると見なすので、プロキシ・サーバなどの中間コンピューティング装置は、メッセージが送信された、または受信された接続に関するメッセージ・クロックを再設定するこができる。メッセージ・クロックは、接続内でメッセージが最後に送信されまたは受信されてから経過した時間量を指し示す。ある接続についてのメッセージ・クロックが閾値の時間量が経過したことを示す（たとえばタイム・アウト状態が発生したことを指し示す）場合、中間コンピューティング装置は、接続を閉じる可能性がある。メッセージ・クロックはメッセージが送信されまたは受信されるときに再設定（reset）されるので、閾値の時間量が経過する前に別のメッセージが送信されまたは受信されないという場合を除いては、接続は閉じられ得ない。受信側コンピューティング装置のＴＣＰ層が受信されたハートビート・メッセージをデータ通信スタックのより上の層に転送した後、その上位層は、ハートビート・メッセージを無視することができる。一例として、別な例では、ＳＩＰは、スペース、タブ、キャリッジ・リターン、改行またはＣＲＬＦなどの空白（white space）だけを含む、有効なＳＩＰメッセージを無視することができる。その上位層は、ＣＲＬＦ以外の情報を含むメッセージを受信する場合には、無視することができない情報を含むものとして、こうしたメッセージを解釈しようと試みることができる。様々な実施形態において、ハートビートは、キャリッジ・リターン、改行、あるいはトランスポート層では有効であるが、データ通信スタックのより上の層のプロトコルによっては無視される任意のデータだけを含むことができる。したがって、ＳＩＰによっては無視されるハートビート・メッセージなどの有効なトランスポート層メッセージを送信することによって、この技術は、トランスポート層より上のデータ通信スタック層ではコンピューティング装置間で情報が交換されない場合にも、セッション接続を持続することができる。無視されるが有効であるメッセージの種類については、プロトコルの仕様または定義内で定めることが可能でする。

ある実施形態では、トランスポート層より上の層によって無視されるメッセージは、キャリッジ・リターン、改行、スペース、タブまたは任意の空白文字などを一般に含むことが可能である。ある実施形態では、空白文字だけを含むこうしたメッセージは、キャリッジ・リターンまたは改行で終了することができる。過度な計算上の負担をもたらさずに接続を持続するためにメッセージ内で使用することができる文字は、接続を閉じることができるプロトコル（ＴＣＰなど）より上で使用されるプロトコルを分析することによって決定することができる。

次に図面に移ると、図１は、セッション接続を持続するためのシステムの一実施形態を示すブロック図である。このシステムは、１つまたは複数のクライアント１０２、１つまたは複数のネットワーク１０４、およびクライアントと前記ネットワークを接続するためのネットワーク、たとえばインターネット１１４を含む可能性がある。クライアントは、ネットワーク接続１０８を介してインターネットに接続することができる。ネットワーク１０４は、様々な形のデータ通信リンク１１０を使用して、インターネットに接続することができる。クライアントは、コンピュータ、携帯電話、またはインターネットに接続された他の装置などであることが可能である。ネットワークは、イントラネットなどであること可能である。クライアントは、私設のデータ通信リンク（private data communications links）１１２を使用して、ネットワークに直接に接続されることもできる。同様に、ネットワークは、私設のデータ通信リンク１１２を使用して、他のネットワークに直接に接続することもできる。インターネットは、様々な他のコンピューティング装置（図示せず）に接続されることもできる。本明細書で述べる接続は、物理接続、無線接続、また実際には任意の形のデータ通信ネットワーク接続である可能性がある。

図２は、図１のネットワークの一実施形態を示すブロック図である。ネットワーク２００は、１つまたは複数のクライアント２０２、サーバ２０４およびエッジ・プロキシ・サーバ２１２を含む。このネットワークは、他の装置（図示せず）をも含むことができる。このネットワークの図示された装置（および図示されていない装置）は、このネットワークに関連するデータ通信ネットワーク（図示せず）を介して相互接続することができる。クライアント２０２およびサーバ２０４は、ＳＩＰメッセージの交換を含めて、様々な動作を実施することができる。エッジ・プロキシ・サーバ２１２は、ネットワーク２００（「内部」ネットワーク）と、インターネット（図示せず）などの「外部」ネットワークの両方に接続される。クライアントがこのネットワークの外部のサーバとのセッションを開くことを望む場合、エッジ・プロキシは、たとえば、セッションが開かれるべきか、またどの通信リンクが使用されるべきかを決定することができる。

図３は、図１および２のコンピューティング装置によって使用されるデータ通信スタックの一実施形態を示すブロック図である。コンピューティング装置は、互いに通信するために、１つまたは複数のデータ通信スタックを使用することができる。図示する例では、コンピューティング装置３００は、こうしたコンピューティング装置に関連するデータ通信スタックを使用して、コンピューティング装置３０３と通信する。コンピューティング装置３０１および３０２は、その関連するデータ通信スタックを使用して、コンピューティング装置３００と３０３の間でメッセージを受信し、転送することができる。

コンピューティング装置３００は、アプリケーション層３０４、トランスポート層３０６、ネットワーク層３０８、データリンク層３１０および物理層３１２を含むデータ通信スタックを有する。アプリケーション層は、ＳＩＰアプリケーションおよび他のアプリケーションを含むことができる。ＳＩＰアプリケーションは、トランスポート層と通信するコンポーネントまたは層を含むことができる。ＳＩＰアプリケーションに属するこの通信層は、ハートビート・メッセージを送信しまたは受信することができる。コンピューティング装置３０１、３０２および３０３は、類似のデータ通信スタックを有することになる。具体的には、コンピューティング装置３０３は、アプリケーション層３１４、トランスポート層３１６、ネットワーク層３１８、データリンク層３２０および物理層３２２を含むデータ通信スタックを有することになる。こうしたアプリケーション層の一部またはすべては、ＳＩＰアプリケーションをさらに含むことができる。

２つのコンピューティング装置が接続される場合、そのデータ通信スタックの各層は、互いの間の論理的または物理的な接続を有することができる。一例として、コンピューティング装置３００がコンピューティング装置３０１および３０２を介してコンピューティング装置３０３に接続される場合、物理層３１２は、物理接続３２４を介してコンピューティング装置３０１の物理層に接続されることができ、このコンピューティング装置３０１は、物理接続を介してコンピューティング装置３０２の物理層に接続されることができ、またこのコンピューティング装置３０２は、物理接続を介してコンピューティング装置３０３の物理層に接続されることができる。コンピューティング装置はそれぞれ、たとえばモデム、ネットワーク・インターフェース・カード、またはインターネットなどの他の接続を介して互いに接続することができる。インターネットは、電話回線、マイクロ波リンク、ならびにメッセージのための複数のルートを共に形成する他の形の有線および無線接続のなど、様々な物理接続で構成される。実際に、インターネットの初期の目標は、送信者がネットワーク障害に拘らず受信者と通信できるようにすることであった。コンピューティング装置３００がコンピューティング装置３０３にデータを送信するときに、そのデータは、インターネットを介してそれぞれ異なる物理ルートを移動することが可能である。

データリンク層３１０および３２０、ネットワーク層３０８および３１８、トランスポート層３０６および３１６、ならびにアプリケーション層３０４および３１４などのデータ通信スタックの高位層は、論理接続３２６、３２８、３３０および３３２などの論理接続によって接続することができる。データ通信スタックの２つの層が論理接続を有し、データを交換する場合、そのデータは、送信側コンピューティング装置のデータ通信スタックの「下方」、そのデータ通信スタックの物理層に送られ、物理接続を渡り、次いで、受信側コンピューティング装置のデータ通信スタックを「情報に」送ることになる。一例として、コンピューティング装置３００のＳＩＰアプリケーション３０４がコンピューティング装置３０３のＳＩＰアプリケーション３１４と通信する場合、ＳＩＰアプリケーション３０４はトランスポート層３０６にデータを伝え、このトランスポート層はネットワーク層３０８にデータを伝え、このネットワーク層はデータリンク層３１０にデータを伝え、このデータリンク層は、物理層３１２にデータを伝えることになる。物理層３１２は、物理接続３２４を介してデータを通信することができ、最終的には物理層３２２にデータを伝えることになる。物理層３２２は、それが受信するデータをデータリンク層３２０に伝え、このデータリンク層は、ネットワーク層３１８にデータを伝え、このネットワーク層はトランスポート層３１６にデータを伝え、このトランスポート層は、最終的にはＳＩＰアプリケーション３１４にデータを伝えることができる。

コンピューティング装置３０１および３０２は、その物理接続上でデータを受信するときに、そのデータ通信スタックの上方にデータを送ることになる。データ通信スタックのアプリケーション層より低いレベルは、受信データをそれより上の層に送信せずに、それを処理することができる可能性がある。一例として、ＳＩＰアプリケーション３０４は、ＳＩＰアプリケーション３１４にＳＩＰメッセージを送信するときに、ＳＩＰメッセージに対応するデータをトランスポート層３０６に送ることになる。両方ともが物理層でデータを受信するコンピューティング装置３０１および３０２のデータ通信スタックは、そのデータ通信スタックの下から上に、そのそれぞれのトランスポート層に受信データを渡すことになる。データ内に示された宛先がコンピューティング装置３０３であることを受信データから認識するトランスポート層は、（その対応する下位レベルを介して）トランスポート層３１６に単にデータを転送することになる。したがって、コンピューティング装置３０１および３０２のアプリケーション／ＳＩＰ層は、メッセージを処理しまたはメッセージを見ることさえ不要であることになる。

ある時間期間にわたって、コンピューティング装置３０１または３０２のトランスポート層によってデータが受信されない場合、コンピューティング装置は、コンピューティング装置３００と３０３の間のＳＩＰセッションに対応する接続を閉じることになる。一例として、コンピューティング装置３０１は、コンピューティング装置３００またはコンピューティング装置３０２から接続に関するメッセージを受信しなかった場合、その接続はもはや不要であると見なし、その接続を閉じることになる。したがって、コンピューティング装置３０１と３０３の間のさらなるＳＩＰメッセージは、前に開いていたコンピューティング装置３０１および３０２を通過する接続を通過することが不可能になることになる。

図４は、ｓｅｎｄ＿ｍｅｓｓａｇｅルーチンの一実施形態を示す流れ図である。このルーチンは、メッセージ送信する、ＳＩＰアプリケーションのコンポーネントなどの、アプリケーション層コンポーネントによって実施されることになる。ｓｅｎｄ＿ｍｅｓｓａｇｅルーチンは、あるコンピューティング装置上で実行されるＳＩＰアプリケーションなどによって、それが別のコンピューティング装置上で実行されるＳＩＰアプリケーションにメッセージを送信するときに使用することができる。このルーチンは、ブロック４０２で開始し、パラメータとしてメッセージの指標（indication）を受信する。ブロック４０４で、ルーチンは、クロック値を、たとえばそれを０に設定するなどによって、再設定する。クロック値は、メッセージが最後に受信されてから経過した時間の指標である。この値は、接続が閉じられるべきかどうかを決定するために、システムのコンポーネントによってチェックすることができる。ブロック４０６で、ブロック４０２で受信されたメッセージをトランスポート層に送信する。このルーチンは、メッセージを送信するトランスポート層によって公開されたアプリケーション・プログラム・インターフェースを使用することができる。ブロック４０８で、ルーチンは、その呼出し側に戻る。

図５は、ｓｕｓｔａｉｎ＿ｃｏｎｎｅｃｔｉｏｎルーチンの一実施形態を示す流れ図である。このルーチンは、接続を持続するために、ＳＩＰアプリケーションのコンポーネントなどのアプリケーション層コンポーネントによって実施される。接続は、メッセージが最後に受信されてから経過した時間量を示すクロック値がタイム・アウト値を超える場合などに、持続される必要があることになる。適切なタイム・アウト値は、トランスポート層のＡＰＩを使用してトランスポート層の属性を決定するなどによって決定されることができ、またはシステムの管理者によって定義することができる。ルーチンは、ブロック５０２で開始する。ブロック５０４で、ルーチンは、クロック値がほぼタイム・アウト値であるかどうかを判定する。クロック値がタイム・アウト値を超える場合、接続が既に閉じられていることがある。結果として、タイム・アウト値の前のある時間期間が選択されるべきである。クロック値がほぼタイム・アウト値である場合、ルーチンは、ブロック５０６に続く。そうでない場合、ルーチンは、ブロック５０８に続く。ブロック５０６で、ルーチンは、ｓｅｎｄ＿ｈｅａｒｔｂｅａｔサブ・ルーチンを呼び出し、これは、接続を持続することができるメッセージを送る。ｓｅｎｄ＿ｈｅａｒｔｂｅａｔサブ・ルーチンについて、図６に関して以下でさらに述べる。ブロック５０８で、ルーチンは、その呼出し側に戻る。

ｓｕｓｔａｉｎ＿ｃｏｎｎｅｃｔｉｏｎルーチンは、メッセージ送信しまたは受信するスレッドとは別個のスレッドのループ内で繰返し呼び出されることになる。あるいは、ｓｕｓｔａｉｎ＿ｃｏｎｎｅｃｔｉｏｎルーチンは、タイム・アウト前の指定された時間間隔でトリガされるクロック・イベントに応答して呼び出すこともできる。

あるいは、ｓｕｓｔａｉｎ＿ｃｏｎｎｅｃｔｉｏｎルーチンは単に、クロック値に関係なく、タイム・アウト値より小さいある間隔で、ハートビート・メッセージを送信することができる。一例として、１分間活動が無かった後にプロキシ・サーバがタイム・アウトになる場合、このルーチンは、メッセージがほんの数秒前に送信されまたは受信された場合にも、３０秒ごとにハートビート・メッセージを送信することができる。

図６は、ｓｅｎｄ＿ｈｅａｒｔｂｅａｔサブ・ルーチンの一実施形態を示す流れ図である。このサブ・ルーチンは、ハートビート・メッセージを送信する、ＳＩＰアプリケーションのコンポーネントなどの、アプリケーション層コンポーネントによって実施される。ハートビート・メッセージは、ある時間にわたって接続内でメッセージが送信されない場合に閉じる可能性のある接続を持続するために送信することができる。サブ・ルーチンは、ブロック６０２で開始し、パラメータとしてセッションの指標（indication）を受信する。ボックス６０４で、サブ・ルーチンは、ハートビート・メッセージを作成する。ハートビート・メッセージは、データ通信スタックのある層によっては無視されることができるが、データ通信スタックの別の層によっては無視されることがないメッセージである。一例として、ハートビート・メッセージは、開いたＳＩＰセッションを有する２つコンピューティング装置間でメッセージを処理する別のコンピューティング装置（プロキシ・サーバなど）によってＴＣＰ接続が閉じられる恐れがある場合に、そのＴＣＰ接続を持続するために、ＳＩＰアプリケーションによって送信することができる。ハートビート・メッセージは、たとえばＣＲＬＦ文字だけを含むことができる。あるいは、ハートビート・メッセージは、ＣＲＬＦで終了する１つまたは複数のスペースおよびタブを含むことができる。ハートビート・メッセージは、ＣＲＬＦを使用するのではなく、キャリッジ・リターンまたは改行文字を使用することもできる。ＴＣＰ層にとって、こうしたメッセージは、メッセージが送信されまたは受信される際に、クロック値を再設定する有効なメッセージであることになる。しかし、ＳＩＰアプリケーションは、こうしたメッセージを無視することができる。したがって、こうしたハートビート・メッセージを送信することによって、ＴＣＰ接続は開かれた状態で保たれることができ、したがって、ＳＩＰプレゼンス情報は正確なままであり、有用でない情報が、ＳＩＰアプリケーションに提示されることはない。代替実施形態では、ハートビート・メッセージ内で、単にキャリッジ・リターンまたは改行文字が送信されることになる。

ブロック６０６で、サブ・ルーチンは、ｓｅｎｄ＿ｍｅｓｓａｇｅサブ・ルーチンを呼び出し、それに、作成されたハートビート・メッセージをパラメータとして渡す。ｓｅｎｄ＿ｍｅｓｓａｇｅサブ・ルーチンについて、図４に関連して上記で述べている。ブロック６０８で、サブ・ルーチンは、その呼出し側に戻る。

図７は、ｒｅｃｅｉｖｅ＿ｍｅｓｓａｇｅサブ・ルーチンの一実施形態を示す流れ図である。このサブ・ルーチンは、ＳＩＰアプリケーションなど、受信側コンピューティング装置のアプリケーション層コンポーネントによって実施されることになる。このサブ・ルーチンは、ブロック７０２で開始し、パラメータとしてメッセージの指標（indication）を受信する。ブロック７０４で、サブ・ルーチンは、受信されたメッセージがハートビート・メッセージかどうか決定する。サブ・ルーチンは、メッセージの内容が単にキャリッジ・リターン、改行またはその両方かどうかをチェックすることによって、受信されたメッセージがハートビート・メッセージかどうかを決定しようと試みることになる。あるいは、ｒｅｃｅｉｖｅ＿ｍｅｓｓａｇｅサブ・ルーチンは、ハートビート・メッセージを識別すると分かっている、メッセージ内の他の任意の、情報を探すようにカスタマイズすることができる。受信されたメッセージがハートビート・メッセージである場合、サブ・ルーチンは、ブロック７０６に続く。そうでない場合、サブ・ルーチンは、ブロック７０８に続く。ブロック７０６で、サブ・ルーチンは、メッセージに肯定応答することができる。一般に、トランスポート層が、メッセージに肯定応答する。しかし、場合によっては、アプリケーション層コンポーネント層が、メッセージに肯定応答する必要がある場合がある。このステップはサブ・ルーチンを実施するアプリケーション層コンポーネントに応じて任意選択であることができるので、ブロック７０６は、破線で示されている。ブロック７０８で、サブ・ルーチンは、ＳＩＰアプリケーションなどにメッセージを転送することになる。ブロック７１０で、サブ・ルーチンは、その呼出し側に戻る。

メッセージを受信すると、サブ・ルーチンは、クロック値（図示せず）を再設定することになる。このクロック値は、接続を持続するためにハートビート・メッセージが送信される必要があるかどうか決定するために使用することができる。

図８は、ある実施形態におけるメッセージの流れを示すメッセージ流れ図である。図示する実施形態では、コンピューティング装置１が、コンピューティング装置２とＳＩＰセッションを確立している。セッション内で交換されるメッセージは、プロキシ・サーバを通過する。一例として、ｔ＝０でコンピューティング装置１がメッセージ１を送信するときに、メッセージはプロキシ・サーバを通過し、ｔ＝１で、コンピューティング装置２が、メッセージを受信する。同様に、ｔ＝２でコンピューティング装置２がメッセージ２を送信するときに、メッセージは、ｔ＝でコンピューティング装置１がそれを受信する前に、プロキシ・サーバを通過する。プロキシ・サーバは、メッセージを転送しまたは受信するときはいつでも、クロックを再設定することができる。一例として、プロキシ・サーバは、メッセージ１を転送するときに、クロック値を０に再設定する。同様に、プロキシ・サーバは、メッセージ２を受信するときに、クロック値を０に再設定する。クロック値は、たとえばシステム・クロックに応答して、自動的に増分されることになる。クロック値がタイム・アウト値を超える場合、プロキシ・サーバは、そのセッションと関連する接続を閉じることになる。図示する例では、コンピューティング装置１は、クロック値がタイム・アウト値を超えた後は、メッセージ３を送信することが不可能となることになる。

図９は、ある実施形態におけるメッセージの流れを示すメッセージ流れ図である。図示する実施形態では、図８で示し、上記で説明したように、コンピューティング装置１および２は、時点０と３の間にメッセージ１および２を交換している。ｔ＝４で、コンピューティング装置１は、間もなくタイム・アウトになる（図中に破線で示す）ことを認識すると、ｔ＝５として示すタイム・アウトになる前に、コンピューティング装置２にハートビート・メッセージを送信することになる。ハートビート・メッセージを送信すると、プロキシ・サーバはクロック値を再設定することができ、したがって、プロキシ・サーバが接続を閉じてないので、コンピューティング装置１は、時点６で、メッセージ３を送信することが可能であることになる。プロキシ・サーバのタイム・アウトの前にハートビート・メッセージを送信することによって、システムは、コンピューティング装置１と２の間で接続を持続することができる。ハートビート・メッセージを送信するコンピューティング装置は、ハートビート・メッセージの受信側のクロック値もまたタイム・アウト値を超過するまでまだ十分な時間があるうちに、ハートビート・メッセージの送信を試みる必要があることになる。

図１０は、ある実施形態におけるメッセージの流れを示すブロック図である。図示する実施形態では、送信側コンピューティング装置１０００は、受信側コンピューティング装置１００２とのＳＩＰセッションを開いている。送信側コンピューティング装置がそのアプリケーション／ＳＩＰ層１００４を介してＳＩＰメッセージ１を送信するときに、トランスポート層１００６は、そのメッセージを２つのセグメントＳ１およびＳ２にセグメント化する可能性がある。タイム・アウトを回避するために、送信側コンピューティング装置は、ハートビート・メッセージＳ３を送信することができる。ハートビート・メッセージは、キャリッジ・リターン、改行、その両方、またはアプリケーションによっては無視されることになえるハートビート・メッセージを示す他の情報を含むことができる。次いで、受信側コンピューティング装置は、トランスポート層１０１６によってトランスポート・メッセージＳ４、Ｓ５およびＳ６としてセグメント化されたＳＩＰメッセージ２を送信することができる。セグメント化されたメッセージは、様々なサイズのものである可能性がある。

ある実施形態では、コンピューティング装置は、一部の接続でハートビート・メッセージを送信することができ、その接続を持続するために、他の接続を含む別の機構を使用することができる。一例として、コンピューティング装置は、それ自体の「ホーム」サーバ、またはそれに接続された他のコンピューティング装置にメッセージを送信するときに、そのホーム・サーバを、そのコンピューティング装置の接続にハートビート・メッセージを関連付け、またその関連付けの指標を格納することが可能であるので、ハートビート・メッセージを使用することができる。そうすることによって、サーバは、後に接続が失われる場合に、そのコンピューティング装置のプレゼンス情報を効率的に更新することを可能とすることができる。コンピューティング装置は、そうすることが有利である可能性がある場合には、他の接続でＲＥＧＩＳＴＥＲメッセージを送信することができる。一例として、コンピューティング装置は、中間装置がハートビート・メッセージを転送しない場合に、ＲＥＧＩＳＴＥＲメッセージを送信することができる。

本明細書で論じた特定の実施例は、ＳＩＰおよびＴＣＰを使用することに言及しているが、代替実施形態は、他の等価または類似のプロトコルを使用することができる。

セッション接続を持続するための技術が実装されるコンピューティング装置は、中央処理装置、メモリ、入力装置（キーボードおよびポインティング装置など）、出力装置（表示装置など）、および記憶装置（ディスク・ドライブなど）を含むことができる。メモリおよび記憶装置は、セキュリティ・システムを実装する命令を収容することが可能なコンピュータ読取り可能媒体である。さらに、そのデータ構造体およびメッセージ構造体は、格納したり、あるいは通信リンク上の信号などのデータ伝送媒体を介して送信したりすることができる。インターネット、ローカル・エリア・ネットワーク、広域ネットワークまたはポイント・ツー・ポイント・ダイヤルアップ接続など、様々な通信リンクを使用することができる。

図１に、セッション接続を持続するための技術を実装することが可能な適切なオペレーティング環境の一例を示す。このオペレーティング環境は、適切なオペレーティング環境の一例にすぎず、本システムの使用または機能の範囲についてのどんな制限をも示唆するものではない。使用に適す可能性のある他の周知のコンピューティング・システム、環境および構成には、パーソナル・コンピュータ、サーバ・コンピュータ、「スマート」携帯電話を含むハンドヘルドまたはラップトップ装置、マルチ・プロセッサ・システム、マイクロ・プロセッサ・ベースのシステム、プログラマブルな家電、ネットワークＰＣ、ミニ・コンピュータ、メインフレーム・コンピュータ、上記システムまたは装置のいずれかを含む分散コンピューティング環境などが含まれる。

セッション接続を持続するための技術について、１つまたは複数のコンピュータまたは他の装置によって実行されるプログラム・モジュールなど、コンピュータ実行可能命令の一般的な文脈で述べることができる。一般に、プログラム・モジュールは、特定のタスクを実施し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造体などを含む。一般に、プログラム・モジュールの機能は、様々な実施形態で望まれるように、組み合わせられることも、分散されることもある。

説明するため、本発明の具体的な実施形態について本明細書で述べたが、上記内容から、本発明の精神および範囲から逸脱せずに様々な修正を行うことができることが理解されよう。したがって、本発明は、添付の特許請求の範囲によって以外は限定されない。

１０２ クライアント
１０４ ネットワーク
１０８ ネットワーク接続
１１０ データ通信リンク
１１２ プライベート・データ通信リンク
１１４ インターネット
２００ ネットワーク
２０２ クライアント
２０４ サーバ
２１２ プロキシ
３００〜３０３ コンピューティング装置
３０４ アプリケーション／ＳＩＰ
３０６ トランスポート
３０８ ネットワーク
３１０ データリンク
３１２ 物理
３１４ アプリケーション／ＳＩＰ
３１６ トランスポート
３１８ ネットワーク
３２０ データリンク
３２２ 物理
１０００ 送信側コンピューティング装置
１００２ 受信側コンピューティング装置
１００４、１０１４ アプリケーション／ＳＩＰ（層）
１００６、１０１６ トランスポート（層）
１００８、１０１８ ネットワーク（層）
１０１０、１０２０ データリンク（層）
１０１２、１０２２ 物理（層）

Claims (16)

1. クライアント計算装置とサーバ計算装置との間のセッション接続を持続するためのプロキシ計算装置によって実行される方法であって、
   前記クライアント計算装置から前記プロキシ計算装置でハートビートメッセージを受信するステップであって、前記クライアント計算装置およびサーバ計算装置は、セッション開始プロトコルを使用してオープンセッションを有し、かつ、前記ハートビートメッセージは、トランスポート層プロトコルの有効なメッセージであって前記セッション開始プロトコルによって無視される、ステップと、
   前記クライアント計算装置とサーバ計算装置との間の前記セッション接続のメッセージクロックをリセットするステップと、
   前記プロキシ計算装置から前記サーバ計算装置に前記ハートビートメッセージを送信し、それによって、前記ハートメッセージを送信するステップは、前記クライアント計算装置とサーバ計算装置との間の前記セッション接続を維持する、ステップと
   を含むことを特徴とする方法。
2. 前記メッセージクロックをリセットするステップは、前記プロキシ計算装置から前記サーバ計算装置に前記ハートビートメッセージを送信した後に実行することを特徴とする請求項１に記載の方法。
3. 前記ハートビート・メッセージは、改行およびキャリッジ・リターンの一つまたは複数を含む空白文字を含むことを特徴とする請求項１に記載の方法。
4. 前記トランスポート層プロトコルはＴＣＰ／ＩＰであることを特徴とする請求項１に記載の方法。
5. 前記メッセージクロックは、前のメッセージが送信または受信されてから経過した時間を測定することを特徴とする請求項１に記載の方法。
6. 前記メッセージクロックは、データ通信スタックのトランスポート層によって送信または受信されるメッセージに関することを特徴とする請求項１に記載の方法。
7. 前記プロキシ計算装置は、エッジプロキシサーバであることを特徴とする請求項１に記載の方法。
8. 前記クライアント計算装置はネットワークの外部に有し、かつ、前記サーバ計算装置は前記ネットワーク内に有することを特徴とする請求項７に記載の方法。
9. 前記ハートビートメッセージを受信するステップ後一定期間を経て、前記クライアント計算装置から前記プロキシ計算装置で第２のハートビートメッセージを受信するステップと、
   時間間隔が前記一定期間を超えているかを判定するステップと
   をさらに含むことを特徴とする請求項１に記載の方法。
10. 前記一定期間が前記時間間隔を超えていると判定すると、前記クライアント計算装置と前記サーバ計算装置との間の前記セッション接続をドロップするステップをさらに含むことを特徴とする請求項９に記載の方法。
11. 前記一定期間が前記時間間隔を超えていないと判定すると、前記メッセージクロックをリセットし、それによって、前記セッション接続を維持するステップをさらに含むことを特徴とする請求項９に記載の方法。
12. クライアント計算装置とサーバ計算装置との間に通信可能に接続され、前記クライアント計算装置と前記サーバ計算装置との間のセッション接続を持続するように構成されているプロキシ計算装置であって、
    前記クライアント計算装置との接続を通じて、メッセージを受信する前記プロキシ計算装置上で実行可能な第１のコンポーネントと、
    前記受信したメッセージを前記サーバ計算装置に送信する前記プロキシ計算装置上で実行可能な第２のコンポーネントと、
    前記受信したメッセージがハートビートメッセージであるかを判定する前記プロキシ計算装置であって、前記ハートビートメッセージは、トランスポート層プロトコルの有効なメッセージであってセッション開始プロトコルによって無視され、かつ、前記受信したメッセージがハートビートメッセージであると判定すると、前記クライアント計算装置と前記サーバ計算装置との間の前記セッション接続のメッセージクロックをリセットし、それによって、前記クライアント計算装置と前記サーバ計算装置との間の前記セッション接続を維持する、前記プロキシ計算装置上で実行可能な第３のコンポーネントと
    を含むことを特徴とするプロキシ計算装置。
13. 前記プロキシ計算装置は、エッジプロキシサーバであることを特徴とする請求項１２に記載のプロキシ計算装置。
14. セッション接続を持続するためのサーバ計算装置によって実行される方法であって、
    セッション開始プロトコルを使用してクライアント計算装置とのセッションを確立するステップであって、前記セッションはセッション接続を有する、ステップと、
    プロキシ計算装置を介して、前記クライアント計算装置から、トランスポート層プロトコルを使用してハートビートメッセージを受信するステップであって、前記セッション開始プロトコルは、第２のプロトコルよりも高いデータ通信スタックの層によって用いられ、かつ、前記ハートビートメッセージは、前記トランスポート層プロトコルの有効なメッセージであって前記セッション開始プロトコルによって無視され、前記ハートビートメッセージを受信するステップは、前記サーバ計算装置で前記セッション接続を維持する、ステップと、
    前記クライアント計算装置とサーバ計算装置との間の前記セッション接続のメッセージクロックをリセットするステップと、を含み、
    前記セッションは、前記プロキシ計算装置を通じて、前記クライアント計算装置と前記サーバ計算装置との間で確立されて維持され、かつ、前記クライアント計算装置から前記サーバ計算装置で前記ハートビートメッセージを受信するステップの後に、前記セッション接続がリセットされる、ステップと
    を含むことを特徴とする方法。
15. 前記ハートビートメッセージは、前記セッション開始プロトコルのメッセージが受信されてから一定期間が経過したときに受信され、前記一定期間はタイムアウト値よりも短いことを特徴とする請求項１４に記載の方法。
16. 前記メッセージクロックは前記プロキシ計算装置によってリセットされることを特徴とする請求項１４に記載の方法。

Images