サーバ、および対応する冗長サーバと通信するように動作するクライアントを含むシステムにおける回復のための方法であって、ランダムに割り付けるアプローチに基づいてサーバ故障を検出するようにプロセスの少なくとも1つのタイミングパラメータを適応的に調整するステップと、前記少なくとも1つの適応的に調整されたタイミングパラメータに基づいて前記故障を検出するステップと、冗長サーバに切り替えるステップと、を含む方法。前記少なくとも1つのタイミングパラメータは、再試行の最大回数である、請求項1に記載の方法。前記少なくとも1つのタイミングパラメータは、応答タイマを含む、請求項1に記載の方法。前記少なくとも1つのタイミングパラメータは、キープアライブメッセージの伝送の間の期間を含む、請求項1に記載の方法。前記冗長サーバに切り替えるステップは、クライアントとのあらかじめ構成されたセッションを保持する冗長サーバに切り替えるステップを含む、請求項1に記載の方法。サーバ、および対応する冗長サーバと通信するように動作するクライアントを含むネットワークにおける回復のためのシステムであって、ランダムに割り付けるアプローチに基づいてサーバ故障を検出するようにプロセスの少なくとも1つのタイミングパラメータを適応的に調整し、前記少なくとも1つの適応的に調整されたタイミングパラメータに基づいて前記故障を検出し、冗長サーバにクライアントを切り替える制御モジュールを備えるシステム。前記少なくとも1つのタイミングパラメータは、再試行の最大回数である、請求項6に記載のシステム。前記少なくとも1つのタイミングパラメータは、応答タイマを含む、請求項6に記載のシステム。前記少なくとも1つのタイミングパラメータは、キープアライブメッセージの伝送の間の期間を含む、請求項6に記載のシステム。前記冗長サーバは、前記クライアントとのあらかじめ構成されたセッションに従事している、請求項6に記載のシステム。冗長サーバ構成におけるサービスの可用性を最大にするためのクライアント回復戦略に関する方法およびシステムが提供される。一態様においては、本方法は、サーバ故障を検出するプロセスの少なくとも1つのタイミングパラメータを適応的に調整するステップと、少なくとも1つの動的に調整されたタイミングパラメータに基づいて故障を検出するステップと、冗長サーバに切り替えるステップとを含む。別の態様においては、少なくとも1つのタイミングパラメータは、再試行の最大回数である。別の態様においては、少なくとも1つのタイミングパラメータを適応的に調整するステップは、再試行の最大回数をランダムに割り付けるステップを含む。別の態様においては、少なくとも1つのタイミングパラメータを適応的に調整するステップは、履歴ファクタに基づいて再試行の最大回数を調整するステップを含む。別の態様においては、少なくとも1つのタイミングパラメータは、応答タイマを含む。別の態様においては、少なくとも1つのタイミングパラメータを適応的に調整するステップは、履歴ファクタに基づいて応答タイマを調整するステップを含む。別の態様においては、少なくとも1つのタイミングパラメータは、キープアライブメッセージの伝送の間の期間を含む。別の態様においては、少なくとも1つのタイミングパラメータを適応的に調整するステップは、トラフィック負荷に基づいてキープアライブメッセージの間の期間を調整するステップを含む。別の態様においては、冗長サーバに切り替えるステップは、クライアントとのあらかじめ構成されたセッションを維持する冗長サーバに切り替えるステップを含む。別の態様においては、システムは、サーバ故障を検出するプロセスの少なくとも1つのタイミングパラメータを適応的に調整し、少なくとも1つの適応的に調整されたタイミングパラメータに基づいて故障を検出し、クライアントを冗長サーバに切り替える制御モジュールを備える。別の態様においては、少なくとも1つのタイミングパラメータは、再試行の最大回数である。別の態様においては、制御モジュールは、再試行の最大回数をランダムに割り付けることにより、少なくとも1つのタイミングパラメータを適応的に調整する。別の態様においては、制御モジュールは、履歴ファクタに基づいて再試行の最大回数を調整することにより少なくとも1つのタイミングパラメータを適応的に調整する。別の態様においては、少なくとも1つのタイミングパラメータは、応答タイマを含む。別の態様においては、制御モジュールは、履歴ファクタに基づいて応答タイマを調整することにより少なくとも1つのタイミングパラメータを適応的に調整する。別の態様においては、少なくとも1つのタイミングパラメータは、キープアライブメッセージの伝送の間の期間を含む。別の態様においては、制御モジュールは、キープアライブメッセージの間の期間を調整することにより少なくとも1つのタイミングパラメータを適応的に調整する。別の態様においては、冗長サーバは、クライアントとのあらかじめ構成されたセッションにおける冗長サーバである。本発明の適用可能性のさらなる範囲は、以下で提供される詳細な説明から明らかになるであろう。しかしながら、本発明の精神および範囲内の様々な変更形態および修正形態は、当業者には明らかになるので、詳細な説明および特定の例は、本発明の好ましい実施形態を示しながら、例証としてだけ与えられることを理解すべきである。本発明の実施形態による装置および/または方法のいくつかの実施形態は、次に、例としてのみ、および添付図面を参照して説明される。本記載の実施形態は、回復時間を改善するサーバの冗長な展開を有するネットワークに対して適用されることもある。図2を参照すると、本記載の実施形態が実装され得る一例のシステム100は、通常はサーバまたはネットワーク要素B1104からネットワークサービスにアクセスしている論理クライアントネットワーク要素A102を含む。名目上地理的に分散された冗長サーバまたはネットワーク要素B2106代替サーバ、または代替冗長サーバ、あるいはネットワーク要素とも称されるもまた、ネットワークにおいて使用可能である。そのような代替サーバ、または冗長サーバ、あるいは代替冗長サーバは、必ずしもそれが対応する主要なサーバを正確に再現するとは限らないことを理解すべきである。示される構成は、単に1つの例にすぎないこともまた認識すべきである。変形形態がうまく実装される可能性もある。また、複数の冗長的な、または代替的なネットワーク要素が、主要なネットワーク要素サーバB1などに対応することができることも理解すべきである。クライアントAと、サーバB1およびB2とはまた、それが存在するネットワーク要素、および/または他のネットワーク要素の機能を制御するように動作する制御モジュールそれぞれ103、105および107とともに示される。ネットワーク要素は、IPネットワーキングを経由した標準プロトコル例えば、SIPを含めて、様々な技法を使用して通信することができることも理解すべきである。下記の詳細な説明を読むことから明らかになるように、本記載の実施形態を具現化すると、サーバB1が故障するときに、クライアントAによって見られるように、改善されたサービスの可用性が促進される。図3を参照すると、クライアント回復戦略が、冗長構成についてのサービスの可用性を改善するための方法200が提供されている。本方法は、202においてサーバ故障を検出するためにクライアントプロセスのタイミングパラメータを動的に設定する、または調整するステップと、204において動的に設定されたタイミングパラメータに基づいて故障を検出するステップと、206において冗長サーバに切り替えるステップとを含む。本方法200は、様々なハードウェア構成およびソフトウェアルーチンを使用して実施され得ることを理解すべきである。例えば、ルーチンは、クライアントA例えば、クライアントAの制御モジュール103またはサーバB1またはB2例えば、サーバB1、B2の制御モジュール105、107において存在することができ、および/またはクライアントA例えば、クライアントAの制御モジュール103によりまたはサーバB1またはB2により例えば、サーバB1、B2の制御モジュール105、107により実行されることもある。それらのルーチンはまた、本記載の実施形態を実現するために例証されたシステムコンポーネントのうちのいくつかまたはすべてにおいて分散され、および/またはそれらのうちのいくつかまたはすべてによって実行されることもある。さらに、用語クライアントおよびサーバは、特定のアプリケーションプロトコル交換に関して参照されることを理解すべきである。例えば、コールサーバは、加入者情報データベースサーバに対するクライアントとすることができ、またIP電話クライアントに対するサーバとすることができる。さらにまた、他のネットワーク要素図示されずは、本方法を実施するルーチンを記憶し、および/または実行するように実装されることもあることを理解すべきである。主題のタイミングパラメータは、アプリケーションごとに変化するが、以下の少なくとも1つの形態を含むことができる。MaxRetryCount-このパラメータは、応答タイマが、タイムアウトした後に試みられる再試行の回数に対する最大値を設定する。TTIMEOUT-このパラメータは、深い非応答的システムに起因してクライアントが如何に高速にタイムアウトするかを保存し、初期要求およびすべての後続の再試行がタイムアウトするための典型的な時間を意味している。TKEEPALIVE-このパラメータは、サーバが依然として使用可能であることを検証するために、クライアントが如何に高速にサーバにポーリングするかを保存する。TCLIENT-このパラメータは、典型的なすなわち、中央値の、または50番目のパーセンタイル値のクライアントが、如何に高速に冗長サーバの上でサービスを正常に回復させるかを保存する。本記載の実施形態によれば、これらの値は、以下で説明されるように、適応的に例えば、動的に設定され、または調整される。これらのパラメータについての小さな値を使用して、できるだけ早く故障を検出し、代替サーバに切り替えFAILOVER:フェイルオーバーをし、ダウンタイムと失敗した要求とを最小にすることが望ましい。しかしながら、代替サーバに切り替えることは、そのサーバの上のリソースを使用して、クライアントを登録し、またそのクライアントについてのコンテキスト情報を取り出すことであると理解すべきである。あまりにも多数のクライアントが、同時に切り替えをする場合、過剰な回数の登録試行は、代替サーバを過負荷に駆動する可能性がある。それゆえに、重要でない一時的故障トラフィックのバーストに起因したブレードフェイルオーバーbladefailoversまたは一時的に遅いプロセスなどについての切り替えを回避することが有利であることもある。したがって、同期化された再伝送とタイムアウト戦略とに、1つのシステムインスタンスの故障に続くプールの中で、動作システムに対するトラフィックのスパイクまたはバーストを単に引き起こさせるのではなくて、代替サーバに対する再接続要求の形成が、クライアントそれら自体によって推進される。本記載の実施形態によれば、タイミングパラメータは、適応され、および/または設定され、その結果、暗黙の故障検出が最適化される。一実施形態においては、再試行の最大回数は、クライアント回復を改善する乱数に合わせて調整され、または設定される。これに関しては、プロトコルは、タイムアウト期間と最大再試行カウントとを指定するまたはネゴシエートするが、クライアントは、一般的に、代替サーバに接続しようと試みる前に、最後の再試行がタイムアウトするのを待つことを必要とされない。通常、メッセージが、プロトコルタイムアウトの期限切れに先立って応答を受信することになる確率は、非常に高い例えば、99.999のサービス信頼性。第1のメッセージが、プロトコルタイムアウトの期限切れに先立って応答を受信しない場合、第1の再伝送が迅速で正しい応答を与えることになる確率は、いささか低くなり、また場合によってはずっと低くなる。肯定応答されなかった各再伝送は、次の再伝送の成功の確率がより低くなることを示唆する。本記載の実施形態によれば、これらの可能性の高くない、またはますます絶望的になる再伝送のおのおのが続くのを単に待つのではなくて、クライアントは、異なる判断基準に基づいて非応答サーバに対して再伝送することを停止し、および/または異なった時間に代替サーバに切り替えることができる。異なるクライアントが、異なった時間に代替サーバに登録する場合、そのときにはこれらのクライアントの認証、識別およびセッション確立についての処理負荷は平坦にされるので、代替サーバはこれらのクライアントを受け入れる可能性がより高くなり、それによってサービス中断の持続時間が短くなる。これを達成するために、クライアントは、この実施形態において、試みられることになる再試行の回数をランダムに、すなわち、プロトコルの中でネゴシエートされる再伝送の試みの最大回数まで、割り付ける。もちろん、本明細書において提案される技法などの、ランダムに割り付けられたバックオフは、主要なサーバの大きな故障の後に代替サーバを過負荷状態に押し込める可能性があるトラフィックスパイクを取り除かないこともあるが、しかしながら、より長い期間にわたってクライアントによって開始された回復の試みを拡張することにより負荷を形成することは、代替サーバ上の負荷を平坦にすることになる。例示的な戦略は、メッセージまたは応答のタイマがタイムアウトするときはいつでも、各クライアントが、以下のプロシージャを実行するためのものである。1.乱数を生成するか、またはクライアント固有の数、例えば、ネットワークインターフェースMACアドレスの指定された桁を使用する。2.乱数のドメインをMaximumRetryCountバケットへと論理的に分割する。3.乱数が分類されるバケットに基づいてこの故障したメッセージ例えば、1つの再試行とMaximumRetryCountとの間のについてMaximumRetryCount値を選択する。これは、一例にすぎない。ランダムに割り付けるアプローチは、様々なやり方で実現されることもある。例えば、アプローチは、別のサーバに対して再接続するコストに基づいて重み付けされる可能性もある。例えば、いくつかのサービスは、初期化される必要がある大量の状態情報、検証される必要があるセキュリティ認証情報、およびシステムにかなりの負荷をかけ、エンドユーザに対するサービス配信遅延を増大させる他の懸案事項を有する。いくつかのプロトコルについてのこれらのより高いコストの再接続を補償するために、ランダムに割り付けられた最大再試行カウントは、いくつかの再試行のオプションを除外すること例えば、常に少なくとも1つの再試行を有することによるか、またはそれらのオプションに重み付けすること例えば、どのようにしてタイムアウトが、指数関数的に重み付けされ得るかなど、最大再試行カウントに指数関数的に重み付けすることによるかのいずれかで調整されることもある。最大再試行カウントの最小の数は、基礎となっているネットワークの動作と、より低いレイヤとトランスポートプロトコルとの挙動により影響を受ける可能性があることに注意すべきである。-0-という最大再試行カウントは、いくつかの展開については適切とすることができるが、最大再試行カウントの最小の数は、他の展開では1とすることができる。さらに、プロトコルによって使用される標準的な最大再試行カウントよりも短い可能性があるランダムに割り付けられた最大再試行カウントを単に設定することに加えて、追加のランダムに割り付けられた、増分のバックオフを使用して、さらにトラフィックを形成することもできる。別の実施形態においては、故障検出時間は、応答時間についての履歴データと、成功した応答のために必要な再試行の回数とを収集することにより改善される。したがって、TTIMEOUTおよび/または再試行の最大回数は、標準的なプロトコルタイムアウトおよび再試行の戦略に比べて、より高速に故障を検出し、また回復をトリガするように、適応的に調整されることができる。データを収集すること、およびタイミングパラメータを適応的に調整することは、様々な技法を使用して達成される得ることを理解すべきである。しかしながら、少なくとも1つの形態においては、データまたは応答時間、および/または再試行の回数は、例えば、日常ベースで、所定の期間にわたって、例えば、クライアントによって追跡され、または保持される。そのようなシナリオにおいては、追跡されたデータを使用して、適応できる、または動的な調整を行うことができる。例えば、タイマの調整された値は、例としてその日および/または前日など、与えられた期間にわたって追跡される最長の成功する応答時間よりも高い、一定の割合例えば、60に設定されることが例えば、クライアントにより決定され得る。変形形態においては、それらの値は、ネットワークの必要性に適合するように、例えば、15分ごとに、100パケットごとに、...など、定期的に更新されることもある。この履歴データを使用して、予測動作に基づいて調整を実施することもできる。さらなる例においては、図4を参照して、クライアントとサーバとの間で使用されるプロトコルは、最大3回の再試行を伴う5秒間の標準的なタイムアウトを有する。クライアントAは、サーバB1に対して要求を送信した後に、応答を5秒間待つ。サーバB1が、ダウンしているか、または到達できず、タイマの有効期限が切れる場合、クライアントAは、再試行を送信し、さらに5秒間待つ。もう2回再試行し、各再試行の後に5秒間待ち、初期メッセージと後続の再試行とに対する応答を待つのに全部で20秒間費やした後に、クライアントAは、サーバB1がダウンしていることを最終的に決定することになる。次いで、クライアントAは、別のサーバB2に対して要求を送信しようと試みる。しかしながら、図5を参照して、また本記載の実施形態に従って、クライアントAは、故障検出および回復の時間を短くすることができる。この例においては、クライアントAは、サーバの応答時間を追跡し続け、200msと400msとの間にあるサーバの典型的な応答時間を測定する。クライアントAは、5秒から、例えば、2秒5倍の最大の観察された応答時間へとタイマ値を減少させることができ、このことは、実際に観察された動作を使用して回復時間をより短くするような利点を有している。さらに、クライアントAは、それが送信するために必要とする再試行の回数を追跡することができる。サーバB1が、しばしば、第2または第3の再試行まで応答することがない場合、クライアントは、3回の再試行のプロトコル標準に従い続けるべきである。しかし、サーバB1は、常に元の要求に対して応答する可能性があり、したがって任意の再試行を送信することにおいてほとんど価値が存在しない。クライアントAは、それがただ1回の再試行に2秒間のタイマを使用することができると決定する場合、図5に例証されるように、全体のフェイルオーバー時間を20秒から4秒へと減少させる。新しいサーバにフェイルオーバーした後に、1つの形態においては、クライアントAは、登録のための標準的な、またはデフォルトのプロトコル値に戻り、それがより低い値を正当化するために新しいサーバの上で十分なデータを収集するまで、要求についての標準的な値を使用し続ける。上記で指摘されるように、プロトコル値を極端に低下させる前に、代替サーバにログオンするために必要とされる処理時間が考慮されるべきである。クライアントが、アプリケーションセッションを確立し、代替サーバによって認証を受ける必要がある場合、重要でない中断のために例えば、単純なブレードフェイルオーバーに起因して、またはIPネットワーク再構成をトリガするルータ故障に起因してサーバの間で前後にはねることbouncingbackandforthを回避することが重要になる。それゆえに、少なくとも1つの形態においては、最小のタイムアウト値が設定され、また少なくとも1回の再試行が常に試みられる。図6は、本記載の実施形態の別の変形形態を示すものである。これに関しては、サーバの重大な故障と、代替サーバを選択する必要性とを示す傾向が存在するかどうかを決定するために故障メッセージを相互に関連づけることが有利でありうる。クライアントAが、同時にサーバB1に対して多数の要求を送信している場合に、このアプローチは当てはまる。サーバB1が、それらの要求またはその再試行のうちの1つに応答しない場合、進行中の他の要求に対する応答を待つことはもはや必要でなく、それは、これらの要求は、同様に失敗する可能性が高いからである。クライアントAは、すべての現在の要求を代替サーバB2に対してすぐにフェイルオーバーし、方向づけ、また例えば、ハートビートを用いてそれが回復したことを示す表示を獲得するまで故障したサーバB1にそれ以上の要求を送信しないようにすることができる。例えば、図6に示されるように、クライアントAは、要求4についての再試行が失敗するときに代替サーバB2に対してフェイルオーバーすることができ、また次いで、それは、すぐに要求5および6を代替サーバに対して再試行することができる。クライアントAは、5および6についての再試行がタイムアウトするまで待つことはない。上記実施形態においては、クライアントAは、サーバB1が、一連の要求に応答することに失敗するまで、サーバB1がダウンしていることを認識しない。これは、少なくとも以下のようにして、サービスに悪影響を及ぼす可能性がある。逆方向トラフィック中断-時として、クライアント/サーバ関係は、両方向に機能する例えば、携帯電話は、モバイル交換センタに対してコールを開始することもでき、モバイル交換センタからコールを受信することもできる。サーバが、ダウンしている場合、サーバは、クライアントからの要求を処理することはなく、またサーバは、クライアントに対してどのような要求も送信しないことになる。クライアントが、しばらくの間、サーバに対してどのような要求も送信する必要がない場合、そのときには、この間隔中に、クライアントに向かう要求は、失敗することになる。エンドユーザ要求の失敗-要求は、TTIMEOUTMaxRetryCount1だけ遅延させられ、これは、いくつかの場合には、エンドユーザ要求の失敗を引き起こすのに十分な長さである。したがって、別の実施形態においては、この問題に対する解決法は、指定された時刻に、キープアライブメッセージと呼ばれる特別なハートビートをサーバに対して送信し、例えば、トラフィックの量に基づいて、キープアライブメッセージの送信の間の時間を調整することである。ハートビートメッセージと、キープアライブメッセージとは、類似した機構であるが、ハートビートメッセージは、冗長サーバの間で使用され、またキープアライブメッセージは、クライアントとサーバとの間で使用されることに注意すべきである。キープアライブメッセージの間の時間は、TKEEPALIVEである。したがって、本記載の実施形態によれば、TKEEPALIVEの値は、サーバとネットワークとの動作に基づいて、例えば、トラフィック負荷に基づいて、調整されることもある。クライアントAが、サーバB1からキープアライブメッセージに対する応答を受信しない場合、そのときにはクライアントAは、それが、サーバB1が故障しているかどうかを決定するための通常の要求に使用するのと同じタイムアウト/再試行アルゴリズムを使用することができる。その意図は、キープアライブメッセージが、動作コマンドがそうする前にサーバの非有用性を検出することができ、その結果、サービスは、実際のユーザ要求が、使用の可能性が高いサーバによって迅速にアドレス指定される適時に、代替サーバ例えば、B2に対して自動的に回復しうる、ということである。これは、クライアントが、クライアントにサービスを行うサーバ能力についての最新の知識を有していないときに、サーバに対して要求を送信するよりも好ましい。本記載の実施形態を例証するために、図7において、クライアントAは、低トラフィックの期間中に、定期的なキープアライブメッセージを主要なサーバB1に対して送信し、また肯定応答を受信することを期待する。しかしながら、主要なサーバB1が、この時間中に故障する場合、クライアントAは、故障したキープアライブメッセージによって故障を検出することになる。これに関しては、故障した主要なサーバが、例えば、再試行の最大回数内の調整されたタイムアウト値の範囲内の、キープアライブ、またはその再試行に応答しない場合、クライアントAは、代替サーバB2にフェイルオーバーすることになる。高トラフィックの期間中に、クライアントAは、通常の過程において要求を送信しており、また応答を受信しているが、キープアライブメッセージについての必要性は存在しない。この場合には、要求は決して遅延されないことに留意すべきである。もちろん、トラフィック負荷は、様々な技法を使用して測定されることも、または予測されることもある。例えば、実際のトラフィックフローが、測定されることもある。1つの代替案として、1日のうちの時間帯を使用して、トラフィック負荷を予測することもできる。さらなる機能強化は、あらゆるキープアライブの後ではなくて、あらゆる要求/応答の後にキープアライブタイマを再スタートすることである。これは、より高いトラフィックの期間中により少ないキープアライブをもたらすことになるが、サーバを用いた非アクティブの長い期間が存在しないことをも依然として保証している。別の機能強化は、クライアントが代替サーバにも定期的にキープアライブメッセージを送信することであり、それらのステータスを追跡することである。次いで、主要なサーバが故障する場合、クライアントは、代替サーバを単にランダムに選択するよりも使用の可能性が高いサーバに対する迅速で正常な回復の確率を増大させる。いくつかの形態においては、サーバはまた、キープアライブメッセージを監視して、クライアントが依然として動作しているかどうかをチェックすることもできる。サーバが、それがもはやキープアライブメッセージ、または他の任意のトラフィックを送信していないことを検出する場合に、サーバは、それをウェイクアップさせるために、それに対してメッセージを送信するか、または少なくとも警告を報告することができる。他のパラメータと同様に、TKEEPALIVEは、故障を迅速に検出できる程度に短いが、サーバが、クライアントからのキープアライブメッセージを処理する過剰な量のリソースを使用しているほどは短くはないように設定されるべきである。クライアントは、サーバと、IPネットワークとの動作に基づいてTKEEPALIVEの値を適応させることができる。TCLIENTは、クライアントが、代替サーバの上でサービスを回復するために必要とされる時間である。それは、以下についての時間を含んでいる。クライアントが、代替サーバを選択すること。代替サーバとプロトコルのネゴシエートをすること。識別情報を提供すること。認証情報を恐らくは相互に交換すること。サーバによる認可をチェックすること。サーバにおいて、およびサーバによってセッションコンテキストを生成すること。サーバによって適切な監査メッセージを生成すること。これらのファクタのすべては、ターゲットサーバと、恐らくは他のサーバ例えば、AAAサーバ、ユーザデータベースサーバなどとの時間およびリソースを消費する。サポートするユーザの識別、認証、認可およびアクセス制御は、多くの場合にTCLIENTが、増大することを必要とする。本記載の実施形態の別の変形形態においては、TCLIENTは、冗長サーバとのあらかじめ構成されたセッション、またはウォームセッションをそれらのクライアントに保持させることにより、短縮することができる。すなわち、登録され、またそれらの主要なサーバ例えば、B1からのサービスを取得するときに、クライアントAは、別のサーバ例えば、B2と接続し、またそのサーバを用いて認証し、その結果、主要なサーバB1が故障する場合に、クライアントAは、すぐに他のサーバB2に対して要求の送信を開始することができるようになる。多数のクライアントが同時に例えば、サーバまたはネットワーキング設備の故障の後にサーバに対してログオンしようと試み、かなりのリソースが、登録をサポートするために必要とされる場合、過負荷状況が起こる可能性がある。もちろん、本記載の実施形態の技法が使用される場合、代替サーバに対する過負荷の機会は、大いに低減されることになる。それにもかかわらず、この可能性がある過負荷は、いくつかの他の追加のやり方で対処可能であり、これらのやり方は、TCLIENTを増大させないことになる。代替サーバに対する回復をトリガするとすぐに、クライアントは、サービスを受けるクライアントの数、またはバックアップシステムにリダイレクトされる膨大なメッセージの発生を低減させるように取り扱われているトラフィックの量に基づいて、構成可能な期間を待つことができる。クライアントは、代替サーバに対してログオンしようと試みる前に、ランダムな長さの時間を待つことができるが、平均時間は、構成化可能であり、また同時にフェイルオーバーする可能性が高い他のクライアントの数に応じて設定可能である。多数の他のクライアントが存在する場合、平均時間は、より高い値に設定されることもある。代替サーバは、通常の過負荷として登録ストームを取り扱うべきであり、新しいセッション要求をスロットルで調整して、代替サーバに既に登録/接続しているユーザに対して受け入れることができないサービス品質を配信することを回避している。クライアント要求のいくつかは、それらがサーバに対してログオンしようと試みるときに拒絶されることになる。それらは、再試行する前にランダムな期間を待つべきである。登録要求を拒絶するときに、代替サーバは、サーバに対してログオンしようと再試行する前にどれだけ長い間それがバックオフする待つべきかをクライアントに対して積極的に示すことができる。これは、必要な量だけ登録トラフィックを分散するサーバ制御を与える。いくつかのサーバが存在する場合の負荷分散の場合に、サーバは、それらがどれだけ過負荷であるかに応じて、それらのDNSSRVレコードにおける重みを更新することができる。1つのサーバが故障するときに、そのクライアントは、代替サーバを決定するためにDNSの問合せを行うことになり、したがって、それらの大部分は、最もビジーでないサーバに移行することになる。当業者なら、上記で説明された様々な方法のステップは、プログラムされたコンピュータ例えば、制御モジュール103、105または107によって実行され得ることを簡単に認識するであろう。本明細書において、いくつかの実施形態はまた、プログラムストレージデバイスを、例えば、デジタルデータストレージ媒体を対象として含むようにも意図され、これらのプログラムストレージデバイスは、マシン読取り可能、またはコンピュータ読取り可能であり、また命令のマシン実行可能プログラム、またはコンピュータ実行可能プログラムを符号化し、そこでは前記命令は、前記上記で説明された方法のステップのうちの一部または全部を実行する。プログラムストレージデバイスは、例えば、デジタルメモリ、磁気ディスクおよび磁気テープなどの磁気ストレージ媒体、ハードドライブ、または光学的読取り可能デジタルデータストレージ媒体とすることができる。実施形態はまた、上記で説明された方法の前記ステップを実行するようにプログラムされるコンピュータをカバーするようにも意図される。さらに、クライアントまたはサーバとしてラベル付けされる任意の機能ブロックを含む、図面の中に示される様々な要素についての機能は、専用のハードウェアならびに適切なソフトウェアと関連づけてソフトウェアを実行することができるハードウェアの使用を通して提供されてもよい。プロセッサによって提供されるときに、それらの機能は、単一の専用のプロセッサによって、単一の共用のプロセッサによって、またはそれらのうちのいくつかが共用され得る複数の個別のプロセッサによって提供されてもよい。さらに、用語プロセッサまたはコントローラの明示的な使用は、ソフトウェアを実行することができるハードウェアだけを排他的に意味するように解釈されるべきではなく、また限定することなく、デジタル信号プロセッサDSP:digitalsignalprocessorのハードウェアと、ネットワークプロセッサと、特定用途向け集積回路ASIC:applicationspecificintegratedcircuitと、フィールドプログラマブルゲートアレイFPGA:fieldprogrammablegatearrayと、ソフトウェアを記憶するためのリードオンリーメモリROM:readonlymemoryと、ランダムアクセスメモリRAM:randomaccessmemoryと、不揮発性ストレージとを暗黙のうちに含むことができる。他の既存のおよび/またはカスタムしたハードウェアもまた、含まれる可能性もある。同様に、図面の中に示される任意のスイッチは、概念的なものにすぎない。それらの機能は、プログラムロジックのオペレーションを通して、専用のロジックを通して、プログラム制御と専用のロジックとの相互作用を通して、または手動によってさえも実行可能であり、特定の技法は、より具体的に文脈から理解されるように、実装者によって選択可能である。方法200を含めて、本記載の実施形態は、様々な環境において使用され得ることもまた、理解すべきである。例えば、本記載の実施形態は、様々なミドルウェア構成、トランスポートプロトコル、および物理ネットワーキングプロトコルを用いて使用され得ることを認識すべきである。非IPベースのネットワーキングもまた、使用されることもある。上記の説明は、単に本発明の特定の実施形態の開示を提供しているにすぎず、本発明をそれだけに限定する目的のために意図されてはいない。したがって、本発明は、上記で説明された実施形態だけに限定されるものではない。むしろ、当業者が本発明の範囲内に含まれる代替の実施形態を考案し得ることが認識される。