我想直接报告此错误，但在主页netty.io中找不到任何可能性
我在向频道发送数据时发现错误。在10-20％的情况下，情况并非总是如此，但它确实发生了。 以下，
例如，如果我第一次连接1024字节数据的消息，到目前为止一切都很好，而不是我使用HexDumpProxyInboundHandler创建套接字转发地址
这里很好，除了一件事，我已经在转发地址上创建了一个带有流量记录的监听器，在那里我得到了由Netty发送的消息。我希望它上面有1024字节的数据，但并不总是这样，不是100％的情况。 有时...
有时噩梦从这里开始， 如果我在1024字节消息之后得到相同的通道下一条消息，则数据将以下列可能的形式写入：
3.1第一条消息和第二条消息是合并的，我在端口监听器上获得的数据是正确的，1024 + 72（例如），也是正确的字节顺序（但是在合并的形式，已经不正确的对我来说）
3.2或者第一个消息和第二个消息也被合并，但是有一点点差异，不同的顺序，72（例如）+ 1024字节，即使服务器套接字正确接收数据，并且顺序正确。发送顺序也不正确。
3.3或者最后1024的第一条消息被发送，因为第二条消息也是如此发送，所以一切都很好，这也是正确的预期行为..
此外，错误发生并非总是如此，但它会发生，并且总是如果发生的话，只有在第一次连接时第一条消息长度为1024字节而第二条消息在第一条消息之后立即发送而没有接收到的数据时才会发生之前。
现在社区的问题是，是否有可能在Netty中关闭这种奇怪的缓冲行为？这样服务器套接字上收到的所有消息都以完全相同的方式发送到客户端套接字通道而不合并数据。
提前谢谢！
答案 0 :(得分：3)
这种“奇怪”的行为与netty毫无关系。它一直到网络层一次转移多少字节，所以它真的希望看到这一点。如果你需要拥有所有1024个字节，你需要缓冲它们，直到收到足够的数据。
答案 1 :(得分：1)
好的，经过漫长的夜晚，我终于解决了我的问题。看来，Netty项目仍然以这种方式出错，并接受传入的消息以便以错误的顺序发送。 所以，我做了什么，我用传入的消息填充缓冲区，直到客户端的远程连接被打开，所以我发送的不是完整的正确缓冲区，而是让Netty做的事情。