我正在一个拥有jabber通信平台的项目中工作。
问题是我需要客户（很多客户）彼此之间进行通信，不仅是为了信号化，而且是为了改变它们之间的数据。
想象一下，客户端A有3种服务可用。客户端B可以请求A开始向他发送来自每个服务的信息（如流服务），直到客户端B向A表示停止服务。
这些服务只能发送一个间隔为100毫秒的字符或1000个字符间隔100毫秒的字符，甚至可以在需要时发送一些数据。
当信息发送到B时，它必须知道什么服务对应，什么动作和值（示例），所以我使用json而不是jabber。
我的问题是我用jabber xmpp协议浪费了很多带宽只是为了发送一个像下面这样的信息的消息：
{“s”：“x”，“x”：5} //每100毫秒（5代表任意数字）
我真的不希望进行并行通信（比如直接套接字），因为jabber已经实现了所有这些并且它易于扩展，防火墙问题，有时我使用http通信（在这种情况下即时使用BOSH）。
我知道我可以做一些压缩，但是我想知道你是否推荐了一些其他的东西，这些东西在我的消息背后仍然没有这么多的xml，仍然使用jabber。
非常感谢你的帮助。
最诚挚的问候，
爱德华
答案 0 :(得分：2)
不，Xml不是垃圾。它具有人性化，可扩展性和压缩性。
XMPP支持流压缩，根据我的所有测试，此流压缩（主要是zlib）工作得非常好。因此，如果您优化通过线路发送的字节数或低带宽对您很重要，那么当您使用套接字时，请使用流压缩。当您使用Bosh时，您必须使用支持HTTP压缩的服务器或在其间使用代理来启用压缩。但请记住，BOSH在所有HTTP标头上也有很多开销。
答案 1 :(得分：2)
听起来，除了重要的数据传输，XMPP很适合您的应用程序。
您可能知道，XMPP从未被设计或打算用作数据传输的大管道。大多数涉及重要数据传输的应用程序（例如文件传输和语音/视频）仅使用XMPP来协商单独的“带外”流。您说这可能会因为防火墙和Web客户端而导致问题。
如果您的应用程序主要是传输文本，那么您真的应该尝试压缩...如果这是您最受限制的资源，它可以显着节省带宽。缺点是需要更多的客户端和服务器内存（默认情况下大约300KB，但可以通过边际压缩损失来减少）。
或者，您可以查看使用In-Band Bytestreams对数据库64进行隧道传输。我没有您的样本数据，或者知道如何将它们包装起来进行运输，这可能会变得更糟或更好。我会说，如果你剥离了你的JSON并使其成为更有效的二进制格式，它会更好。 Base64数据压缩不会很好，比原始数据大约大33％。节省的是能够剥离JSON和任何其他无关的包装，同时将数据保留在XMPP流中。
最终扩展大多数应用程序都很难，无论您使用哪种技术。它主要需要洞察力 - 如果不先测试它就不应该改变任何东西，你应该事先测试一下，找出你应该改变的东西。你应该分析你的系统的主要瓶颈（它真的是客户端的带宽??）。在我的经验中，很少有XML本身成为直接的瓶颈。然而，最终所有这些都是您的应用程序所独有的，大规模提供通用建议并不容易。