我目前正在编写代码以将数据传输到远程供应商。传输将通过 TCP 套接字进行。我遇到的问题是数据是可变长度的，并且没有框架或大小标记。发送数据没问题，但我不确定处理返回数据的最佳方式。
数据由不同的“消息”组成，但它们没有固定的大小。每条消息都有一个 8 或 16 字节的位图，指示该消息中包含哪些组件。有些组件是固定长度的，有些是可变的。每个可变长度组件都有一个用于整个消息的该部分的大小前缀。
当我第一次打开套接字时，我将发送消息，每个消息都应该收到响应。当我开始读取数据时，我应该在消息的开头。我需要解释位图以了解包含哪些消息字段。当数据到达时，我必须验证位图指示的每个字段是否存在并且大小正确。
一旦我阅读了所有第一条消息，下一条就开始了。我担心的是，如果传输在消息中途中断，我如何才能恢复并正确找到下一条消息的开始？
我将不得不模拟连接失败，并且我的代码需要在取消该消息之前自动重试一定次数。
我无法控制远程端的代码，也无法将帧字节或大小前缀添加到消息中。
最佳实践、设计模式或处理此问题的最佳方式的想法都受到欢迎。
TCP 流不能在消息中间“剪切”然后恢复。
如果传输中有足够短的中断，那么每一端的 O/S 都会处理，并根据需要重新传输数据包，但这对最终用户应用程序来说是不可见的 - 就它而言，流是连续的。
如果 TCP 连接确实完全断开，则两端都必须重新打开连接。此时，传输系统应该在新的消息边界处重新开始。
从用户的角度来看，TCP 是一个数据流，就像您可能通过串行端口接收一样。没有数据包，也没有标记。
非阻塞读取/接收调用将返回您当前到达的内容，您可以解析它。如果在解析时，您在到达消息末尾之前用完了数据，请读取/接收更多数据并继续解析。冲洗。重复。请注意，如果另一条消息紧随其后，您可能会获得比特定消息所需的更多字节。
TCP 流不会丢失或重新排序字节。除非连接中断或发件人有错误（例如，只能写入/发送部分，然后从未尝试写入/发送其余部分），否则消息不会被截断。您无法继续中断的 TCP 流。您只能打开一个新的并重新开始。
对于这样的事情，您可能会更轻松地使用网络框架（如 netty）或完全不同的 IO 机制，如带有 Play 2.0 的 Iteratee IO。