Java NIO框架Netty教程(十) Object对象的连续收发解析分析
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了Java NIO框架Netty教程(十) Object对象的连续收发解析分析，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含11301字，纯文字阅读大概需要17分钟。
内容图文
如果您一直关注OneCoder，我们之前有两篇文章介绍关于Netty消息连续收发的问题。( 《Java NIO框架Netty教程(五) 消息收发次数不匹配的问题 》、《 Java NIO框架Netty教程(七)-再谈收发信息次数问题 》)。如果您经常的“怀疑”和思考，我们刚介绍过了Object的传递，您是否好奇，在Object传递中是否会有这样的问题？如果Object流的字节截断错乱，那肯定是会出错的。Netty一定不会这么傻的，那么Netty是怎么做的呢？
我们先通过代码验证一下是否有这样的问题。（有问题的可能性几乎没有。）
01.
/**
02.
* 当绑定到服务端的时候触发，给服务端发消息。
03.
*
04.
* @author lihzh
05.
* @alia OneCoder
06.
*/
www.it165.net
07.
@Override
08.
public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e) {
09.
// 向服务端发送Object信息
10.
sendObject(e.getChannel());
11.
}
12.
13.
/**
14.
* 发送Object
15.
*
16.
* @param channel
17.
* @author lihzh
18.
* @alia OneCoder
19.
*/
20.
private void sendObject(Channel channel) {
21.
Command command =
new Command();
22.
command.setActionName(
"Hello action."
);
23.
Command commandOne =
new Command();
24.
commandOne.setActionName(
"Hello action. One"
);
25.
Command command2 =
new Command();
26.
command2.setActionName(
"Hello action. Two"
);
27.
channel.write(command2);
28.
channel.write(command);
29.
channel.write(commandOne);
30.
}
打印结果：
Hello action. Two
Hello action.
Hello action. One
一切正常。那么Netty是怎么分割对象流的呢？看看ObjectDecoder怎么做的。
在ObjectDecoder的基类LengthFieldBasedFrameDecoder中注释中有详细的说明。我们这里主要介绍一下关键的代码逻辑：
01.
@Override
02.
protected Object decode(
03.
ChannelHandlerContext ctx, Channel channel, ChannelBuffer buffer)
throws Exception {
04.
05.
if (discardingTooLongFrame) {
06.
long bytesToDiscard = this.bytesToDiscard;
07.
int localBytesToDiscard = (int) Math.min(bytesToDiscard, buffer.readableBytes());
08.
buffer.skipBytes(localBytesToDiscard);
09.
bytesToDiscard -= localBytesToDiscard;
10.
this
.bytesToDiscard = bytesToDiscard;
11.
failIfNecessary(ctx,
false
);
12.
return null;
13.
}
14.
15.
if (buffer.readableBytes() < lengthFieldEndOffset) {
16.
return null;
17.
}
18.
19.
int actualLengthFieldOffset = buffer.readerIndex() + lengthFieldOffset;
20.
long frameLength;
21.
switch (lengthFieldLength) {
22.
case 1:
23.
frameLength = buffer.getUnsignedByte(actualLengthFieldOffset);
24.
break
;
25.
case 2:
26.
frameLength = buffer.getUnsignedShort(actualLengthFieldOffset);
27.
break
;
28.
case 3:
29.
frameLength = buffer.getUnsignedMedium(actualLengthFieldOffset);
30.
break
;
31.
case 4:
32.
frameLength = buffer.getUnsignedInt(actualLengthFieldOffset);
33.
break
;
34.
……
我们这里进入的是4，还记得在编码时候的开头的4位占位字节吗？跟踪进去发现。
1.
public int getInt(int index) {
2.
return (array[index] & 0xff) << 24 |
3.
(array[index +
1
] &
0xff
) <<
16 |
4.
(array[index +
2
] &
0xff
) <<
8 |
5.
(array[index +
3
] &
0xff
) <<
0
;
6.
}
原来，当初在编码时，在流开头增加的4字节的字符是做这个的。他记录了当前了这个对象流的长度，便于在解码时候准确的计算出该对象流的长度，正确解码。看来，我们如果我们自己写的对象编码解码的工具，要考虑的还有很多啊。
附：LengthFieldBasedFrameDecoder的JavaDoc
001.
/**
002.
* A decoder that splits the received {@link ChannelBuffer}s dynamically by the
003.
* value of the length field in the message. It is particularly useful when you
004.
* decode a binary message which has an integer header field that represents the
005.
* length of the message body or the whole message.
006.
* <p>
007.
* {@link LengthFieldBasedFrameDecoder} has many configuration parameters so
008.
* that it can decode any message with a length field, which is often seen in
009.
* proprietary client-server protocols. Here are some example that will give
010.
* you the basic idea on which option does what.
011.
*
012.
* <h3>2 bytes length field at offset 0, do not strip header</h3>
013.
*
014.
* The value of the length field in this example is <tt>12 (0x0C)</tt> which
015.
* represents the length of "HELLO, WORLD". By default, the decoder assumes
016.
* that the length field represents the number of the bytes that follows the
017.
* length field. Therefore, it can be decoded with the simplistic parameter
018.
* combination.
019.
* <pre>
020.
* <b>lengthFieldOffset</b> = <b>0</b>
021.
* <b>lengthFieldLength</b> = <b>2</b>
022.
* lengthAdjustment = 0
023.
* initialBytesToStrip = 0 (= do not strip header)
024.
*
025.
* BEFORE DECODE (14 bytes) AFTER DECODE (14 bytes)
026.
* +——–+—————-+ +——–+—————-+
027.
* | Length | Actual Content |—–>| Length | Actual Content |
028.
* | 0x000C | "HELLO, WORLD" | | 0x000C | "HELLO, WORLD" |
029.
* +——–+—————-+ +——–+—————-+
030.
* </pre>
031.
*
032.
* <h3>2 bytes length field at offset 0, strip header</h3>
033.
*
034.
* Because we can get the length of the content by calling
035.
* {@link ChannelBuffer#readableBytes()}, you might want to strip the length
036.
* field by specifying <tt>initialBytesToStrip</tt>. In this example, we
037.
* specified <tt>2</tt>, that is same with the length of the length field, to
038.
* strip the first two bytes.
039.
* <pre>
040.
* lengthFieldOffset = 0
041.
* lengthFieldLength = 2
042.
* lengthAdjustment = 0
043.
* <b>initialBytesToStrip</b> = <b>2</b> (= the length of the Length field)
044.
*
045.
* BEFORE DECODE (14 bytes) AFTER DECODE (12 bytes)
046.
* +——–+—————-+ +—————-+
047.
* | Length | Actual Content |—–>| Actual Content |
048.
* | 0x000C | "HELLO, WORLD" | | "HELLO, WORLD" |
049.
* +——–+—————-+ +—————-+
050.
* </pre>
051.
*
052.
* <h3>2 bytes length field at offset 0, do not strip header, the length field
053.
* represents the length of the whole message</h3>
054.
*
055.
* In most cases, the length field represents the length of the message body
056.
* only, as shown in the previous examples. However, in some protocols, the
057.
* length field represents the length of the whole message, including the
058.
* message header. In such a case, we specify a non-zero
059.
* <tt>lengthAdjustment</tt>. Because the length value in this example message
060.
* is always greater than the body length by <tt>2</tt>, we specify <tt>-2</tt>
061.
* as <tt>lengthAdjustment</tt> for compensation.
062.
* <pre>
063.
* lengthFieldOffset = 0
064.
* lengthFieldLength = 2
065.
* <b>lengthAdjustment</b> = <b>-2</b> (= the length of the Length field)
066.
* initialBytesToStrip = 0
067.
*
068.
* BEFORE DECODE (14 bytes) AFTER DECODE (14 bytes)
069.
* +——–+—————-+ +——–+—————-+
070.
* | Length | Actual Content |—–>| Length | Actual Content |
071.
* | 0x000E | "HELLO, WORLD" | | 0x000E | "HELLO, WORLD" |
072.
* +——–+—————-+ +——–+—————-+
073.
* </pre>
074.
*
075.
* <h3>3 bytes length field at the end of 5 bytes header, do not strip header</h3>
076.
*
077.
* The following message is a simple variation of the first example. An extra
078.
* header value is prepended to the message. <tt>lengthAdjustment</tt> is zero
079.
* again because the decoder always takes the length of the prepended data into
080.
* account during frame length calculation.
081.
* <pre>
082.
* <b>lengthFieldOffset</b> = <b>2</b> (= the length of Header 1)
083.
* <b>lengthFieldLength</b> = <b>3</b>
084.
* lengthAdjustment = 0
085.
* initialBytesToStrip = 0
086.
*
087.
* BEFORE DECODE (17 bytes) AFTER DECODE (17 bytes)
088.
* +———-+———-+—————-+ +———-+———-+—————-+
089.
* | Header 1 | Length | Actual Content |—–>| Header 1 | Length | Actual Content |
090.
* | 0xCAFE | 0x00000C | "HELLO, WORLD" | | 0xCAFE | 0x00000C | "HELLO, WORLD" |
091.
* +———-+———-+—————-+ +———-+———-+—————-+
092.
* </pre>
093.
*
094.
* <h3>3 bytes length field at the beginning of 5 bytes header, do not strip header</h3>
095.
*
096.
* This is an advanced example that shows the case where there is an extra
097.
* header between the length field and the message body. You have to specify a
098.
* positive <tt>lengthAdjustment</tt> so that the decoder counts the extra
099.
* header into the frame length calculation.
100.
* <pre>
101.
* lengthFieldOffset = 0
102.
* lengthFieldLength = 3
103.
* <b>lengthAdjustment</b> = <b>2</b> (= the length of Header 1)
104.
* initialBytesToStrip = 0
105.
*
106.
* BEFORE DECODE (17 bytes) AFTER DECODE (17 bytes)
107.
* +———-+———-+—————-+ +———-+———-+—————-+
108.
* | Length | Header 1 | Actual Content |—–>| Length | Header 1 | Actual Content |
109.
* | 0x00000C | 0xCAFE | "HELLO, WORLD" | | 0x00000C | 0xCAFE | "HELLO, WORLD" |
110.
* +———-+———-+—————-+ +———-+———-+—————-+
111.
* </pre>
112.
*
113.
* <h3>2 bytes length field at offset 1 in the middle of 4 bytes header,
114.
* strip the first header field and the length field</h3>
115.
*
116.
* This is a combination of all the examples above. There are the prepended
117.
* header before the length field and the extra header after the length field.
118.
* The prepended header affects the <tt>lengthFieldOffset</tt> and the extra
119.
* header affects the <tt>lengthAdjustment</tt>. We also specified a non-zero
120.
* <tt>initialBytesToStrip</tt> to strip the length field and the prepended
121.
* header from the frame. If you don‘t want to strip the prepended header, you
122.
* could specify <tt>0</tt> for <tt>initialBytesToSkip</tt>.
123.
* <pre>
124.
* lengthFieldOffset = 1 (= the length of HDR1)
125.
* lengthFieldLength = 2
126.
* <b>lengthAdjustment</b> = <b>1</b> (= the length of HDR2)
127.
* <b>initialBytesToStrip</b> = <b>3</b> (= the length of HDR1 + LEN)
128.
*
129.
* BEFORE DECODE (16 bytes) AFTER DECODE (13 bytes)
130.
* +——+——–+——+—————-+ +——+—————-+
131.
* | HDR1 | Length | HDR2 | Actual Content |—–>| HDR2 | Actual Content |
132.
* | 0xCA | 0x000C | 0xFE | "HELLO, WORLD" | | 0xFE | "HELLO, WORLD" |
133.
* +——+——–+——+—————-+ +——+—————-+
134.
* </pre>
135.
*
136.
* <h3>2 bytes length field at offset 1 in the middle of 4 bytes header,
137.
* strip the first header field and the length field, the length field
138.
* represents the length of the whole message</h3>
139.
*
140.
* Let‘s give another twist to the previous example. The only difference from
141.
* the previous example is that the length field represents the length of the
142.
* whole message instead of the message body, just like the third example.
143.
* We have to count the length of HDR1 and Length into <tt>lengthAdjustment</tt>.
144.
* Please note that we don‘t need to take the length of HDR2 into account
145.
* because the length field already includes the whole header length.
146.
* <pre>
147.
* lengthFieldOffset = 1
148.
* lengthFieldLength = 2
149.
* <b>lengthAdjustment</b> = <b>-3</b> (= the length of HDR1 + LEN, negative)
150.
* <b>initialBytesToStrip</b> = <b> 3</b>
151.
*
152.
* BEFORE DECODE (16 bytes) AFTER DECODE (13 bytes)
153.
* +——+——–+——+—————-+ +——+—————-+
154.
* | HDR1 | Length | HDR2 | Actual Content |—–>| HDR2 | Actual Content |
155.
* | 0xCA | 0×0010 | 0xFE | "HELLO, WORLD" | | 0xFE | "HELLO, WORLD" |
156.
* +——+——–+——+—————-+ +——+—————-+
157.
* </pre>
158.
*
159.
* @see LengthFieldPrepender
160.
*/
原文：http://www.cnblogs.com/hashcoder/p/7648426.html
内容总结
以上是互联网集市为您收集整理的Java NIO框架Netty教程(十) Object对象的连续收发解析分析全部内容，希望文章能够帮你解决Java NIO框架Netty教程(十) Object对象的连续收发解析分析所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。
来源：【匿名】