基本上有两种类型的服务器到服务器 (s2s) 连接。第一个被称为网关或传输,但它们是相同的。这可能是您正在寻找的那种。我找不到非 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 以外的服务通信。权衡的是更复杂的核心服务器,具有更多的潜在漏洞。