質問

ユーザーとプレゼンスに関する独自の概念を持つ別のシステムがある場合、XMPP サーバー ネットワークへのブリッジを作成するための最も適切なアーキテクチャは何ですか?私の知る限り、主な方法は 3 つあります。

  1. サーバーとして機能します。これによりタッチポイントが 1 つ作成されますが、互換性に影響があり、サーバーをエミュレートするシステムが複雑になる可能性があるのではないかと心配しています。

  2. クライアントとして行動します。これは、システム内でユーザーごとに 1 つの接続が必要であることを意味しているようですが、これではうまく拡張できません。

  3. XMPP ゲートウェイ プロトコルについて聞いたことはありますが、これがクライアント ソリューションよりも優れているかどうかは不明です。これが標準かどうかもわかりません。

ご提案やトレードオフをいただければ幸いです。たとえば、これらのソリューションのいずれかで、ターゲット XMPP サーバー内でコードを実行する必要がありますか (私には実行できない可能性があります)。

役に立ちましたか?

解決

あなたが聞いたことのある XMPP ゲートウェイ プロトコルは、トランスポートに関連している可能性が最も高いです。トランスポートは、XMPP サーバーと非 XMPP サーバーの両方に接続するサーバーです。トランスポートを実行すると、Jabber クライアントを使用して、たとえば MSN Messenger を使用している誰かと会話できます。

通常、トランスポートは、オンラインとみなされる JID ごとにリモート ネットワークに 1 回接続します。つまり、逆の選択肢 2 になります。これは、トランスポートと非 XMPP ネットワークの間に特別な関係がないためです。トランスポートは単に通常のクライアントの束として機能します。これが機能するには、まず XMPP クライアントをトランスポートに登録し、リモート ネットワークのログイン資格情報を与え、トランスポートがクライアントの存在を表示できるようにする必要があります。

これにより拡張性が向上する可能性がある唯一の理由は、同じリモート ネットワークに多数のトランスポートが存在する可能性があるためです。たとえば、私の Jabber サーバーは MSN へのトランスポートを実行し、別の Jabber サーバーは別のトランスポートを実行するなど、それぞれが XMPP ユーザーの異なるサブセットに接続を提供することができます。これにより Jabber 側の負荷が分散され、システムの負荷分散によっても負荷が分散される可能性がありますが、それでも 2 つのシステム間に多くの接続が必要になります。

あなたの場合、非 XMPP 側が協力している (と思われる) ため、非 XMPP サーバーに XMPP サーバー インターフェイスを配置するのが最善の策と思われます。このサーバー インターフェイスは、XMPP ユーザーに登録などを強制するのではなく、XMPP JID 間のマッピングとその JID が独自のネットワーク上でどのように表示されるかを管理するのに最適です。

これらをまだ見ていない場合は、役に立つかもしれません。

それが役立つことを願っています。

他のヒント

私も同様のシステムに取り組んでいます。

私はゲートウェイ/コンポーネントルートを使用します。いくつかの選択肢を検討しましたが、これに落ち着きました。

ゲートウェイは基本的に、Jabber/XMPP を別のネットワークにブリッジするという特定の目的を持つコンポーネントです。XMPP をクライアントとして使用する場合、当然のことと考えられるもののほとんどを構築する必要があります。名簿管理のようなもの。

実際のコンポーネントの設計と構築に関するオンライン ヘルプはほとんどありません。上記の回答と同様に、xmpp プロトコル/拡張機能が役立つことがわかりました。主なものは次のとおりです。

これらを読むと、どの XEP を処理できることが期待されるかがわかります。コンポーネントが接続されるサーバーによって処理されるものは無視してください。

Djabberd のドキュメントが貧弱なのは残念です。Djabberd の「すべてがモジュール」システムでは、サーバーのバックエンドが他のネットワークに直接接続できる可能性があったためです。これに関しては何も進みませんでした。

サーバー間 (S2S) 接続には基本的に 2 つのタイプがあります。1 つ目はゲートウェイまたはトランスポートと呼ばれますが、それらは同じものです。これはおそらくあなたが探している種類のものです。非 XMPP 側に関する具体的なドキュメントは見つかりませんでしたが、XMPP がレガシー サーバーへの変換をどのように考えているかは次のとおりです。 http://xmpp.org/extensions/xep-0100.html. 。2 番目の種類については、追加の XEP では実際には説明されていません。これは通常の XMPP s2s 接続です。最新のドラフト更新については、RFC 3920 または RFC 3920bis で「サーバー間通信」を探してください。

サーバー上には独自のユーザーとプレゼンスがあり、XMPP ではないため、概念は XMPP モデルに完全には対応しません。ここで輸送の仕事が始まります。モデルから XMPP モデルへの変換を行う必要があります。これは多少の作業ではありますが、すべての決定はあなたが行う必要があります。

これにより、重要な設計上の選択の 1 つが決まります。サービスから XMPP にマッピングするものとそうでないものを実際に決定する必要があります。これらの機能と使用例の説明は、全体の構造を推進します。たとえば、これは AOL または MSN チャット サービスと会話するためのトランスポートのようなものですか?次に、それらに相当する名簿、プレゼンスをマッピングし、ローカル ユーザーからリモート サーバーへのログインとパスワードとともにセッション情報を保持する方法が必要になります。これは、トランスポートがそれらのユーザーのふりをし、ユーザーに代わってログインする必要があるためです。

あるいは、他の人の XMPP ベースのチェス ゲームへの単なる s2s ブリッジである可能性があるため、リモート サーバーにログインする必要はなく、電子メール サーバーと同様に動作して情報をやり取りするだけで済みます。(通常の s2s 接続では、保存される唯一のセッションはリモート サーバーで使用される SASL 認証ですが、ユーザー レベルでは s2s は接続を維持するだけであり、ログイン セッションは維持しません。)

その他の要素としては、ユーザー側のスケーラビリティとモジュール性があります。スケーラビリティに関する懸念のいくつかを解決しました。負荷のバランスをとるために複数のトランスポートを導入することを検討してください。モジュール性については、各パケットまたはアクションをどのように処理するかを決定する場所を確認してください。たとえば、サブスクリプション データをどのように処理し、追跡するのですか?トランスポートに置くこともできますが、そうすると複数のトランスポートを使用するのが難しくなります。あるいは、その決定をコア サーバーの近くで行うと、トランスポートがより単純になり、XMPP 以外のサービスと通信する必要がある場合に共通のコードを使用できます。その代償として、コア サーバーがより複雑になり、より多くの脆弱性が発生する可能性があります。

どのアーキテクチャを使用する必要があるかは、非 XMPP システムによって異なります。

  1. 非 XMPP システムを運用していますか?「はい」の場合は、そのシステムに XMPP-S2S インターフェイスを追加する方法、つまりシステムを XMPP サーバーとして機能させる方法を見つける必要があります。AOL は、AIM にこのアプローチを使用しています。残念ながら、ゲートウェイは GoogleTalk に制限されています。

  2. 非 XMPP システムは操作しませんが、使用できるフェデレーション インターフェイスがあります。e.ゲートウェイは他のシステムと通信できます サーバーとして 独自の名前空間を持っています。この場合、両側でフェデレーション サーバーとして機能するゲートウェイを構築できます。このアプローチを使用するゲートウェイの例を私は知りませんが、パブリック XMPP から SIP へのブリッジを構築したい場合にはこれを使用できる可能性があります。

  3. 非 XMPP システムでフェデレーション インターフェイスが提供されない場合は、多数のクライアントとして動作する以外に選択肢はありません。XMPP の世界では、これを「トランスポート」と呼びます。トランスポートサーバーと通常のサーバーの違いは基本的に次のとおりです。

    • トランスポートの JID は別のシステムからマッピングされます (例:john.doe\40example.net@msngateway.example.org - 本当に醜いです!)
    • トランスポートを使用したい XMPP ユーザーは、非 XMPP システムでアカウントを作成し、そのアカウントのログイン資格情報をトランスポート サービスに与える必要があります。XMPP プロトコルには、XMPP ユーザーが帯域内でトランスポート登録を実行できるようにするプロトコル拡張機能もあります。

もう 1 つのアプローチは、XMPP サーバー ベンダーと協力することです。ほとんどの製品には、サードパーティ アプリケーションからのプレゼンス注入を可能にする内部 API があります。例えば、 ジャバーXCP は、このための非常に使いやすい API を提供します。

(開示:私は Jabber XCP の背後にある会社、Jabber, Inc で働いています)

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top