ユーザーとプレゼンスの独自の概念を持つ別のシステムを使用している場合、XMPP サーバー ネットワークへのブリッジを作成するための最も適切なアーキテクチャは何ですか? 私が知る限り、主な方法は次の 3 つです。
サーバーとして機能します。これにより 1 つのタッチポイントが作成されますが、互換性に影響があり、サーバーをエミュレートするシステムが複雑になる可能性があるのではないかと心配しています。
クライアントとして行動します。これは、システム内のユーザーごとに 1 つの接続が必要であることを意味しているように思われますが、これではうまくスケーリングできません。
XMPP ゲートウェイ プロトコルについて聞いたことがありますが、これがクライアント ソリューションより優れているかどうかは不明です。これが標準かどうかもわかりません。
任意の提案やトレードオフをいただければ幸いです。たとえば、これらのソリューションのいずれかを実行するには、ターゲット XMPP サーバー内でコードを実行する必要があります (私ができることではない可能性があります)。
聞いたことのある XMPP ゲートウェイ プロトコルは、トランスポートに関係する可能性が最も高いです。トランスポートは、XMPP サーバーと非 XMPP サーバーの両方に接続するサーバーです。トランスポートを実行することで、Jabber クライアントを使用して、たとえば MSN Messenger を使用している人と話すことができます。
通常、トランスポートは、オンラインと見なされる JID ごとにリモート ネットワークに 1 回接続します。つまり、逆のオプション 2 です。これは、トランスポートと非 XMPP ネットワークの間に特別な関係がないためです。トランスポートは、通常のクライアントの集まりとして機能しているだけです。これを機能させるには、まず XMPP クライアントをトランスポートに登録して、リモート ネットワークのログイン資格情報を提供し、トランスポートがその存在を表示できるようにする必要があります。
これによりスケーリングが改善される可能性がある唯一の理由は、同じリモート ネットワークに対して多数のトランスポートが存在する可能性があるためです。たとえば、私の Jabber サーバーは MSN へのトランスポートを実行し、別の Jabber サーバーは別の Jabber サーバーを実行することができ、それぞれが XMPP ユーザーの異なるサブセットに接続を提供します。これにより Jabber 側の負荷が分散され、システムの負荷分散によっても負荷が分散される可能性がありますが、それでも 2 つのシステム間に多くの接続が必要です。
あなたの場合、(私が思うに) 非 XMPP 側が協力しているため、XMPP サーバー インターフェイスを非 XMPP サーバーに配置するのが最善の策です。このサーバー インターフェイスは、XMPP ユーザーに登録などを強制するのではなく、XMPP JID 間のマッピングと、その JID が独自のネットワークでどのように表示されるかを管理するのに最適です。
これらを見たことがない場合は、役に立つかもしれません。
それが役立つことを願っています。
どのアーキテクチャを使用する必要があるかは、非 XMPP システムによって異なります。
非 XMPP システムを運用していますか? はいの場合、そのシステムに XMPP-S2S インターフェイスを追加する方法を見つける必要があります。つまり、XMPP サーバーとして機能させる必要があります。AOL は、このアプローチを AIM に使用しています。残念ながら、ゲートウェイは GoogleTalk に制限されています。
非 XMPP システムは操作しませんが、フェデレーション インターフェイスを使用できます。つまり、ゲートウェイはサーバーとして他のシステムと通信でき、独自の名前空間を持ちます。この場合、両側で連合サーバーとして機能するゲートウェイを構築できます。このアプローチを使用するゲートウェイの例を私は知りませんが、パブリック XMPP-to-SIP ブリッジを構築する場合に使用できます。
XMPP 以外のシステムでフェデレーション インターフェイスが提供されない場合は、多数のクライアントとして機能する以外に選択肢はありません。XMPP の世界では、これを「トランスポート」と呼びます。トランスポートと通常のサーバーの基本的な違いは次のとおりです。
私も同様のシステムに取り組んでいます。
ゲートウェイ/コンポーネント ルートを使用します。いくつかのオプションを検討しましたが、これに落ち着きました。
ゲートウェイは基本的に、Jabber/XMPP を別のネットワークにブリッジするという特定の目的を持つコンポーネントです。XMPP をクライアントとして使用する場合、当然のことと思われるもののほとんどを構築する必要があります。名簿管理のようなもの。
コンポーネントの実際の設計と構築に関するオンラインのヘルプはほとんどありません。上記の回答のように、xmpp プロトコル/拡張機能が役立つことがわかりました。主なものは次のとおりです。
これらを読むと、処理できると予想される XEP がわかります。コンポーネントが接続されるサーバーによって処理されるものは無視してください。
「すべてがモジュールである」という彼らのシステムが、サーバーのバックエンドが他のネットワークに直接インターフェースできる可能性を与えたため、Djabberd の文書が貧弱であることは残念です。私はこれについて前進しませんでした。
基本的に、サーバー間 (s2s) 接続には 2 つのタイプがあります。最初のものはゲートウェイまたはトランスポートと呼ばれますが、同じものです。これはおそらくあなたが探している種類です。非 XMPP 側の特定のドキュメントは見つかりませんでしたが、XMPP がレガシー サーバーへの変換をどのように考えているかについては、 http: //xmpp.org/extensions/xep-0100.htmlを参照してください。2 番目の種類は、追加の XEP では実際には説明されていません。通常の XMPP s2s 接続です。最新のドラフト更新については、RFC 3920 または RFC 3920bis で「Server-to-Server Communication」を探してください。
サーバーには独自のユーザーとプレゼンスがあり、それは XMPP ではないため、概念は XMPP モデルに完全には対応しません。ここで、トランスポートの作業が行われます。モデルから XMPP モデルへの変換を行う必要があります。これは多少の作業ですが、すべての決定を行う必要があります。
これにより、重要な設計上の選択肢の 1 つにたどり着きます。サービスから XMPP にマッピングするものとそうでないものを実際に決定する必要があります。これらの機能とユースケースの説明は、全体的な構造を推進します。たとえば、これは AOL または MSN チャット サービスと通信するためのトランスポートのようなものですか? 次に、ロスター、プレゼンス、キープ セッション情報に相当するものを、ローカル ユーザーからのログインとパスワードとともにリモート サーバーにマップする方法が必要になります。これは、トランスポートがそれらのユーザーのふりをする必要があり、ログインする必要があるためです。
または、他の誰かの XMPP ベースのチェス ゲームへの s2s ブリッジにすぎないので、リモート サーバーにログインする必要がなく、電子メール サーバーと同じように動作して、情報をやり取りすることができます。(通常の s2s 接続では、保存される唯一のセッションは、リモート サーバーで使用される SASL 認証になりますが、ユーザー レベルでは、s2s は接続を維持するだけで、ログイン セッションは維持しません。)
その他の要因は、スケーラビリティとモジュール性です。スケーラビリティに関する懸念事項のいくつかを解決しました。複数のトランスポートを配置して負荷のバランスを取ることを検討してください。モジュール性については、各パケットまたはアクションで何をするかについて決定を下す場所を確認してください。たとえば、サブスクリプション データをどのように処理し、追跡していますか? トランスポートに入れることはできますが、そうすると複数のトランスポートを使用することが難しくなります。または、コアサーバーの近くでその決定を下すと、XMPP 以外のサービスと通信する必要がある場合に、より単純なトランスポートを使用して共通のコードを使用できます。トレードオフは、脆弱性の可能性が高い、より複雑なコア サーバーです。
もう 1 つの方法は、XMPP サーバー ベンダーと連携することです。ほとんどの場合、サードパーティ アプリケーションからのプレゼンスの挿入を可能にする内部 API があります。たとえば、Jabber XCPは、このための非常に使いやすい API を提供します。
(開示: 私は、Jabber XCP の背後にある会社である Jabber, Inc で働いています)