Netty(1): Abstration

As the one of the most widely used network library in Java, Netty has become the de facto standard of network communication in Java. In this blog, we learn some basic concept and designs of Netty by examples in their website.

The following is the template code to start a server:

EventLoopGroup group = new NioEventLoopGroup();
EventLoopGroup worker = new NioEventLoopGroup();  
try { 
  ServerBootstrap b = new ServerBootstrap(); 
  b.group(group, worker)  
      .channel(NioServerSocketChannel.class)  
      .handler(new xxxHandler())
      .childHandler(new yyyHandler());  
  b.bind(PORT).sync().channel().closeFuture().await();  
} finally {  
  worker.shutdownGracefully();
  group.shutdownGracefully();  
}

In the view of normal Java plain IO & Servlet developer, this code snippet can be very confusing.

In plain Java IO way, we bind, listen, accept through ServerSocket. Then we start a new thread/executor to handle the received socket connection. If we use Java NIO, things goes a little different: we use ServerSocketChannel to listen connection and Selector to arrange multiple channels.

When we do it using Java EE servlet(or Spring), the listening job is done by container and it will pass the request to servlet & filter etc to handle.

So, in order to understand the logic behind the code, we need to understand the design and abstractions of Netty.

Basic Abstraction

Netty adopts an event-driven style design, which means, in Netty, all network related things are abstracted as events, and we react by adding listener or call back.

Events

Netty split events into two general kinds: Inbound and Outbound. Outbound events is often triggered by our operations, like write, bind, connect. Inbound events, on the other hand, is usually generated by IO thread, like channelRegistered, being in connected state – channelActive, receiving some packet from remove peer – channelRead.

So, Netty has two corresponding kinds of handler to handle those two kinds of events: ChannelInboundHandler & ChannelOutboundHandler.

State

When received events, our server/client will be triggered to invoke handler, and we can use handler to get involved in state change.

Examples: Registered & Active

We have mentioned that some common events like channelRegistered, channelActive and channelRead. channelRead is very easy to understand, which means channel received some packet. But what the meaning of Registered & Active?

Registered state means the Bootstrap has a channel registered in the eventloop, which is somewhat similar concept compared with Java NIO's selector .

Active is a little different. It is a new idea introduced in Netty 4, which is merged from channelOpen, channelBound, and channelConnected. Of course, channelDisconnected, channelUnbound, and channelClosed have been merged to channelInactive. Likewise, Channel.isBound() and isConnected() have been merged to isActive().

This merge is because Netty thought simple Open or Bound state is not so useful, and the final Connected state is when user will be interested in.

So the state transfer when bootstrap is like following:

server: channelRegistered -> bind (out bound) -> channelActive
client: channelRegistered -> connect (out bound) -> channelActive

What should be noticed is that channelRegistered and channelUnregistered are not equivalent to channelOpen and channelClosed. They are new states introduced to support dynamic registration, deregistration, and re-registration of a Channel.

Pipeline & Handler

In order to let user get involved in the state change and react to corresponding event, Netty has a chain of handlers which is called Pipeline. In order to decouple multiple handlers, handler not invoke each other: they are invoked through ChannelHandlerContext object. By calling fireXXX, user can trigger specific kinds of event for upcoming handler to react, make state change very flexible.

public class MyInboundHandler extends ChannelInboundHandlerAdapter {
    @Override
    public void channelActive(ChannelHandlerContext ctx) {
        System.out.println("Connected!");
        ctx.fireChannelActive(); // or fire other events
    }
}

EventLoop: Thread Pools

We have the code (in handler) to handle event and state, now we need thread to run them. Because those worker thread run in a loop to handle event, it is named as EventLoop.

If different worker threads run different kinds of jobs, like different code, different running time, they will have some performance penalty: some hot code which should be compiled into native code, may not benefit from this JIT functionality; when switching between long-lived job and short-lived job, CPU cache will be flushed; the number of thread in pool will be hard to control and init.

So, Netty use different threads to handle different jobs:

A EventLoop for receiving remote connection, do the long-lived accept job;
A EventLoop to run pipeline, which is relative short job;

Conclusion

In this blog, we learned some basic concepts and abstractions in Netty. Through this way, we understand how Netty view network related events and some design decision under the hood.

Ref

Written with StackEdit.

On teh way

Blog Search