JP2011530953A - メッセージ経路指定プラットフォーム - Google Patents

Abstract

通信ネットワークにおいてメッセージの経路指定を行うためのシステム及び方法が開示される。このシステムは、対象受信者に配送されるパケットを受信するための複数のノードを備え、このシステムは、対象受信者が複数のノード内の第１の選択されたノードに接続されているかどうかを判定し、対象受信者が第１の選択されたノードに接続されている場合にパケットを配送するように構成され、対象受信者が複数のノード内の第１の選択されたノードに接続されていないと判定された場合には、対象受信者が複数のノードのうちのどのノードに接続されているかを判定し、対象受信者が接続されているノードにパケットを回送するようにさらに構成される。
【選択図】 図１

Description

本願は、情報の経路指定を行うためのシステム及び方法に関する。特に、本発明は、限定はしないが、モバイル通信ネットワークにおいてメッセージ及びデータの経路指定を行うことに関する。

ＳＭＳ、ＭＭＳ、ＶＯＩＰ、電子メール、インスタントメッセージング、ビデオメッセージング、ライブビデオストリーミングなどのメッセージング及びモバイルデータフォーマットの衰えを知らない人気のせいで、ネットワーク容量に対する負担は増大する一方である。トラヒックの増加は、ネットワーク効率に影響を及ぼす。データスループットを改善するために、多くのプロバイダが、設定されているデータ使用量限度を超えるさまざまなユーザに提供されるデータ転送速度が制限されるシェーピングを採用している。

データトラヒック増大の影響は、現在のモバイル通信プラットフォームの多くにかなり顕著に表れている。本質的に、モバイル技術が第１世代のモバイルデバイスから、第２世代、第２．５世代、そしてより最近の第３世代へと進歩するにつれ、データトラヒックは指数関数的に増大してきた。これは、主に、帯域幅の増加によるものであった。しかし、モバイルネットワーク上のデータ転送の効率は、ネットワークのハードウェアコンポーネントによる速度制限を受ける。ハードウェアは、データ転送速度を制限するだけでなく、ネットワークを用いる１つのノードが特定の時点においてサービスを提供できるユーザの数も制限する。

モバイル通信ネットワーク上に送り出されるデータの量が増える一方であるとすれば、明らかに、現在のネットワークデータトラヒックを処理する能力を有するだけでなく、データの増大に応じて容易に拡張可能であるメッセージングシステム及び方法が必要である。

そこで、本発明の一態様において、通信ネットワーク内のメッセージの経路指定を行うためのシステムが構成され、前記システムは、対象受信者に配送されるパケットを受信するための複数のノードを備え、このシステムは、対象受信者が複数のノード内の第１の選択されたノードに接続されているかどうかを判定し、その受信者が第１の選択されたノードに接続されている場合にパケットを配送するように構成され、その受信者が複数のノード内の第１の選択されたノードに接続されていないと判定された場合には、対象受信者が複数のノードのうちのどのノードに接続されているかを判定し、対象受信者が接続されているノードにパケットを回送するようにさらに構成される。

好ましくは、複数のノードのうちのそれぞれのノードは、互いに結合された複数のサーバを含む。適切には、それぞれのノードは、複数のサーバのうちの第１のサーバを含み、前記第１のサーバは、対象受信者がノード上の複数のサーバの中の少なくとも１つのサーバに接続されているかどうかを判定するように構成されている。第１のサーバは、パケットの経路指定先となるノードの宛先アドレスを含んでいるかどうかを判定するように構成されうる。好ましくは、第１のサーバは、パケットを所望の宛先に回送するとパケット内の経路指定情報をクリアするように構成される。

メッセージパケットが、経路指定情報を含まず、第１のサーバが、そのノードに対象受信者が接続されていないと判定した場合、第１のサーバはレジストリへのメッセージパケットの経路指定を行うように構成される。レジストリには、１つ又は複数のサーバを含むことができる。適切には、レジストリは、対象受信者の接続先だった最後のノードのロケーションに関する情報について少なくとも１つのデータベースに問い合わせを行うように構成されている第１のサーバを含む。少なくとも１つのデータベースに、対象受信者の最後の知られているロケーションに関する情報が格納されている場合、最初のレジストリサーバが、パケットを識別されたノードの第１のサーバに回送する。

適切には、レジストリは、複数のデータベースに対して同時に、又は順次的に問い合わせを行うことができる。データベースは、単一のロケーションに置くか、又はネットワーク全体にわたって分散配置することができる。

好ましくは、それぞれのノード及び／又はそれぞれのレジストリ内の複数のサーバが、同じ物理的ロケーションを占有するとよい。或いは、それぞれのノード及び／又はレジストリ内のサーバをそのノード／レジストリ内の異なるロケーションにわたって分散させることができ、このような場合、サーバは複数のクラスタにグループ化される。

これらのパケットとしては、メッセージパケット、情報パケット、又はプレゼンスパケットが挙げられる。パケットがメッセージパケットであり、このシステムが受信者のロケーションを判定することができない場合、このシステムは、所定のルールセットに従ってパケットを配送しようと試みる。配送ルールは、（限定はしないが）ＳＭＳ配送、電子メール配送、及び／又は他の代替媒体を介した配送を含んでいてもよく、また含むことができる。パケットが情報パケットである場合、このシステムは、「ｎｏｔ ｆｏｕｎｄ」エラーパケットをメッセージ発信元に送り返す。メッセージパケットがプレゼンスパケットである場合、このシステムは、そのパケットを破棄する。

本発明の他の態様において、通信システム内のメッセージの経路指定を行うための方法が提供され、前記方法は、
対象受信者に対する１つのパケットを複数のノードのうちの第１のノードにおいて受信するステップと、
対象受信者がそのノードに接続されているかどうかを判定し、対象受信者がそのノードに接続されている場合にパケットを対象受信者に配送し、その受信者が第１のノードに接続されていない場合には、対象受信者が複数のノードのうちのどのノードに接続されているかを判定し、対象受信者が接続されているノードにパケットを回送するステップとを含む。

この方法は、判定するステップが対象受信者の接続先であるノードを識別するのに失敗した場合にパケットをレジストリに回送するステップをさらに含むことができる。

この方法は、１つ又は複数のデータベースに問い合わせを行い、対象受信者がどのノードに最後に接続したかを判定し、前記１つ又は複数のデータベースから取り出した情報に基づいてそのノードにパケットを回送するステップを含むこともできる。

好ましくは、この方法は、所定のルールに基づいてパケットを受信者に回送するステップを含む。

本発明を理解しやすくし、実用上の効果をもたらすために、本発明の好ましい実施形態を例示する、付属の図面を参照する。

本発明の一実施形態によるパケットの経路指定を行うためのシステムを例示する略図である。 本発明の一実施形態による経路指定プロセスを例示する流れ図である。 本発明の一実施形態による経路指定プロセスの下にあるネットワークコンポーネント間の接続関係を例示する略図である。 本発明の一実施形態によるデータシャードを配置するためにレジストリサーバによって使用されるプロセスを例示する略図である。

本明細書の説明全体を通して、「接続」及び「レジストリ」という用語は、システムアーキテクチャの説明に関連して用いられる場合には、エンドユーザ／デバイス（接続）の接続性及びデータベース／永続的データアクセス（レジストリ）を処理する論理サーバコンポーネントを指すことは理解されるであろう。同様に、「ロケーション」という用語は、上で定義されているように「接続」の一意的識別子と称される、「ユーザ又はデバイスの位置」を表すために使用される。これは、例えば、ＩＰアドレスとすることができるが、このアーキテクチャは、他のアドレッシング方式をも対象とする。「データベース」という用語は、単にデータの記憶域程度の意味合いでも使用され、データ（ＳＱＬデータベースなどの）を格納する特定の方法、又は特定のデータベース管理システム若しくは製品を意味するわけではない。

図１を参照すると、そこには、本発明の一実施形態によるパケット１０２を経路指定するためのシステム１００の一例が示されている。この特定の例におけるパケットとして、メッセージパケット、情報パケット、及びプレゼンスパケットが挙げられる。ＸＭＰＰプロトコルを使用する場合、これらは＜ｍｅｓｓａｇｅ＞、＜ｉｑ＞、及び＜ｐｒｅｓｅｎｃｅ＞スタンザとそれぞれ相関する。

この例では、発信元クライアント１０１は、パケット１０２をフォーマットし、複数のノード１０３ａ、１０３ｂ、１０３ｃ、及び１０３ｄ（ネットワーク）のうちの第１の選択されたノード１０３ａ内の複数のサーバ（クラスタ）１０４ａ、１０４ｂ、１０４ｃのうちの第１の選択されたサーバ１０４ａに回送し、対象受信者１０８に配送する。パケット１０２が、選択されたノード１０３ａ内の第１のサーバ１０４ａに配送された後、第１のサーバ１０４ａは、対象受信者１０８が第１のサーバ１０４ａに接続されているかどうかを判定する。受信者が、サーバ１０４ａに接続されている場合、サーバは、対象受信者１０８にパケットを配送（ローカル配送）するステップに進む。

受信者１０８が、クラスタ内のサーバ１０４ａ、１０４ｂ、１０４ｃに接続されていない場合、第１のサーバ１０４ａは、パケット１０２が宛先アドレスを含んでいるかどうかチェックするステップに進む。例えば、パケット１０２は、ノード１０３ｃ内のサーバ１０４ｃを宛先アドレスとして指定することができ、その場合、ノード１０３ａ内のサーバ１０４ａはパケット１０２をノード１０３ｃ内のサーバ１０４ｃに直接送るように経路指定する。当業者であれば、パケットを、ノード１０３ｂ、１０３ｄ、１０３ｃを通してノード１０３ｃ内のサーバ１０４ｃに間接的に送るように経路指定することが可能であり、次いで、ノード１０３ｃ内の第１のサーバ１０４ａは、パケット１０２の配送を受け取ってから、パケット１０２をサーバ１０４ｃに回送し、受信者１０８に配送することが可能であることを理解するであろう。

受信者１０８が、サーバ１０４ａに接続されておらず、パケットが指定された宛先アドレスを含んでいない場合、ノード１０３ａ内のサーバ１０４ａは、パケットをレジストリ１０５に回送する。説明を明確にし、わかりやすくするために、この例は、ただ１つのレジストリ１０５のみを含むように示されているが、当業者であれば、システムは任意の数のレジストリ１０５を備えることができることを理解するであろう。

図示されているように、レジストリ１０５は、複数のサーバ１０６ａ、１０６ｂ、１０６ｃ（レジストリサーバのクラスタ）を含む。パケット１０２が、複数サーバ（クラスタ）１０６ａ、１０６ｂ、１０６ｃから第１のサーバ１０６ａに配送された後、サーバ１０６ａは、１つ又は複数のデータベース１０７ａ、１０７ｂ、１０７ｃに、対象受信者１０８の最後の知られているロケーションに関する情報を問い合わせる。対象受信者１０８の最後のロケーションに関する情報が利用可能である場合、第１のサーバ１０６ａは、パケットを受信者１０８が最後に接続されたしかるべきノード１０３ａ、１０３ｂ、１０３ｃ、及び１０３ｄ内のサーバ１０４ａ、１０４ｂ、１０４ｃに回送する。この例では、データベースから得られた情報は、受信者１０８がノード１０３ｄ内のサーバ１０４ａに最後に接続されたことを示しており、この場合、サーバ１０６ａは、パケット１０２を配送のためノード１０３ｄ内のサーバ１０４ａに回送する。受信者１０８が、それ以降にロケーションを移動した場合、サーバ１０４ａは、上述のようにパケットを処理するか、又はさらに経路指定を行うことができる。さまざまなノード間のパケットの経路指定など方法の詳細について、以下において図２を参照しつつ説明する。

本発明の他の実施形態では、第１のサーバ１０４ａは、対象受信者１０８が第１のサーバ１０４ａに接続されていないと判定した後、ノード１０３ａに含まれるクラスタ内の残りのサーバ１０４ｂ、１０４ｃの探索を最初に実行して、対象受信者１０８が残りのサーバ１０４ｂ、１０４ｃのうちの１つに接続されているかどうかを判定することが可能である。対象受信者が、残りのサーバ１０４ｂ、１０４ｃのうちの１つに接続されている場合、サーバ１０４ａは、受信者１０８が接続されているサーバ（この場合、サーバ１０４ｂ）にパケットを回送する。次いで、サーバ１０４ｂは、パケットを受信者１０８に配送する。

上述のように、ノード１０３ａ、１０３ｂ、１０３ｃ、及び１０３ｄ内のサーバ、及びレジストリ１０５はクラスタ構成をとっている。これらのクラスタは、通常、サーバ同士の間で少なくとも１つのネットワーク接続が利用可能になっている多数のサーバからなる。したがって、サーバは、サーバ間のネットワーク接続が利用可能であるという条件の下でノードのサービスエリア上に地理的に分散されうる。上記の説明では、レジストリとノードとの間に区別をつけているが、当業者であれば、この区別は説明を明確にするためにのみつけられているのであって、与えられたノード内のサーバのクラスタはどれも接続又はレジストリタイプのクラスタであってもよいことは理解するであろう。

図２を参照すると、上述の図１のシステムにおいて使用されうる経路指定プロセスの一例を示す流れ図であることがわかる。ここで、パケット１０２がフォーマットされ、ノード１０３ａ内の「接続」サーバ１０４ａに配送される。ネットワーク内には、複数のノード１０３ａ、１０３ｂ、１０３ｃ、１０３ｄがあるので、受信者１０８は、与えられたノードに含まれるサーバのクラスタ内の接続サーバ１０４ａ、１０４ｂ、１０４ｃのうちの１つに接続されうる。したがって、パケットを扱う接続サーバ１０４ａは、チェック２０１を実行して、対象受信者がパケットを処理するサーバ１０４ａにローカル接続されているかを確認する。このチェックの結果が「はい」であれば、パケット受信者が見つかっており、そのパケット受信者は現在処理を扱っているサーバ１０４ａに接続されることを意味する。したがって、サーバ１０４ａは、パケット１０２のローカル配送２０２を続ける（つまり、受信者１０８がサーバ１０４に接続されている場合）。

「いいえ」がチェック２０１から返された場合、接続サーバ１０４ａは、対象受信者２０３のロケーションを判定するための探索手順を開始しなければならない。この探索手順では、接続サーバ１０４ａは、パケット１０２が「経路指定宛先」２０３を含むかどうかをチェックするステップに進む。この例における経路指定情報は、パケットの回送先となるクラスタ１０４ａ、１０４ｂ、１０４ｃ（これは、例えば、前記サーバのＩＰアドレスとすることができるが、他のアドレッシング方式も適用可能である）内の与えられ接続サーバを指定する一意的な識別子である。したがって、送信側クライアントは、パケット１０２内の任意選択の「経路指定宛先」フィールドを使用して、クライアントに認識されている特定の接続サーバへの経路指定を要求することができるか、又は受信者１０８が接続される接続サーバ１０４ａ、１０４ｂ、１０４ｃを含むノード１０３ａ、１０３ｂ、１０３ｃ、１０３ｄのロケーション若しくはそうである可能性の高いロケーションを推論することができる。

パケット１０２が経路指定情報を含んでいる場合、パケット１０２の処理を扱う接続サーバ１０４ａは、そのパケット１０２を経路指定情報において識別される接続サーバ１０４ａ、１０４ｂ、１０４ｃに回送する。次いで、経路指定情報が「クリアされる」、つまり削除され（２０４）、これにより、パケット１０２が関連する宛先ノード内の関連する接続サーバによってパケットが処理されるときにループ内の同じ宛先にそって無限に経路指定されることが防止される。

宛先受信者が、処理を行っている接続サーバ１０４ａに接続されていない場合、またパケット１０２において指定されている経路指定宛先がない場合、対象受信者１０８のロケーションを確認するために、接続サーバ１０４ａはパケット１０２をレジストリサーバ１０６ａ、１０６ｂ、１０６ｃのクラスタ内の選択されたレジストリサーバ１０６ａに回送する（ステップ２０５）。所望の方式を使用してこれに適したレジストリサーバ１０６ａ、１０６ｂ、１０６ｃを決定するための処理を実行するのは、接続サーバ１０４ａの役目である（これは、最も近いレジストリサーバ、若しくは負荷の最も少ないサーバであるか、又は知られている利用可能なレジストリ、若しくは他の方法からランダムに単純に選択することが可能である）。

パケット１０２がレジストリサーバ１０６ａに到達すると、レジストリサーバ１００６ａは、１つ又は複数のデータベース１０７ａ、１０７ｂ、１０７ｃ内の受信者データ（例えば、受信者のユーザアカウントなど）を検索する。データベース１０７ａ、１０７ｂ、１０７ｃは、接続及びレジストリサーバと同様のものであってもよく、ネットワーク全体に分散されるクラスタで構成され、これにより、受信者データをネットワーク内の複数のデータベースに保存することができる。このような場合、すべてのレジストリサーバ１０６ａ、１０６ｂ、１０６ｃは、与えられたユーザデータが格納される場所及びそれに接続する方法を決定するために必要な情報とともに構成される。パケット１０２を処理するレジストリサーバ１０６ａは、その構成情報を使用して、適切なデータベース１０７ａ、１０７ｂ、１０７ｃに接続し（それ以前に接続されていなければ）、対象受信者１０８のユーザプロファイルデータをデータベース２０６に問い合わせる。

レジストリサーバ１０６ａが、関連するデータベース１０７ａ、１０７ｂ、１０７ｃ内にユーザプロファイルデータを配置した後、レジストリサーバ１０６ａは、受信者のユーザアカウントの最新のロケーションが知られているかチェックするステップに進む（２０７）（「ロケーション」は、ここでは、上で決定されているように使用され、これはネットワーク内の与えられたノードにおける接続サーバの一意的な識別子である）。同様に、「最新のロケーション」とは、ここでは、対象受信者１０８に最近サービスを提供した接続サーバ１０４ａ、１０４ｂ、１０４ｃのことである。レジストリサーバ１０６ａによってパケット１０２を、対象受信者に最後にサービスを提供した最後の知られている接続サーバ１０４ａ、１０４ｂ、１０４ｃに回送する前に、パケットがレジストリサーバ１０６ａ、１０６ｂ、１０６ｃによって接続サーバ１０４ａ、１０４ｂ、１０４ｃにすでに回送されているかどうかを判定するさらなるチェックを実行する（２０８）。すでに回送されていれば、パケットは、再び回送されることはない。

パケット１０２が、レジストリ１０６ａ、１０６ｂ、１０６ｃによってまだ回送されていない場合、現在パケットを処理している最中のレジストリ１０６ａは、パケットを現在処理している最中のレジストリサーバ１０６ａによってパケットが回送されたことを示す情報をパケット１０２にタグとして付ける。次いで、レジストリサーバ１０６ａが、パケット１０２を適切な接続サーバ１０４ａ、１０４ｂ、１０４ｃに回送する（２０９）。次いで、関連する接続サーバ１０４ａ、１０４ｂ、１０４ｃが、上述のようにパケットの処理を続行する。このようにしてパケット１０２にタグ付けすることにより、次回パケット１０２がレジストリと接続サーバとの間でパケットを返す無限ループが形成されないことのチェック２０８を通ることが確実になる。

レジストリサーバ１０６ａによって受信者のロケーションを決定できない場合、パケットの受信者１０８は、現時点２１０において接続サーバ１０４ａ、１０４ｂ、１０４ｃに接続されていないと結論される。ある意味で、対象受信者１０８は「オフライン」になっているのである。次いで、プロトコルによって、パケット１０２が属している（２１１）クラス（つまり、メッセージ、情報、又はプレゼンス）が判定される。パケットがどのようなタイプに属しているかに応じて、経路指定プロセスがパケットを扱う方法は異なる。

「最も重要である」と考えられる、「メッセージパケット」の場合、システムは、一組の経路指定ルール２１２を調べて、パケットがそのときに配送される方法に関して適切な決定を下す。メッセージを配送する方法を定める経路指定ルール２１２は、（限定はしないが）ＳＭＳ配送、電子メール配送、及び／又は他の代替媒体を介した配送を含むことができる。

「情報パケット」（ＸＭＰＰプロトコルにおけるＩＱスタンザに対応する）の場合、「ｎｏｔ ｆｏｕｎｄ」エラーパケット（一般に４０４エラーとも称される）が、元のパケット２１３の送信者に送り返される。次いで、エラーパケットの配送はまた、本明細書で説明されているのと同じメッセージ経路指定アルゴリズムに従う。エラーパケットは、元のパケットがすでにエラーパケットであった場合には送信されない（つまり、エラー応答に対してエラー応答は送信されない）。このこともまた、無限ループの発生を防ぐ。

「プレゼンスパケット」の場合、これらのパケットは、情報の受信者がクラスタに接続されていない場合は無関係であるとみなされる。したがって、これらのパケットは、情報を送信者２１４に送り返すことなく黙って破棄される。

上記の説明からわかるように、本発明の一実施形態による経路指定プロセスは、以下の主要コンポーネントからなるネットワーク接続されたシステムを対象とする。
・クライアント（複数可）１０１、１０８
・接続（複数可）１０４ａ、１０４ｂ、１０４ｃ
・レジストリ（複数可）１０６ａ、１０６ｂ、１０６ｃ
・データベース（複数可）１０７ａ、１０７ｂ、１０７ｃ

これらのコンポーネント間の接続関係は、図３に示されている。経路指定アルゴリズムでは、以下の接続関係を指定する。発信側１０１及び受信側１０８のクライアントは、接続サーバ１０４ａ、１０４ｂ、１０４ｃにのみ接続する。図示されているように、１つ又は複数のクライアント１０１、１０８が１つの接続サーバ１０４ａに接続することができる。クライアントは、任意の与えられた時点においていくつでも接続できるが、１つのクライアント／ユーザアカウントは、一度に１つの接続サーバ１０４ａにしか接続できない。任意の与えられた時点において接続サーバ１０４ａ、１０４ｂ、１０４ｃはいくつでも使用可能にできる。任意の接続サーバが、任意のレジストリサーバ１０６ａ、１０６ｂ、１０６ｃに接続することができる。接続サーバ１０４ａは、必要ならば複数のレジストリに同時に接続することができる。任意のレジストリサーバ１０６ａ、１０６ｂ、１０６ｃが、任意のデータベース１０７ａ、１０７ｂ、１０７ｃにアクセスすることができる。レジストリは、必要ならば複数のデータベースに同時に接続することができる。任意のレジストリサーバが、任意の接続サーバに接続することができる（上述のようにメッセージ回送のため）。

「接続」、「レジストリ」、及び「データベース」は、上では、システムの論理的コンポーネントとして使用されており、単一の物理的サーバ上に配備される場合も、配備されない場合もあるか、又は一連のハードウェア上に配備することもできる。一般に、容量要件は、所望のシステムの物理的レイアウトを決定付ける。

本発明の経路指定プロセスでは、特定のデータベース管理システム又は方法への依存は不要である。しかし、本発明の一実施形態では、このプロセスは、以下でさらに詳しく説明される、データベースのシャーディング及びレプリケーションの組合せを利用することができる。

「シャード（ｓｈａｒｄ）」は、本明細書では、複数の個別にインストールされたデータストレージバックエンド上に大量のデータを分散させる方法を表す、「データベースパーティション」を指すために使用される。「データストレージバックエンド」は、本明細書では、ＲＤＢＭＳ（リレーショナルデータベース管理システム）を実行する特定のサーバを指すために通常使用されるが、これは、必ずしもそうではなく、本明細書では、データを格納するいかなる方法も許容される。

図４に示されているように、共有環境では、レジストリサーバ１０６ａは、与えられたアクションに対する正しいデータ格納先を常に決定し、適切なシャードに対しオペレーションを実行する必要がある。例えば、要求されるシャードがシャード「２番」である場合、レジストリサーバ１０６ａは、シャードがデータベース１０７ａ内に格納されていると判定する。次いで、レジストリサーバ１０６ａは、データベース１０７ａからシャードを取り出し、必要なアクションを実行する。要求されるシャードがシャード「１番」であり、オペレーションがリードオペレーションである場合、レジストリサーバ１０６ａは、データベース１０７ｂ、１０７ｃのいずれかが関係するシャードを含んでいると判定し、要求されるシャードが「１番」であるが、オペレーションがライトオペレーション（データの追加又は修正）である場合、レジストリサーバ１０６ａは、データベース１０７ｂを選択する（レプリケーションがマスター−スレーブタイプであると仮定する）。シャードの選択は、シャードが分散される３つの別々のデータベースへのアクセスに関して説明されているが、当業者であれば、複数の位置を含む単一のデータベースを利用できることを理解するであろう。

上で述べたように、大きなデータベースを、データベース内のレコード毎に、多数のシャード（又は「パーティション」）上にパーティション分割することができ、シャーディングアルゴリズムが、どのパーティションがそのレコードを所有するかを決定する。シャーディングアルゴリズムは、さまざまな方法で実装することができ、ここでもまた、ふさわしいアルゴリズムは、拡張性要件によって規定されるべきである。シャーディングアルゴリズムに対する一般的ガイドラインは以下の通りとすることができる。

・システム内の特定のユーザアカウントに関係するデータについて、最初に、このユーザアカウントに対する一意的な識別子（「ユーザｉｄ」）を決定する。

・適当なハッシュ関数を使用してユーザｉｄのハッシュを計算する（「ハッシュ」は、コンピュータ関係で使用される専門用語であり、文字列の数値表現を指すために使用されることが多く、「ハッシュ関数」は、この表現を与える特定のアルゴリズムを決定する関数である）。これにより、それ自体数値である場合も数値でない場合もある、ユーザｉｄの数値表現が与えられる。

・ハッシュ数をシャードを割り振るステップの基礎として使用する。利用可能なシャードの数が知られている場合、値は、単純除算を行い、剰余を求めることで簡単に得られる。例えば、次の通りである。
１．システムが８つのデータベースシャードを持つとする。
２．ハッシュ（ｕｓｅｒｉｄ）＝８４５２９８２３
３．このｕｓｅｒｉｄレコードを所有するデータベースシャード数は、８４５２９８２３ ％ ８＝７とすることができる（表記「ａ ％ ｂ」は、ここでは、除算「ａ／ｂ」を実行し、次いで、計算結果の剰余を取り出すことを意味する）
４．この場合、データベースシャードは、シャード数７となる。

シャーディングアルゴリズムに加えて、レジストリサーバ１０６ａ、１０６ｂ、１０６ｃが与えられたシャードにどのように到達するかを決定するためにシステム内に他のメカニズムが必要である。読み出し及び書き込みのオペレーションがマスター−スレーブ構成でデータベースレプリケーションに対応できるように異なるメカニズムを構成することができる（１つの物理的サーバにのみ書き込むことができるが、リードオペレーションについては複数のサーバにアクセスすることができる）。

シャードを配置するためのこのメカニズムは、レジストリサーバ１０６ａ内の単純な構成テーブルを介して実行することができ、その際に、それぞれのシャードインデックスは、与えられたシャードに対するデータベースノードとして動作することができるサーバの（ＩＰ）アドレスで構成される。これらのアドレスは、任意に与えられた時点においてデータベース要件が与えられた場合にレジストリがどこに接続するかを認識するように「リード」及び／又は「ライト」フラグを介してタグ付けすることができる。

上記の実施形態は、本発明の例示によってのみ提示されており、またそれに対するさらなる修正及び改善は、当業者には明らかなように、本明細書で説明されている本発明の広い範囲及び分野内に収まるとみなされることは理解されるであろう。

Claims (16)

1. 通信ネットワークにおいてメッセージの経路指定を行うためのシステムであって、
   対象受信者に配送されるパケットを受信するための複数のノードを備え、
   前記対象受信者が前記複数のノード内の第１の選択されたノードに接続されているかどうかを判定し、前記対象受信者が前記第１の選択されたノードに接続されている場合に前記パケットを配送するように構成され、
   前記対象受信者が前記複数のノード内の前記第１の選択されたノードに接続されていないと判定された場合には、前記対象受信者が前記複数のノードのうちのどのノードに接続されているかを判定し、前記対象受信者が接続されているノードに前記パケットを回送するようにさらに構成されている、システム。
2. 前記複数のノードのうちのそれぞれのノードが、互いに結合された複数のサーバを含む、請求項１に記載のシステム。
3. それぞれのノードが、前記複数のサーバのうちの第１のサーバを含み、前記第１のサーバは前記対象受信者が前記ノード上の前記複数のサーバの中の少なくとも１つのサーバに接続されているかどうかを判定するように構成されている、請求項２に記載のシステム。
4. 前記複数のサーバのうちの前記第１のサーバが、前記パケットの経路指定先となるノードの宛先アドレスを含んでいるかどうかを判定するように構成されている、請求項３に記載のシステム。
5. 前記複数のサーバのうちの前記第１のサーバが、前記パケットを前記所望の宛先に回送すると前記パケット内の前記経路指定情報をクリアするように構成されている、請求項２〜４のいずれか一項に記載のシステム。
6. 前記対象受信者の前記ロケーションを決定することができない場合に前記パケットをレジストリに回送するように構成されている、請求項１に記載のシステム。
7. 前記レジストリが、互いに結合された複数のサーバを含む請求項６に記載のシステム。
8. 前記レジストリが、前記対象受信者の接続先だった最後のノードのロケーションに関する情報を少なくとも１つのデータベースから読み出すように構成されている第１のサーバを含む、請求項７に記載のシステム。
9. 前記レジストリが、前記パケットを前記対象受信者の前記最後の知られているロケーションに回送するように構成されている、請求項８に記載のシステム。
10. 前記複数のサーバが、それぞれのノード内で同じ物理的ロケーションを占有する請求項２〜５のいずれか一項に記載のシステム。
11. 前記複数のサーバが、それぞれのレジストリ内で同じ物理的ロケーションを占有する、請求項７〜９のいずれか一項に記載のシステム。
12. 前記パケットは、メッセージパケット、情報パケット、又はプレゼンスパケットというパケットクラスのうちの少なくとも１つから選択される、請求項１〜１１のいずれか一項に記載のシステム。
13. 通信システムにおいてメッセージの経路指定を行うための方法であって、
    対象受信者に対する１つのパケットを複数のノードのうちの第１のノードにおいて受信するステップと、
    前記対象受信者が前記第１のノードに接続されているかどうかを判定し、前記対象受信者が前記第１のノードに接続されている場合に前記パケットを前記対象受信者に配送し、前記対象受信者が前記第１のノードに接続されていない場合には、前記対象受信者が前記複数のノードのうちのどのノードに接続されているかを判定し、前記対象受信者が接続されている前記ノードに前記パケットを回送するステップと
    を含む方法。
14. 前記対象受信者の前記ロケーションが決定することができない場合に前記パケットをレジストリに回送するステップをさらに含む、請求項１３に記載の方法。
15. 前記レジストリが、１つ又は複数のデータベースに問い合わせて、前記対象受信者の接続先だった最後のノードのロケーションに関する情報を取り出すように構成されている、請求項１４に記載の方法。
16. 前記パケットを前記対象受信者の接続先だった前記最後のノードに回送するステップをさらに含む、請求項１５に記載の方法。

Images