净额-框架 [英] Netty - Framing

问题描述

我创建了例子.我在端口8080上有一个EchoServer，在端口9090上有一个LogServer(在此示例中为示例).两者都在同一台计算机上启动(使用Server，其中包含主机).

I created this small example. I have an EchoServer on Port 8080 and a LogServer on Port 9090 (exemplary in this example). Both are started on the same machine (with Server, which contains the main).

Server started on port 8080
Server started on port 9090

客户端-通过telnet连接后，EchoServer便建立了与LogServer的连接.现在，我输入一个长文本，假设5000个字符(请参见示例中的long_text)，即使bash无法处理它:

As soon a client -- via telnet -- connects, the EchoServer establishes a connection to the LogServer. Now I am entering a long text, let's say 5000 character (see the long_text in the example), even if bash cannot handle it:

EchoServer Received: 1024
LogServer Received: 1024
EchoServer Received: 2048
LogServer Received: 2048
EchoServer Received: 1025
LogServer Received: 1025

如果我再次输入文本，我将得到:

If I enter the text again, I am getting:

EchoServer Received: 2048
LogServer Received: 2048
EchoServer Received: 2049
LogServer Received: 2049

让我们再做一次

EchoServer Received: 3072
EchoServer Received: 1025
LogServer Received: 3072
LogServer Received: 1025

再次:

EchoServer Received: 4096
EchoServer Received: 1
LogServer Received: 4096
LogServer Received: 1

最后一次:

EchoServer Received: 4097
LogServer Received: 4097

我的观察:

首先，数据是零散的.此外，每次将碎片扩展1024个字节(1024、2048、3072、4096等). 我猜最后一个行为是因为TCP启动缓慢.

First of all, the data is fragmented. Additionally, each time the fragmends are extended by 1024 bytes (1024,2048,3072,4096,...). I guess the last behavious is because of the TCP slow start.

如何在不分段的情况下实现转发到LogServer，这样我的文本将以一条消息的形式到达?我想问题是我如何连接到LogServer .

How can I achive the forwarding to the LogServer without fragmentation, such my text will arrive as one single message? I guess the problem is, how I connect to the LogServer.

[ EDIT1 ]

我更改了日志.看来，这已经在telnet和EchoSever之间发生了. 无论如何，我仍然在实际环境中遇到问题.整个消息(大约千字节)是通过WebSockets到达的，而转发到另一个连接是不完整的.

I changed the logs. It seems, that it's already happening between telnet and the EchoSever. Anyway, I still have the problem in the real environment. The whole message (some Kilobyte) is arriving via WebSockets and the Forwarding to another Connection is fragmented.

[ EDIT2 ]

我做了一些进一步的研究(wireshark-日志 ).我想这与TCP Slow Start无关.数据(我正在发送4095次字母A)作为三个正确的TCP数据包到达计算机:

I did some more research (with wireshark -- the log). I guess it has noting to do with TCP Slow Start. The data (I was sending 4095 times the letter A) arriving on the machine as three correct TCP packets:

1. 具有1440字节TCP数据(41 41 41 ... 41 41 41/HEX)的帧1(1506字节)
2. 具有1440字节TCP数据(41 41 41 ... 41 41 41/HEX)的帧2(1506字节)
3. 第3帧(1283字节)和1217字节的TCP数据(41 41 41 ... 41 0d 0a/HEX)

1. Frame 1 (1506 bytes) with 1440 bytes TCP data (41 41 41 ... 41 41 41/HEX)
2. Frame 2 (1506 bytes) with 1440 bytes TCP data (41 41 41 ... 41 41 41/HEX)
3. Frame 3 (1283 bytes) with 1217 bytes TCP data (41 41 41 ... 41 0d 0a/HEX)

所有4095个A字符+ CRLF均按预期到达.

All 4095 A characters + CRLF arrived as expected.

EchoServer说:

EchoServer Received: 1024
EchoServer Received: 2048
EchoServer Received: 1025

它也收到了4095个字符+ CRLF，但它的片段化与TCP片段不同(与上面的第一个日志完全相同).如何避免这种Netty行为?

It also received the 4095 characters + CRLF, but it is different fragmented than the TCP segments (exactly same as the first log above). How can I avoid this Netty behavior?

推荐答案

在非阻塞I/O中，没有实用的方法来获取套接字接收缓冲区中的可用字节数.由于这个问题，Netty 预测可用字节数.它从1024开始，然后根据读取的字节数增加预测.您可以通过采用其他预测算法来减少这种行为.

In non-blocking I/O, there's no practical way to get the number of available bytes in socket receive buffer. Because of that problem, Netty predicts the number of available bytes. It starts from 1024 and then increases the prediction depending the number of read bytes. You can shcnage this behavior by employing a different prediction algorithm.

默认实现为AdaptiveReceiveBufferSizePredictor，您可能需要查看其源代码以编写自己的源代码.

The default implementation is AdaptiveReceiveBufferSizePredictor and you might want to take a look into its source code to write your own one.

但是，无论选择哪种预测算法，都必须记住TCP/IP是一种流协议，这意味着您始终可以以拆分或合并形式获取消息.请参考用户指南: http://netty.io/docs/stable/guide/html /(请参阅处理基于流的传输"一节.)

However, no matter what prediction algorithm you choose, you have to keep in mind that TCP/IP is a streaming protocol, which means you can always get messages in a split or merged form. Please refer to the user guide: http://netty.io/docs/stable/guide/html/ (See the 'Dealing with a Stream-based Transport' section.)

这篇关于净额-框架的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！