使用 ObjectInputStream/ObjectOutputStream 实现网络“数据包”的优点和缺点在Java中？
我正在开发一个简单的客户端/服务器应用程序，它使用套接字进行所有通信。通信是基于数据包的，数据包的概念是使用一组类和套接字流的 ObjectInputStream/ObjectOutputStream 包装器来实现的。
想知道与完全基于文本的协议（如 IRC）或我明确使用字节的“非常二进制”的东西相比，这种方法是否有任何缺点。
让我们忽略这里的流量问题（“qwerty”与“qwerty”+ 1KB 元数据），只考虑可靠性和可维护性。
你怎么认为？
I'm working on a simple client/server application that uses sockets for all the communications. Communications are packet-based and the concept of packets is implemented using a set of classes and ObjectInputStream/ObjectOutputStream wrapper for socket streams.
Wondering if this approach has any disadvantages when compared to either fully text-based protocol (like IRC) or "very binary" stuff where I explicitly work with bytes.
Let's ignore the traffic problems here ("qwerty" vs. "qwerty" + 1KB of metadata) and only consider reliability and maintainability.
What do you think?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
就我个人而言，我发现 Java 中内置的二进制序列化非常痛苦。即使您没有更改任何预期会导致问题的内容，很容易导致版本不兼容，这很容易导致版本不兼容。
如果满足以下条件，那么这不是问题：
也许这就是你的情况 - 但我个人更喜欢序列化格式，它允许我在版本控制方面更加灵活。当然，现在并不要求它是二进制或文本。您可以使用 JSON、协议缓冲区、节俭或任意数量的其他选项。每个都有各自的优点和缺点 - 但每个都可能在设计时考虑到比 Java 更简单的版本兼容性。
现在，Java 序列化的优点是，当您处于一切正常的情况（您的整个树都是可序列化的）时，您可以直接序列化它而无需进行任何其他更改 - 您不需要对您的模型进行建模单独的数据，就像使用某些序列化框架一样。不幸的是，一旦您想要使用树中某处不可序列化的类，您就会再次陷入痛苦......
至于文本和二进制形式之间的选择 - 优点和缺点缺点相当显而易见。文本更大，但仅通过查看网络跟踪就可以更轻松地诊断正在发生的情况。当然，您需要确保双方使用相同的编码。
哦，当然，如果您想与非 Java 客户端/服务器进行通信，那么如果您使用过 Java 的本机序列化，您将会遇到困难:)
Personally I've found the binary serialization built into Java to be immensely painful. It's ludicrously easy to end up with version incompatibilities even when you haven't changed anything you expect to cause problems.
That's not an issue if:
Maybe that's your situation - but personally I prefer a serialization format which allows me to be more flexible with versioning. Now that doesn't require it to be either binary or text of course. You could use JSON, Protocol Buffers, Thrift or any number of other options. Each will have separate pros and cons - but each is likely to be designed with simpler version compatibility in mind than Java.
Now the upside of Java serialization is that while you're in the situation where everything works (your entire tree is serializable) you can just serialize it with no other changes - you don't need to model your data separately, as you do with some serialization frameworks. Unfortunately, as soon as you want to use a class which isn't serializable somewhere in your tree, you're back into pain...
As for the choice between text and binary forms - the pros and cons are reasonably obvious. Text is bigger, but it's easier to diagnose what's going on just by looking at network traces. You need to make sure you use the same encoding on both sides, of course.
Oh, and of course if you ever want to communicate with a non-Java client/server, you'll have a hard time if you've used Java's native serialization :)
维护与序列化对象的向后可比性是一件很痛苦的事情，而且非 Java 客户端无法与您的服务通信。序列化对象的序列化大小也不是很好。
我会使用协议缓冲区之类的东西来代替。
It.s a pain to maintain backwards comparability with serialized objects, and non java clients can't talk to your service. Serialized objects are not great with respect to serialized size as well.
I would use something like protocol buffers instead.