Plot the flow of data between the pipeline, channel, and context of the Netty.

Disclaimer: This article is the original blog post, prohibit reprint.

The following drawings are drawn based on the Netty4.0.28 version.

One, connect (outbound type event)

when a user invokes connect with the channel, an event of type outbound is initiated, which is passed in pipeline (pipeline.connect), first handled by tail handler, The handler simply passes the event through to the next outbound type of user handler (if any), the event is passed down sequentially until it is passed to head handler, and the handler calls Unsafe.connect () to EventLoop ( NIO's selector) registers a read event.

Second, connect successfully after the flow chart (inbound type event)

When a user initiates a connect request, when the connection is available, EventLoop (selector with NiO at the bottom) raises a channelactive event, which is first caught with unsafe, Pipeline.firechannelactive () is then called to propagate the event in pipeline, followed by a chain pass between the handler and the context, depending on how the inbound type event is passed. One of the areas of concern is that when the Channelactive event is triggered, if the channel is set to Autoread, then the Channel.read () method is also called, which is not really reading the data from the channel, Instead of registering a read event with EventLoop (because a channel is not registering any events by default when registering with EventLoop), the procedure for Channel.read can be seen in another diagram below.

Iii. Channel.read Event Flow graph (Outbound type event)

when the user calls Channel.read (), a outbound-type event is initiated, which is first handled by tail handler in pipeline. The handler simply passes the event through to the user handler (if any) of the previous outbound type, then proceeds forward until it is passed to head handler, which handler calls Unsafe.read () Registering read events with EventLoop (that is, adding read events to the selector of NiO)

Iv. channel.write (Outbound type event)

With the Channel.read () type, Wirte is also an outbound type event, which is first passed by tail handler in pipeline to the user outbound (if any) of the preceding handler type, which in turn passes , until it is passed to head handler, the handler calls the Unsafe.write () method, where the Wirte does not perform a real send, but rather caches the data to be sent until the flush is called, and the data executes the true network IO.

V. Flush (Outbound type event)

As shown earlier, flush is also a outbound type of event, unlike Wirte, which performs real network IO operations.

Vi. when the channel has data readable (inbound type event)

When the EventLoop layer detects that the network layer has data readable (the selector of NiO returns the corresponding Seleciontkeys), the event is first passed to unsafe, and then Pipeline.firechannelread () is called. The event starts in pipeline, and the event first has head handler processing (Head.firechannelread ()), which directly passes the event to the next inbound type of user handler (if any). The event is passed down in turn until it is passed to tail handler.

The

Plots the flow of data between the pipeline, channel, and context of the Netty.