Netty Architecture Overview & Core Components

This chart is very important and I suggest you keep it in mind as you read this article.

To view pictures, go to: Netty Architecture Overview & Core Components

Transport services

  1. Socket & Datagram: a communication interface that establishes conditions for communication between two ends. TCP and UDP are based on this interface.
  2. HTTP Tunnel: indicates the HTTP Tunnel
  3. In-vm Piple: Indicates the Piple channel of the Java VM

Protocol support

  1. HTTP & WebSocket Hypertext Transfer Protocol & Full-duplex Communication protocol based on TCP (can be used for two-way communication)
  2. SSL & StartTSL encryption protocol
  3. Google Protobuf A binary transport protocol developed by Google. It is lightweight, efficient, and difficult to read.
  4. Zip /gzip Compression: Compression protocol
  5. Large File Transfer: Large File Transfer
  6. RTSP Real Time Streaming Protocol: used for multimedia data transmission

The core

  1. Extensible Event Model
  2. Universal Communication API A unified Communication API
  3. Zero-copy-capable Rich Byte Buffer Zero-copy high-performance Byte Buffer

1. Rich Buffer Data Structure

Netty uses its own buffer instead of NIO’s ByteBuffer to represent sequences of bytes, which has significant advantages over ByteBuffer.

Netty designed ChannelBuffer from the ground up, which solved some of the problems of ByteBuffer while meeting the needs of daily development.

Two questions arise here:

  1. What are the advantages of using ChannelBuffer over ByteBuffer?
  2. What problem does ChannelBuffer solve with ByteBuffer? What is the problem with ByteBuffer?

With these two questions in mind, let’s look at the properties of ChannelBuffer

Features:

  • You can define your own buffer types if necessary.
  • Straightforward zero copy is implemented by the built-in compound buffer type.
  • Dynamic buffer types are out-of-the-box and can expand dynamically on demand, just like StringBuffers.
  • You no longer need to call the flip() function
  • Its performance is generally faster than ByteBuffer
Merge and slice ChannelBuffers

When data is transmitted at the communication layer, it is usually necessary to combine or slice the data. For example, if a payload is split into multiple packets, then we need to merge them and decode them.

The traditional solution is to combine data from multiple packets by copying them into a new buffer.

Netty supports a zero-copy approach, which uses ChannelBuffers, where ChannelBuffers are used to point to the buffers needed to avoid copying. (There is also a zero copy that avoids copying data from kernel space to user space, which is also implemented by reference.)

2. Generic asynchronous I/O API

The traditional Java I/O API provides different methods for different transport modes, and such differences mean inconsistency

For example, java.net.socket and java.net.DatagramSocket do not have a common abstract superclass, and they handle Socket I/O in completely different ways.

This difference, or disunity, makes it difficult and tedious for network applications based on this implementation to convert from one transport mode to another. This means that we may be faced with different approaches to the same set of logic.

Generally speaking, network protocols can run over more than one transport, such as TCP/IP, UDP/IP, SCTP, serial port communication, and this non-portability can be a huge problem when we need to support multiple transports, which means we need to rewrite the network layer logic of our applications.

To make matters worse, Java NIO is not designed to be compatible with OIO and it is not compatible with AIO either. Since these apis are different in design and features, this means that at the beginning of the program design, you have to decide which API your application depends on, and it is difficult to change once determined.

Netty provides a unified asynchronous I/O interface, Channel

It abstracts all the methods needed for point-to-point communication, meaning that you can write your application on one Netty transport and your application can run on other transport types.

Netty provides several basic transport modes through a common interface:

  • NIO is a TCP/ IP-based transmission modeorg.jboss.netty.channel.socket.nio
  • OIO TCP/ IP-based transmission modeorg.jboss.netty.channel.socket.oio
  • OIO UDP/ IP-based transmission mode
  • Local transmission modeorg.jboss.netty.channel.local

Using Netty to transform transport usually requires only a few lines of code to change, such as choosing a different ChannelFactory implementation

3. Event model based on responsibility chain model

For event-driven applications, a well-defined extensible event model is essential. Netty has an event model that is explicitly focused on I/O. It allows you to implement your own event types without breaking the existing code structure.

Channelevents are handled through the List of ChannelHandlers in ChannelPipline. ChannelPipline implements an advanced chain of responsibility pattern that gives the user complete control over how events are handled and how each processor interacts with ChannelPipline.

For example, you can define what to do when data is read from a socket.

public class MyReadHandler implements SimpleChannelHandler {
     public void messageReceived(ChannelHandlerContext ctx, MessageEvent evt) {
            Object message = evt.getMessage();
         // Do something with the received message..// And forward the event to the next handler.ctx.sendUpstream(evt); }}Copy the code

You can also define the logic to handle when the handler receives a write request

public class MyWriteHandler implements SimpleChannelHandler {
       public void writeRequested(ChannelHandlerContext ctx, MessageEvent evt) {
            Object message = evt.getMessage();
           // Do something with the message to be written..// And forward the event to the next handler.ctx.sendDownstream(evt); }}Copy the code

4. Provides advanced components for rapid development

In addition to the core components described above, Netty also provides advanced components for rapid development.

Codec framework:

Netty provides a number of basic and advanced codecs that solve most of the problems we have with writing our own codecs, such as handling message fragments, as well as some multi-level protocol handling (that is, built on top of other lower-level protocols).

SSL/TLS support:

Supporting SSL in NIO is not a simple matter. You can’t simply wrap a stream to encrypt or decrypt it, you have to use javax.net.ssl.SSLEngine SSLEngine is a state machine as complex as SSL itself. You have to manage all possible states, such as cipher-suite, cryptographic key negotiation, renegotiation, certificate exchange, and authentication, and SSLEngine is not completely thread-safe.

Netty provides SslHandler for this purpose. SslHandler handles SSLEngine, and all we need to do is configure SslHandler and configure it into ChannelPipline. It also supports easy implementation of StartTLS

HTTP:

As the most popular protocol in the network at present, Netty provides the implementation of HTTP. At present, there are many implementations of HTTP, such as Servlet container, and Netty’s support for HTTP is very different from the existing library, which supports the control of HTTP message exchange at a low level. Because it is basically a combination of HTTP codecs and HTTP message classes, there is no constraint to enforce a threading model.

So we can write HTTP servers in Netty and in any way we want, we have complete control over everything in the HTTP specification, including the threading model, connection life cycle, and chunking coding

Because of its highly customizable nature, it is possible to write a very efficient HTTP server, such as:

  • Chat servers that require persistent connections and server push technologies (such as Comet’S “server push” over HTTP long connections)
  • You need to keep connected to an open media streaming server until the entire media has been streamed (for example, 2 hours of video)
  • File servers that allow large files to be uploaded without memory stress (e.g. 1GB per request)
  • Extensible mashup client that asynchronously connects to tens of thousands of 3rd side Web services

Webscoket implementation:

Webscoket allows bidirectional, full-duplex communication channels over a single Transmission Control Protocol (TCP) socket. It is designed to allow data to be transferred between Web browsers and Web servers. Netty provides the implementation of io.net ty. The handler. Codec. HTTP. Websocketx

Integrated With Google Protocol Buffer:

If you want to implement high performance binary Protocol client server, Google’s Protocol Buffer is definitely the best choice. Netty provides ProtobufEncoder and ProtobufDecoder. You can encode and decode message classes generated by Google Protocol Buffer using Netty.

conclusion

Netty provides us with:

Efficient byte buffer, zero copy technology.

Unified asynchronous I/O communication API, fast switching transmission mode.

An event model based on the chain of responsibility pattern, customizing your own event handling without intrusion, and controlling the relationship between processors.

Developing advanced components quickly, right out of the box, makes it possible to develop customization quickly.

The three core components of Netty are: Buffer, Channel, and Event Model. The rest of the advanced functionality is built on top of these three core components.

So, if you want to build your own communications server, Netty is a great choice, whether it’s HTTP, Wetscoket, Mqtt, etc., you can customize it yourself.

Welcome to my public account, I am dying aground