xmpp ejabberd 中的实时数据流
Real time data streaming in xmpp ejabberd
我正在配置一个 ejabberd xmpp 服务器用于远程实时图形数据流。实现成功，但是现在出现了很多性能问题。
我的要求是通过 ejabberd-xmpp 每分钟向移动网络发送大约 3000 条消息，并在桌面应用程序中接收它，没有任何延迟。
我已将 ejabberd.yml 配置文件中的 traffic_shapers 更改为非常大的值，并修改了许多其他流量限制，但在测试时桌面端发生了大量缓冲在低带宽。
那么，如果我确定我的配置是正确的，应该使用哪些扩展？在我研究的过程中，我发现以下 XEP 可以提供帮助：
流压缩(XEP-138)
Jingle ICE-UDP 传输方法(XEP-176)
基于同步 HTTP 的双向流 (BOSH)(XEP-124)
基于 BOSH 的 XMPP(XEP-206)
流管理(XEP-198)
但是所有的研究只是增加了疑惑的数量：
如果我要实施这些 XEP 中的任何一个，那么必须对配置进行哪些更改？
我将如何相应地更改我的 XML 节？ XEP 文档对于新手来说出奇地不够用。
流管理和流压缩有什么区别？
BOSH 上的 XMPP 和同步 HTTP 上的双向流有什么区别？
如何实现BOSH？我现在使用端口号 5222，如果我使用端口号 5280，我的项目会有什么变化？我应该在哪里反映这些变化？
如果我要组合任何两个扩展程序，它只会增加速度问题还是对我有利？
请问有人能帮忙吗？我确实意识到这个问题不在可以发布在这个网站上的问题范围内，而且正如指南所指定的那样，'out of scope' 和 'off topic'。但任何帮助将不胜感激。提前致谢！
根据您的描述，带宽似乎是问题所在。那么，流压缩应该是有用的。在这种情况下，其他 XEP 将无济于事。
关于使用流压缩的提示：当使用流压缩时，不要忘记启用它后，所有数据都被压缩发送，并且在传递给 XML 解析器之前必须解压缩。
问题出在 Ejabberd 之后的协商顺序上。 Ejabberd 按照以下顺序进行流协商：
-TLS
-流压缩
-SASL
-资源绑定
而所有其他客户端和库都遵循流协商的推荐顺序 XEP-170:
-TLS
-SASL
-流压缩
-资源绑定
这导致 <compress> 请求在 SASL 加密后被 ejabberd 服务器完全忽略。由于 XEP-170 是由 XMPP 文档关键字 RECOMMENDED 而不是 REQUIRED 标识的，因此没有严格执行
尽管支持的协议 here specify that XEP-170 is followed, but I feel that the issue from this link 表示 "ejabberd 1.1.2: It only accepts compression before SASL (XEP-0138)" 仍未修复
（使用 OpenFire 3.10、XIFF AS3 库和 Seesmic-XMPP AS3 库测试了相同的场景，并且自 OpenFire 以来一直在进行压缩允许在 SASL 加密之前或之后进行压缩）
我正在配置一个 ejabberd xmpp 服务器用于远程实时图形数据流。实现成功，但是现在出现了很多性能问题。
我的要求是通过 ejabberd-xmpp 每分钟向移动网络发送大约 3000 条消息，并在桌面应用程序中接收它，没有任何延迟。
我已将 ejabberd.yml 配置文件中的 traffic_shapers 更改为非常大的值，并修改了许多其他流量限制，但在测试时桌面端发生了大量缓冲在低带宽。
那么，如果我确定我的配置是正确的，应该使用哪些扩展？在我研究的过程中，我发现以下 XEP 可以提供帮助：
- 流压缩(XEP-138)
- Jingle ICE-UDP 传输方法(XEP-176)
- 基于同步 HTTP 的双向流 (BOSH)(XEP-124)
- 基于 BOSH 的 XMPP(XEP-206)
- 流管理(XEP-198)
但是所有的研究只是增加了疑惑的数量：
- 如果我要实施这些 XEP 中的任何一个，那么必须对配置进行哪些更改？
- 我将如何相应地更改我的 XML 节？ XEP 文档对于新手来说出奇地不够用。
- 流管理和流压缩有什么区别？
- BOSH 上的 XMPP 和同步 HTTP 上的双向流有什么区别？
- 如何实现BOSH？我现在使用端口号 5222，如果我使用端口号 5280，我的项目会有什么变化？我应该在哪里反映这些变化？
- 如果我要组合任何两个扩展程序，它只会增加速度问题还是对我有利？
请问有人能帮忙吗？我确实意识到这个问题不在可以发布在这个网站上的问题范围内，而且正如指南所指定的那样，'out of scope' 和 'off topic'。但任何帮助将不胜感激。提前致谢！
根据您的描述，带宽似乎是问题所在。那么，流压缩应该是有用的。在这种情况下，其他 XEP 将无济于事。
关于使用流压缩的提示：当使用流压缩时，不要忘记启用它后，所有数据都被压缩发送，并且在传递给 XML 解析器之前必须解压缩。
问题出在 Ejabberd 之后的协商顺序上。 Ejabberd 按照以下顺序进行流协商：
-TLS
-流压缩
-SASL
-资源绑定
而所有其他客户端和库都遵循流协商的推荐顺序 XEP-170:
-TLS
-SASL
-流压缩
-资源绑定
这导致 <compress> 请求在 SASL 加密后被 ejabberd 服务器完全忽略。由于 XEP-170 是由 XMPP 文档关键字 RECOMMENDED 而不是 REQUIRED 标识的，因此没有严格执行
尽管支持的协议 here specify that XEP-170 is followed, but I feel that the issue from this link 表示 "ejabberd 1.1.2: It only accepts compression before SASL (XEP-0138)" 仍未修复
（使用 OpenFire 3.10、XIFF AS3 库和 Seesmic-XMPP AS3 库测试了相同的场景，并且自 OpenFire 以来一直在进行压缩允许在 SASL 加密之前或之后进行压缩）