XMPP 网络聊天：如何解决多个选项卡/窗口？答案

【问题标题】：XMPP web chat: how to resolve multiple tabs/windows?XMPP 网络聊天：如何解决多个选项卡/窗口？
【发布时间】：2011-05-01 05:20:41
【问题描述】：

我们有一个站点，我们使用 strophe.js 库和 ejabberd XMPP 服务器为其开发了一个聊天系统。我们使用由 PHP 启动的会话附件（使用内部库）。我们所做的是从 PHP 脚本中获取 RID 和 SID，然后使用 strophe 的会话附件。所述 RID 和 SID 存储在 cookie 上，并且每次更新 strophe.js 上的 RID 时都会更新 cookie 上的 RID 值。（这样我们就可以在页面刷新/导航到站点上的其他位置时重用会话 ID）

我们现在计划让它在多个选项卡/窗口上运行。我观察了 Facebook 的实现，每个选项卡都有一个对某个域的长轮询请求。这个域对于每个选项卡都是不同的。例如，第一个标签是 0.86.channel.facebook.com。第二个标签是 1.86.channel.facebook.com。据我了解，这是为了解决浏览器对某个域的 2 个活动请求的限制。这个多域解决方案是如何实现的？

接下来是聊天会话本身。每个标签的聊天会话会有所不同，对吗？ UI 如何与 Facebook 等每个标签同步？我的想法是，每个操作都会向用户自己的 JID 发送一条消息，其中包含与聊天相关的操作。例如，打开聊天窗口会发送如下消息节：

<message from="my_own_jid" to="my_own_jid" type="chat">
    <body>{"jid-of-contact":"open-chat-box"}</body>
</message>

这将在聊天客户端上捕获，并且 UI 将相应调整（在这种情况下，为联系人打开一个聊天框）。

关于这个实现有什么建议/cmets？

谢谢！

【问题讨论】：

在多域上：不同的域可能只是将来自不同域的请求重新路由回它们使用的 XMPP 服务器。它可能只是浏览器端的“伪装”。关于如何在单个用户名下登录到相同的资源，嗯，我想知道 FB 是否已经实现/修改了他们用来实现这一点的 XMPP 服务器。知道会很有趣。
关于跨多个选项卡维护 UI 的外观和感觉：我想知道您是否可以使用 HTML5 的数据存储来维护聊天的“状态”，并让每个选项卡...数据存储？根据 XMPP 规范，您应该能够使用资源优先级来“控制”消息节将发送到的位置。想知道您是否可以利用它来实现多标签效果...
@DashK他们登录的是同一个资源吗？我认为这是一个不同的会话，每个会话都有不同的资源。这样就不需要修改 XMPP 服务器（并且使用相同资源为同一个用户进行多次登录是违反 XMPP 标准的，对吧？）。
在 HTML5 数据存储中，恐怕我无法实现它，直到它在不同的浏览器中正确实现（最后我检查了只有基于 Webkit 的浏览器完全支持这一点）。关于资源优先级，您是在谈论 XEP-0168 吗？我略读了一下，开始看到它在多标签聊天环境中的可能用途，但我在这里仍然一无所知。
@mives - 我不确定 FB 的 XMPP 是如何实现的。如果他们在所有不同的浏览器会话中使用完全相同的资源登录，那么他们需要有自定义代码来支持它。

标签： xmpp chat strophe

【解决方案1】：

我和我的团队正在解决完全相同的问题 - 只是我们使用 Openfire 而不是 Ejabberd（主要是因为我们有 Java 技能但不熟悉 Erlang）。我们公司正在开发浏览器游戏。

我们的解决方案包括：

XMPPHP - 用于预绑定
Strophe.js - 用于会话附加（修改）
旁遮普 - 作为连接管理器（扩展、修改）
Openfire - 作为 XMPP 服务器

我们使用旁遮普语，因为一开始 Openfire 的 BOSH 实现似乎不能很好地与其他组件配合使用。

基本上我们决定不为每个标签创建会话。这是因为我们的一些游戏的运行方式与通常的网站一样：单击链接将请求一个完整的新页面（而较新的游戏完全在 ajax 中运行，并且大部分 GUI 保持不变）。换句话说：我们基于网络的聊天必须在用户“在网站上移动”的环境中工作。一个标签的一个会话意味着每个页面请求的一个新会话，这似乎是一个巨大的开销，因为玩家经常点击很快。所以 - 我们希望创建一个会话并坚持一个玩家。

为了解决这个问题，我们 - 像您一样 - 修改了 strophe.js 以在 cookie 中读取/保存 RID，因此所有选项卡都知道当前的 RID 并递增到正确的值。另一件事是，我们让 Strophe 在 XMPP 节的正文中添加了一个 CID。 CID 类似于客户 ID。我会尽快解释使用..

接下来的计划是修改旁遮普语中的两件事。首先，我们添加了一个类来替代在 punjab 中存储等待请求的通常方式。等待的 BOSH 请求现在以 CID（strophe.js 现在添加到每个请求的正文中）作为键保存在字典中。当来自同一选项卡的另一个请求到达旁遮普语时，就会知道要向哪个等待请求发送空答案。如果有新的节要传递，旁遮普将把这些发送到字典中的所有等待请求。因此，传入消息将分发到所有选项卡。其次，我们添加了几行，以便从一个选项卡发送的消息立即“返回”到所有其他选项卡。所以消息也可以出现在其他标签历史记录中。

当然还有其他问题必须面对，比如当玩家进入下一个屏幕时，不会丢失 GUI 中的聊天历史记录。将其存储在 cookie 中会很糟糕，因为所有这些内容都会随每个请求一起发送出去，并会导致大量流量。为此，我们考虑实现类似于 XEP-0136 消息归档的东西。

简而言之，我们必须处理修补/扩展 strophe.js 和 punjab 的问题，并且我们正在稍微修改标准。但目前它运行良好，我很高兴看到此设置在测试版中的效果。

【讨论】：

我很好奇，Beta 版的进展如何？我问是因为我即将着手实施类似的解决方案。
你在github上对strophe/punjab的修改是偶然的吗？
我也很好奇这个。你能分享一下你对 Strophe 和 Punjab 所做的修改吗？

【解决方案2】：

我的解决方案：

每个选项卡在不同的资源上都有自己的连接，所有资源都具有优先级 1。

在 openfire 添加服务器变量route.all-resources: true
消息将被广播到所有资源。

【讨论】：