XEP-0289 から一部の機能を差し引いた行に分散型 XMPP MuC アプリケーションを実装する必要があります。本質的には、プラグインの必要最小限の実装が必要です。私の懸念はフォールト トレランスに対処することであり、現在はそうしています。 289で指定されているパフォーマンスの考慮事項について心配したくありません.サーバー側プラグインを開発するツールとしてSleekXmppを調べましたが、そのような実装に使用するのがどれほど快適かわかりません.他のオプションを調べましたで OpenFire 、 Tigase です。私は Python/Java に慣れており、考慮すべきその他の重要な機能は、優れたドキュメント、使いやすさなどであることを念頭に置いて、この開発にどのようなパスを採用するのが望ましいかを知りたいと考えています。任意のガイダンスをいただければ幸いです。
1 に答える
2
FMUC (または同様のもの) を含む MUC コンポーネントを作成できるはずです。これを行う一般的な方法は、XEP-0114 コンポーネント (SleekXMPP (Python)、Swiften (C++) など) をサポートするライブラリを使用し、それを介して MUC+FMUC を実装することです。あなたは SleekXMPP に関する懸念を述べていませんが、XMPP コミュニティではかなり尊敬されているライブラリであるため、適切な選択のようです (私は Swiften を選びますが、著者の 1 人として偏見があります)。
2 番目のオプション (サーバーに直接パッチを適用する) は、一般に、カスタマイズを追加する XMPP 的な方法ではありません (ベンダー固有であるため) が、サーバー コードに十分に精通した人を見つけることができる場合、または喜んでそうする場合にも機能するはずです。そうなる。
耐障害性を実現するには (サーバー障害に対する回復力を意味すると仮定して)、XMPP サーバーをクラスター化して実行し、FMUC 実装もクラスター化する必要があります。これが完了すると、DNS で SRV レコードを使用する通常の XMPP フェールオーバーにより、他のサーバーが別のホストへの接続を再試行することが保証されます。
余談ですが、FMUC (XEP-0289) の次のバージョンでは、現在のリビジョンの機能の一部が取り除かれ、展開の経験に基づいて多くの改善が行われます。公開されたら読んでいただけると助かります。また、FMUC の少なくとも 1 つの実装 (私が取り組んでいる Isode の M-Link) が既に存在し、他のベンダーからの関心もあることに注意してください。 .
于 2014-08-26T14:01:01.553 に答える