我正在为加密的P2P架构开发一个低级UDP消息传递层，如果有兴趣，您可以阅读更多相关信息on its github page。
我已经构建了一个简洁的序列化框架，将POJO转换为紧凑的ByteBuffers，以及使用对称和非对称加密的各种库都相当轻松。
我现在正致力于消息传递框架，它利用动态代理实现与GWT的RPC机制类似的功能。
我的问题是早期我决定使用ByteBuffers读取和写入序列化机制。我现在发现这有几个问题：
有人可以建议在此框架中实现序列化的替代方法吗？
答案 0 :(得分：3)
可能值得一看KryoNet - 它可能符合您的需求，或者您也可以看看他们是如何做事的。
顺便说一句，他们确实使用ByteBuffers进行TCP和UDP连接。我认为诀窍是从ByteBuffers中抽象出来，这样任何客户端代码都可以与POJO一起使用。要做到这一点，你显然需要在某处可以将大对象分解为多个缓冲写入。
我认为你真的还想要ByteBuffers，因为它们非常快，支持各种原生加速技巧，不管你喜不喜欢，最终你需要在高吞吐量IO环境中处理缓冲....
答案 1 :(得分：0)
有人可以建议在此框架中实现序列化的替代方法吗？
为什么选择，我在这里解决您的主要问题：
- 您需要在序列化对象之前知道最大字节缓冲区大小
为什么ByteBuffer的最大大小？您可以使用缓冲池。您应该准备将对象拆分为多个数据包。一个数据包 - 一个对象不适用于较大的对象。 序列化是一个有趣的观点：通常这就是它变得混乱的地方。你需要一些不错的协议层（+ - 重发数据包等）
- 它们是可变的，这使得它们容易出错
出于性能原因，你确实希望它们是可变的。我从来没有遇到过他们可变的问题。您可能也想要直接缓冲区。谢天谢地，他们变异，因为他们不便宜（de）分配。直接缓冲区直接映射到OS代码（查看sun.nio.ch.DatagramDispatcher）
- 它们与DatagramPacket并不特别兼容，而且DatagramChannels令人困惑。
他们没问题，您只需要将对象拆分成多个数据包。如果您使用缓冲区，请坚持使用缓冲区，它应该没问题。