我正在开发一个使用套接字进行所有通信的简单客户端/服务器应用程序。通信是基于数据包的，数据包的概念是使用一组用于套接字流的类和ObjectInputStream/ObjectOutputStream包装器来实现的。
想知道与完全基于文本的协议（如 IRC）或我明确使用字节的“非常二进制”的东西相比，这种方法是否有任何缺点。
让我们忽略这里的流量问题（“qwerty”与“qwerty”+ 1KB 的元数据），只考虑可靠性和可维护性。
你怎么看？
问问题
1365 次
2 回答
5
就我个人而言，我发现 Java 中内置的二进制序列化非常痛苦。即使您没有更改任何预期会导致问题的内容，最终也很容易出现版本不兼容。
如果：
- 您可以保证您的客户端/服务器都将运行完全相同版本的代码。
- 您永远不需要读取以前版本写入的任何数据。
也许这就是你的情况——但我个人更喜欢序列化格式，它可以让我在版本控制方面更加灵活。现在这当然不需要它是二进制或文本。您可以使用 JSON、Protocol Buffers、Thrift或任何数量的其他选项。每一个都有各自的优缺点——但每一个都可能在设计时考虑到比 Java 更简单的版本兼容性。
现在，Java 序列化的好处是，当您处于一切正常的情况下（您的整个树都是可序列化的）时，您只需序列化它而无需进行其他更改 - 您不需要单独建模数据，就像您使用一些序列化框架。不幸的是，一旦你想在你的树的某个地方使用一个不可序列化的类，你就会重新陷入痛苦......
至于文本和二进制形式之间的选择 - 优点和缺点是相当明显的。文本更大，但仅通过查看网络跟踪就更容易诊断正在发生的事情。当然，您需要确保在两侧使用相同的编码。
哦，当然，如果您想与非 Java 客户端/服务器通信，那么如果您使用过 Java 的本机序列化，您将很难 :)
于 2011-08-14T06:43:13.337 回答
2
保持与序列化对象的向后可比性很痛苦，而且非 Java 客户端无法与您的服务对话。序列化对象在序列化大小方面也不是很好。
我会改用协议缓冲区之类的东西。
于 2011-08-14T06:43:38.623 回答