Netty in Action笔记(Chapter 8)Provided ChannelHandlers and codecs

【8.1 Securing Netty applications with SSL/TLS】

【8.3 Handling idle connections and timeouts】
You may find times when you want to handle idle connections and timeouts. Typically youd send a message, also called a "heartbeat," to the remote peer if it idles too long in order to detect if its still alive. Another approach is to disconnect the remote peer if it idles too long.
Dealing with idle connections is such a core part of many applications that Netty ships a solution for it. Three different ChannelHandlers handle idle and timeout, as shown in table 8.4.

IdleStateHandler
Triggers an IdleStateEvent when a Channel has not performed read, write, or both operation for a while.

Listing 8.9 shows how you can use the IdleStateHandler to get notified if you havent received or sent data for 60 seconds. If this is the case, a heartbeat will be written to the remote peer, and if this fails the connection is closed.

【8.4 Decoding delimiter- and length-based protocols】
【8.4.1 Delimiter-based protocols】

Imagine you have a protocol that handles only commands. Those commands are formed out of a name and arguments. The name and the arguments are separated by a whitespace.
Writing a decoder for this is a piece of cake if you extend the LineBasedFrameDecoder.
Listing 8.11 shows how to do it.
命令1 [参数...]\r\n
命令2 [参数...]\r\n

【8.4.2 Length-based protocols】

More often you find the case where the size of the frame is encoded in the header. For this purpose you can use the LengthFieldBasedFrameDecoder, which will read the length out of the header and extract the frame for the length.
Figure 8.7 shows how it works.

If the length field is part of the header frame extracted, this can be configured using the constructor of the LengthFieldBasedFrameDecoder. Also, it lets you specify where exactly in the frame the length field is and how long it is. Its very flexible, so for more information, please refer to the API docs.

【8.5 Writing big data】

【8.6 Serializing data】