Please indicate the original source, thank you!

confusion

We all know bio NIO and NIO2 (also known as AIO). If you are not particularly familiar with the network I/O model I wrote earlier, why does netty often see code like the following?

EventLoopGroup... = new NioEventLoopGroup(); ..................... B.g roup (...) Channel (NioSocketChannel. Class)........................... ChannelFuture f = b.bind(PORT).sync();Copy the code

We know not to choose bio model, so why not choose AIO model? Or niO? This is a question worth thinking about, and I’ve been curious about it since AIO is obviously better than NIO in the network I/O model.

So why did Netty choose the NIO model?

Netty components are briefly introduced

Netty defines EventLoop as such. This article will not focus on EventLoop.

Will handle all the I/O operations for a Channel once registered. One EventLoop instance will usually handle more than one Channel but this may depend on implementation details and internals.

In Netty, the EventLoopGroup is defined in this way.

Special EventExecutorGroup which allows registering Channels that get processed for later selection during the event loop.

In Netty, a Channel is defined in this way.

A nexus to a network socket or a component which is capable of I/O operations such as read, write, connect, and bind.

A channel provides a user:

  • the current state of the channel (e.g. is it open? is it connected?) .

  • the configuration parameters of the channel (e.g. receive buffer size),

  • the I/O operations that the channel supports (e.g. read, write, connect, and bind), and

  • the ChannelPipeline which handles all I/O events and requests associated with the channel.

ChannelFuture is defined like this in Netty. This article will not focus on ChannelFuture.

The result of an asynchronous Channel I/O operation.

All I/O operations in Netty are asynchronous. It means any I/O calls will return immediately with no guarantee that the requested I/O operation has been completed at the end of the call. Instead, you will be returned with a ChannelFuture instance which gives you the information about the result or status of the I/O operation.

A ChannelFuture is either uncompleted or completed. When an I/O operation begins, a new future object is created. The new future is uncompleted initially – it is neither succeeded, failed, nor cancelled because the I/O operation is not finished yet. If the I/O operation is finished either successfully, with failure, or by cancellation, the future is marked as completed with more specific information, such as the cause of the failure. Please note that even failure and cancellation belong to the completed state.

Netty provides the implementation of network transmission

Note: this is a reference to netty actual combat books.

Take a look at RocketMQ, and RocketMQ will continue to analyze it when the Netty series is complete.

Remark:

If you are running on linux you can use EpollEventLoopGroup and so get better performance, less GC and have more advanced features that are only available on linux.

Epoll has two modes of operation for file descriptors –LT (Level trigger level mode) and ET (Edge Trigger edge mode)

To put it simply, LT is the default operation mode of epoll. When epoll_WAIT detects an event, it notifies the application, but the application does not have to process it immediately. In this way, epoll_WAIT notifies the application when it detects an event again until the event is processed.

In ET mode, if the epoll_WAIT function detects an event, it notifies the application to process it immediately, and subsequent epoll_WAIT functions will not detect the event. Therefore, ET mode reduces the number of epoll triggers of the same event to a large extent, so it is more efficient than LT mode.

LT(level triggered) : This is the default way of working and supports both block and no-block sockets. In this way, the kernel tells you if a file descriptor is ready, and then you can IO the ready FD. If you do nothing, the kernel will continue to inform you, so this mode is less likely to cause errors. The traditional SELECT /poll is representative of this model.

Thanks for chao Ge’s address: https://github.com/netty/netty/commit/9330172f803f340df677c370464126cd6112204a#diff-67591dfc9d4c7ea8dbe03ab24ff1669c, Slight difference between EpollEventLoopGroup and NioEventLoopGroup. Feel free to comment further.

– Why did Netty remove AIO support?

According to this question searched, the view to making the above description: https://github.com/netty/netty/issues/2515.

Remark: In general, AIO Not faster than NIO (epoll) on Unix Systems (which is true) is probably supported and Not cost-effective, so it may Not be worth it. Netty already packages it, It’s also easy for the user to call and use NIO or AIO at the bottom, but the user doesn’t need to care, as long as it’s fast.

Due to my own level problems, I may not understand a lot of things in place, welcome to actively discuss in the message area, thank you. AIO Not faster than NIO (epoll) on Unix Systems (which is true) For now, I’ll focus on the Netty trunk and return to this topic later.

If you feel that you have gained something after reading it, please click “like”, “follow” and add the official account “Ingenuity Zero” to check out more wonderful history!!