Google协议缓冲区或类似的.net / javascript

Question

我们当前正在使用对.net Web服务的Ajax调用，然后将Json对象返回给客户端。其中一些Json对象非常庞大（未压缩的500k）。我们听说过Google Protocol Buffers的一些好消息，并且一直在试验。

到目前为止，我们在服务器上使用看起来最常见的.net版本 - “protobuf-net”进行了序列化。我们没有太多运气反序列化客户端。我们尝试使用似乎是唯一的javascript反序列化程序protobuf.js。我们发现它不容易使用，只有很少的示例或文档，它似乎不处理字符串和整数以外的数据类型。

在这一点上，似乎有一个经过验证的，定义明确的解决方案，用于.net和Web客户端之间的二进制数据序列化/反序列化。也许我们错过了一些明显的东西。

我们的要求是来自客户端的Ajax调用，以及服务器上的.net Web服务方法（.asmx或WCF）。

感谢任何意见和建议。

Answer 1

如果客户端是javascript，我认为你会很挣扎。有（如你所说）有限的 javascript报道，但我不确定它会为你带来多少收获。致quote from Kenton Varda（谁真正了解protobuf）：

  

javascript和。的一个问题   protobuf是你需要很多   支持解析消息的代码。   除非你最终发送了很多   来回的东西，使得   用户下载JS protobuf编解码器   图书馆可能是净损失。它可能是   最好使用JSON或XML，因为   浏览器已经内置了   支持那些。

     

那就是说，我想   google里面有各种各样的人   玩javascript +协议   缓冲一段时间，如果我们结束了   任何运作良好的东西，   我们会发布它。

所以也许未来会有希望。现在我会坚持使用json + deflate，或者如果您的场景允许，您可以使用嵌入客户端的Silverlight applet？ protobuf-net将在Silverlight中运行。

Answer 2

您可能会发现JSON实际上是最佳答案。 Justin已经完成了一系列performance comparisons of JSON to Thrift and Protocol Buffers，发现压缩的JSON比协议缓冲区更快，至少在Python中是这样。这是关于该主题的earlier thread。

Answer 3

如上所述，使用javascript的二进制协议是有问题的。一些特别讨厌的方面是：

• 很难从javascript中可靠地访问内容为二进制文件 - 解决方法通常是特定于浏览器的（参见Accessing binary data from Javascript, Ajax, IE: can responseBody be read from Javascript (not VB)?）
• 编码/解码标准IEEE编码的double / float值很难且效率低下（如果不是完全不可能的话）

与JSON或XML的本机支持相比，性能不太可能更快。