桥接到 XMPP 的最佳架构是什么？

Question

如果我有一个单独的系统，有自己的用户和状态概念，那么创建 XMPP 服务器网络桥接的最合适的架构是什么？据我所知，主要有以下三种方式：

1. 充当服务器。这会创建一个接触点，但我担心它会对兼容性产生影响，并且可能会在我的模拟服务器系统中造成复杂性。

2. 充当客户。这似乎意味着我的系统中每个用户都需要一个连接，这无法很好地扩展。

3. 我听说过 XMPP 网关协议，但不清楚这是否比客户端解决方案更好。我也无法判断这是否是标准的。

任何建议或权衡将不胜感激。例如，这些解决方案中的任何一个都需要在目标 XMPP 服务器内运行代码（我不太可能做）。

Answer 1

您听说过的 XMPP 网关协议很可能与传输有关。传输是连接到 XMPP 服务器和非 XMPP 服务器的服务器。通过运行传输，我可以使用 Jabber 客户端与使用 MSN Messenger 等工具的人交谈。

传输通常会为其视为在线的每个 JID 连接一次到远程网络。也就是说，它是你的选项2的相反。这是因为传输和非XMPP网络之间没有特殊的关系；运输只是充当一群常客。为此，XMPP 客户端必须首先向传输注册，提供远程网络的登录凭据，并允许传输查看其存在。

这有可能更好地扩展的唯一原因是同一远程网络可以有许多传输。例如，我的 Jabber 服务器可以运行到 MSN 的传输，另一台 Jabber 服务器可以运行另一个，依此类推，每个服务器都为不同的 XMPP 用户子集提供连接。虽然这会分散 Jabber 端的负载，并且系统上的负载平衡也可能会分散负载，但两个系统之间仍然需要许多连接。

就您而言，因为（我假设）非 XMPP 方面正在合作，所以将 XMPP 服务器接口放在非 XMPP 服务器上可能是您的最佳选择。该服务器接口最适合管理 XMPP JID 之间的映射以及 JID 在其自己的网络上的显示方式，而不是强制 XMPP 用户注册等。

如果您还没有看过这些，您可能会发现它们很有用：

• http://www.jabber.org/jabber-for-geeks/technology-overview
• http://www.xmpp.org/protocols/
• http://www.xmpp.org/extensions/

希望有帮助。

Answer 2

我也在开发类似的系统。

我将使用网关/组件路线。我研究了几种选择并最终选择了这个。

网关基本上是一个组件，其特定目的是将 Jabber/XMPP 与另一个网络桥接。当使用 XMPP 作为客户端时，您将必须构建大部分您认为理所当然的东西。像名册控制之类的东西。

关于组件的实际设计和构建的在线帮助非常少。就像上面的答案一样，我发现 xmpp 协议/扩展很有帮助。主要有：

• 基本客户端2008
• 基本服务器2008
• 中级客户 2008
• 中级服务器2008

通读这些内容将向您展示您预计能够处理哪些 XEP。忽略您的组件将附加到的服务器将处理的内容。

遗憾的是，Djabberd 的文档如此糟糕，因为他们的“一切都是模块”系统使服务器后端可以直接连接到其他网络。我在这方面没有取得任何进展。

Answer 3

服务器到服务器 (s2) 连接基本上有两种类型。第一个称为网关或传输，但它们是同一件事。这可能就是您正在寻找的类型。我找不到非 XMPP 方面的具体文档，但 XMPP 如何考虑对旧服务器进行转换位于 http://xmpp.org/extensions/xep-0100.html. 。第二种确实没有在任何额外的 XEP 中进行解释——它是常规的 XMPP s2s 连接。在 RFC 3920 或 RFC 3920bis 中查找“服务器到服务器通信”以获取最新的草稿更新。

由于您在服务器上拥有自己的用户和存在，并且它不是 XMPP，因此这些概念不会完全映射到 XMPP 模型。这就是运输工作发挥作用的地方。您必须将您的模型转换为 XMPP 模型。虽然这是一些工作，但您确实可以做出所有决定。

这给我们带来了关键的设计选择之一——您需要真正决定哪些内容要从您的服务映射到 XMPP，哪些内容不映射。这些功能和用例描述将驱动整体结构。例如，这是否类似于与 AOL 或 MSN 聊天服务交谈的交通工具？然后，您需要一种方法来映射相应的名册、状态，并将会话信息以及本地用户的登录名和密码保存到远程服务器。这是因为您的交通工具需要假装是这些用户，并且需要为他们登录。

或者，也许您只是通往其他人基于 XMPP 的国际象棋游戏的 s2s 桥梁，因此您不需要登录远程服务器，只需像电子邮件服务器一样操作并来回传递信息。（对于普通的 s2s 连接，存储的唯一会话将是与远程服务器一起使用的 SASL 身份验证，但在用户级别 s2s 仅维护连接，而不是登录会话。）

其他因素包括您的可扩展性和模块化。您解决了一些可扩展性问题。考虑一下放置多个传输来平衡负载。对于模块化，请查看您想要在哪里做出有关如何处理每个数据包或操作的决策。例如，您如何处理和跟踪订阅数据？您可以将其放在您的交通工具上，但这会使使用多种交通工具变得更加困难。或者，如果您做出的决定更接近您的核心服务器，那么如果您需要与 XMPP 以外的服务进行通信，则可以使用更简单的传输并使用一些通用代码。代价是核心服务器更加复杂，潜在的漏洞也更多。

Answer 4

您应该使用什么架构取决于非 XMPP 系统。

1. 您是否运行非 XMPP 系统？如果是，您应该找到一种方法向该系统添加 XMPP-S2S 接口，换句话说，使其充当 XMPP 服务器。AOL 正在将这种方法用于 AIM。不幸的是，他们限制了 GoogleTalk 的网关。

2. 您不操作非 XMPP 系统，但它有一个您可以使用的联合接口 - i。e.您的网关可以与其他系统通信 作为服务器 并且有自己的命名空间。在这种情况下，您可以构建一个网关，充当两侧的联合服务器。因为我不知道有任何使用此方法的网关示例，但如果您想构建公共 XMPP 到 SIP 桥接，则可以使用它。

3. 如果非 XMPP 系统没有为您提供联合接口，那么您除了充当一群客户端之外别无选择。在 XMPP 世界中，这称为“传输”。传输服务器和普通服务器之间的区别基本上是：

   • 传输的 JID 是从另一个系统映射的（例如john.doe\40example.net@msngateway.example.org - 真的很难看！）
   • 想要使用传输的 XMPP 用户需要在非 XMPP 系统上创建一个帐户，并将该帐户的登录凭据提供给传输服务。XMPP 协议甚至有一个协议扩展，允许 XMPP 用户进行带内传输注册。

Answer 5

另一种方法是与 XMPP 服务器供应商合作。大多数都有内部 API，可以从第三方应用程序进行注入。例如， 贾伯XCP 为此提供了一个非常易于使用的 API。

（披露：我在 Jabber, Inc 工作，该公司是 Jabber XCP 背后的公司）