xmpp ejabberd中的实时数据流
我正在配置一个ejabberd xmpp服务器，用于实时图形数据的远程流式传输。 实施是成功的，但现在很多性能问题正在出现。
我的要求是通过ejabberd-xmpp将每分钟约3000条消息发送到移动网络，并在桌面应用程序中接收，而不会有任何明显延迟。
我已将ejabberd.yml配置文件中的traffic_shapers更改为非常大的值，并修改了很多其他流量限制，但在低带宽下进行测试时，桌面端会发生大量缓冲。
所以，如果我确信我的配置是正确的，那么应该使用什么扩展？ 在我研究的时候，我发现以下XEP可以提供帮助：
数据流压缩（XEP-138） Jingle ICE-UDP传输方法（XEP-176） 基于同步HTTP（BOSH）（XEP-124）的双向流 XMPP （BEPH）但所有的研究只增加了一些疑虑：
如果我要实现这些XEP中的任何一个，那么对配置所做的所有更改都必须进行？ 我将如何相应地更改我的XML节？ 对于新秀来说，XEP文档令人惊讶地不足。 流管理和流压缩有什么区别？ XMPP Over BOSH和双向流同步HTTP之间有什么区别？ 如何实施BOSH？ 现在我正在使用端口号5222，如果我使用端口5280，那么对我的项目所做的所有更改都会发生？ 我应该在哪里反映这些变化？ 如果我要结合任何两个扩展名，它只会增加速度问题还是会对我有利？请有人帮忙吗？ 我确实意识到，这个问题已经超出了可以在本网站上发布的问题范围，并且也符合指南中的'超出范围'和'非主题'。 但任何帮助将非常感激。 提前致谢！
从你所描述的看来，带宽就是问题所在。 然后，流压缩应该是有用的。 其他XEP在这种情况下不会帮助你。
关于使用流压缩的提示：使用流压缩时，不要忘记，在启用它之后，所有数据都将发送压缩，并且在传递到XML解析器之前必须解压缩。
问题在于Ejabberd的谈判顺序。 Ejabberd按照以下顺序进行流式处理：
-TLS
流压缩
-SASL
资源绑定
而所有其他客户和图书馆都遵循XEP-170推荐订单：
-TLS
-SASL
流压缩
资源绑定
这导致SASL加密后ejabberd服务器完全忽略<compress>请求。 由于XEP-170是由XMPP文档关键字RECOMMENDED而不是REQUIRED标识的，因此没有严格的强制执行
虽然这里支持的协议指定遵循XEP-170，但是我认为从这个链接说出“ejabberd 1.1.2：它只在SASL（XEP-0138）之前接受压缩”的问题仍然没有解决
（测试了OpenFire 3.10，XIFF AS3库和Seesmic-XMPP AS3库的相同场景，并且由于OpenFire允许在SASL加密之前或之后进行压缩，因此进行了压缩）