Netty Core Concept

Reproduced from: http://blog.csdn.net/abc_key/article/details/37672187

A Netty program begins with the Bootstrap class, and the bootstrap class is a very important class provided by Netty that can be set or "booted" by a simple configuration. In Netty, handlers is designed to handle specific "event" and setting events in Netty to handle multiple protocols and data. Events can be described as a very generic method because you can customize a handler to convert object to byte[] or to convert byte[to object, or you can define a handler handle thrown exception.
Channelinboundhandler is used to receive messages, and when a message comes, you can decide what to do with them. When the program needs to return the message, it can write/flush the data in the Channelinboundhandler. It can be considered that the business logic of the application is handled in Channelinboundhandler, and the life cycle of the business Luo is in Channelinboundhandler.
Netty Connect client-side or bound servers need to know how to send or receive messages, which are done through different types of handlers, and how multiple handlers are configured. Netty provides a channelinitializer class for configuring handlers. Channelinitializer are channelpipeline to add channelhandler, such as sending and receiving messages, and these handlers will determine what messages are sent. Channelinitializer itself is also a channelhandler that automatically deletes itself from Channelpipeline after adding other handlers.
All Netty programs are based on Channelpipeline. Channelpipeline and EventLoop are closely related to Eventloopgroup, since all three of them are associated with event handling, so that's why they deal with IO work by EventLoop management.
All IO operations in Netty are performed asynchronously, such as connecting a host asynchronously by default, and write/Send messages are also asynchronous. This means that the operation will not be executed directly, but will wait for a while to execute, because you do not know the return of the operation results are successful or failed, but need to check whether the success of the method or registration of monitoring to notify; Netty use futures and channelfutures to achieve this goal. Future registers a listener that is notified when the operation succeeds or fails. Channelfuture encapsulates information about an operation that is immediately returned to Channelfuture when the operation is executed.

channels,events and IONetty is a non-blocking, event-driven network framework. Netty actually uses multithreading to handle IO events, and readers who are familiar with multithreaded programming may need to synchronize the code. This is not a good way because synchronization affects the performance of the program, and the Netty design guarantees that the program handles events without synchronization.
The following figure shows a eventloopgroup and a channel associated with a single eventloop,netty eventloopgroup containing one or more eventloop, And EventLoop is a channel thread that performs the actual work. EventLoop always binds a single thread and does not change during its lifecycle.

When a channel is registered, Netty binds the channel to a eventloop that is always bound to a channel during the life cycle of the eventloop. In Netty IO operations, the program does not need to be synchronized because all IO for a given channel is always performed by the same thread.

To help understand this, the following illustration shows the relationship between EventLoop and Eventloopgroup:

The Association of EventLoop and Eventloopgroup is not intuitive because eventloopgroup contains one or more eventloop, but the above illustration shows that EventLoop is a eventloopgroup, This means that you can use only one specific eventloop.

What is bootstrap? Why use it. Boot is the process of configuring a program in Netty, which requires the use of bootstrap when you need to connect to a client or server binding a specified port. As mentioned earlier, there are two types of boot, one for the client (bootstrap for Datagramchannel) and one for the serverbootstrap on the server. Regardless of which protocol the program uses, you need to use bootstrap to create either a client or a server.
There are some similarities between the two kinds of bootsstraps, and there are some differences. The difference between Bootstrap and Serverbootstrap:
Bootstrap is used to connect to a remote host, there are 1 eventloopgroup serverbootstrap used to bind the port, there are 2 eventloopgroup the first difference is obvious, "Serverbootstrap" Listens for "Bootstrap" or Datagramchannel to connect to the server when the server listens on a port to poll the client. It is often necessary to invoke the Connect () method of the "Bootstrap" class, but you can also call bind () and connect () and then use the channel contained in the Channelfuture returned by bind ().
The second difference may be the most important. The client bootstraps/applications uses a single example of Eventloopgroup, while Serverbootstrap uses 2 eventloopgroup (actually using the same instance). A serverbootstrap can be considered to have 2 channels groups, the first group contains a single case Serverchannel, the representative holds a socket bound to the local port, and the second group contains all the channel, representing the connections that the server has accepted. The image below depicts the situation:

In the figure above, Eventloopgroup A's sole purpose is to accept the connection and then hand it over to Eventloopgroup B. Netty can use two different group, because the server program needs to accept many client connections, a eventloopgroup will be the bottleneck of program performance, because the event loop is busy processing the connection request, does not have the extra resources and the idle to handle the business logic, The final result would be that many connection requests timed out. If there are two eventloops, all connections will be accepted even under high load, because eventloops accept that the connection will not share resources with those already connected.

What is the relationship between Eventloopgroup and EventLoop? Eventloopgroup can contain many eventloop, each channel binding a eventloop will not be changed, because Eventloopgroup contains a small number of eventloop channels, Many channel share the same eventloop. This means that keeping eventloop busy in a channel will prevent other channel from binding to the same eventloop.     It can be understood that EventLoop is an event loop thread, and Eventloopgroup is a collection of event loops. If you decide to configure the Netty server two times with the same Eventloopgroup instance, the following figure shows how it changes:

Netty allows processing IO and accepting connections to use the same eventloopgroup, which is applied in practice for a variety of applications. The figure above shows a eventloopgroup processing connection request and IO operation.

Channel handlers and data flow (channel processing and streaming)To understand what happens when the Netty program Wirte or read, the first thing to know is what handler is. Handlers itself relies on channelpipeline to determine the order in which they are executed, so it is not possible to define some aspects of the handler through Channelpipeline, In turn, it is impossible to define or define certain aspects of channelpipeline through Channelhandler.
In many places, Netty's Channelhandler is the most processed in the application. So what exactly is Channelhandler. To give Channelhandler a definition is not easy, it can be understood that Channelhandler is a section of code to perform business logic processing data, they come and go through the channelpipeline. In fact, Channelhandler is the parent interface that defines a handler, Channelinboundhandler and Channeloutboundhandler implement the Channelhandler interface, as shown in the following figure:

There is a significant difference between the inbound (Channelinboundhandler) and outbound (Channeloutboundhandler) data flows in the Netty: If the data is from a user application to a remote host it is "Outbound" ( Outbound) ", on the contrary, when data is from a remote host to a user application is" inbound (inbound). "
In order for the data to reach from one end to the other, the Channelhandler will manipulate the data in some way. These channelhandler are added channelpipeline in the "boot" phase of the program, and the order in which they are added determines the order in which the data is processed. The role of Channelpipeline can be understood as a container for managing Channelhandler, each Channelhandler processing its own data (for example, inbound data can only be handled by Channelinboundhandler), When processing is complete, the transformed data is placed in Channelpipeline to the next channelhandler to continue processing until the last Channelhandler process completes.
The following illustration shows the process of Channelpipeline:

The figure above shows that both Channelinboundhandler and Channeloutboundhandler have to go through the same channelpipeline.
In Channelpipeline, if the message is read or there are any other inbound events, the message is passed from Channelpipeline's head to the first Channelinboundhandler, This channelinboundhandler can either process the message or pass the message to the next channelinboundhandler, once there is no remaining channelinboundhandler in the Channelpipeline, Channelpipeline knew that the message had been handled by all the handler.
Conversely, any outbound event or write will start at the end of the Channelpipeline and pass to the last Channeloutboundhandler. The Channeloutboundhandler function is the same as Channelinboundhandler, which can pass event messages to the next handler or process messages yourself. The difference is that Channeloutboundhandler starts at the tail of the Channelpipeline, and Channelinboundhandler starts with the head of Channelpipeline, When the first channeloutboundhandler processing is finished, some operations, such as a write operation, are started.
An event can be passed to the next Channelinboundhandler or previous Channeloutboundhandler, and each method is invoked in Channelpipeline by using Channelhandlercontext. Netty provides an abstract event base class called Channelinboundhandleradapter and Channeloutboundhandleradapter. Each provides the implementation of a method in Channelpipeline to pass an event to the next handler by calling the appropriate method. The way we can cover it is the processing we need to do.

Perhaps readers will be surprised that the outbound and inbound operation is different, can be placed in the same channelpipeline work. Netty design is very ingenious, inbound and outbound handler have different implementations, Netty can skip an unhandled operation, so in the event of outbound events, Channelinboundhandler will be skipped, Netty know that each handler must be Channelinboundhandler or Channeloutboundhandler.
Gets a channelhandlercontext when a channelhandler is added to the channelpipeline. It is usually safe to obtain a reference to this object, but when a datagram protocol such as UDP is incorrect, the object can then be used to fetch the underlying channel, because it is used to read/write the message, so the channel is preserved. That is to say, there are two ways to send a message in Netty: Write directly to the channel or write to the Channelhandlercontext object. The main differences between the two approaches are as follows:
• Direct write channel causes processing messages to start at the end of the Channelpipeline
• Writing Channelhandlercontext objects causes processing messages to start from the next handler of Channelpipeline

encoders, decoders, and business logic: A closer look at handlersAs mentioned earlier, there are many different types of handlers, each handler dependent on their base class. Netty offers a series of "Adapter" classes that make things simple. Each handler is responsible for forwarding the event to the next handler of Channelpipeline. is done automatically in the adapter class (and subclasses), so you only need to override the method in the adapter of interest. These features help us to encode/decode messages very simply. There are several adapters (adapter) that allow custom Channelhandler, and general custom Channelhandler need to inherit one of the encoding/decoding adapter classes. Netty has the following adapters:
Channelhandleradapter
Channelinboundhandleradapter
Channeloutboundhandleradapter
Focus on Ecoders,decoders and simplechannelinboundhandler<i>. Simplechannelinboundhandler<i> inherits Channelinboundhandleradapter.

encoders (Encoder), decoders (decoder)
After a message is sent or received, Netty must convert the message data from one form to another. After receiving the message, the message needs to be converted from bytecode to Java object (decoded by some decoder); the Java object needs to be converted to bytes (encoded by some types of encoders) before sending the message. This conversion typically occurs in a network program because only byte data can be transmitted on the network.
There are several basic types of encoders and decoders, depending on the functionality you want to implement. To figure out some type of codec, from the class name can be seen, such as "Bytetomessagedecoder", "Messagetobyteencoder", as well as Google's agreement "Protobufencoder" and " Protobufdecoder ".
Strictly speaking, other handlers can do encoders and adapters, using different adapter classes depending on what you want to do. In the case of a decoder, there is a channelinboundhandleradapter or channelinboundhandler, and all decoders inherit or implement them. The "Channelread" method/event is overwritten, and this method reads each message from the inbound (inbound) channel. The overridden Channelread method invokes the "Decode" method of each decoder and passes Channelhandlercontext.firechannelread (Object msg) Passed to the next channelinboundhandler in the Channelpipeline.
Similar to inbound messages, when you send a message out (outbound), the encoder forwards the message to the next channeloutboundhandler, except for the bytecode.

Business Logic
Perhaps the most common is when the application processes the message and decodes it, which is then used by the relevant business logic module. So the application only needs to extend the simplechannelinboundhandler<i&gt, that is, to customize a handler class that inherits Simplechannelinboundhandler<i>, where < I> is the type of message that handler can handle. By overriding the parent class, you can get a channelhandlercontext reference that accepts a channelhandlercontext parameter that you can store as a property in class.
The main approach the handler focuses on is "channelRead0 (Channelhandlercontext ctx, I msg)", and whenever Netty calls this method, the object "I" is the message, where Java's generic design is used, and the program can handle I. How messages are handled depends entirely on the needs of the program. One thing to be aware of when processing messages is that event-handling IO typically has a number of threads in Netty, and in the program try not to block IO threads, because blocking can degrade program performance.
The need to not block IO threads means there is a problem with blocking operations in Channelhandler. Fortunately, Netty provides a solution that can specify a eventexecutorgroup when adding Channelhandler to Channelpipeline. Eventexecutorgroup will get a eventexecutor,eventexecutor all the methods that will perform channelhandler. Eventexecutor will use a different thread to execute and release EventLoop.