What are the Netty Channel state transitions?

Question

Netty feeds have several states, but I cannot find documentation on the actual state transitions. Closest to any documentation on this subject that I can find for Netty 3.2.x here .

I managed to find possible conditions in which the channel may be here .

However, there is nothing that describes normal transitions that a channel can go from one state to another. It seems that not all channels make all possible state transitions.

Answer 1

Different Netty channels do have different state transitions.

In general, possible state transitions for a server based on TCP channels:

OPEN -> ( BOUND -> UNBOUND )* -> CLOSE 

If you use a subclass of SimpleChannelHandler in your pipeline, the equivalent methods for handling upstream events when one of these state changes occur:

 channelOpen channelBound channelUnbound channelClose 

Server channels never transition to the CONNECTED state.

Server channels rarely return to the BOUND state when they transition to the UNBOUND state, however this seems to depend on the application, therefore YMMV.

Note that server channels can trigger events when a child channel is open or closed. These events can occur only after the server channel is in the BOUND state. When these events are sent upstream on behalf of the server channel, the following methods are called to subclass SimpleChannelHandler :

 childChannelOpen childChannelClosed 

Possible state transitions for TCP-based child and client channels are:

 OPEN -> ( BOUND -> ( CONNECTED -> DISCONNECTED )* -> UNBOUND )* -> CLOSE 

It seems that the transition to the CONNECTED state is not first forced into the channel code; however, this state is invariably first triggered for both child and client channels in Netty before the channel is moved to the CONNECTED state.

If you use SimpleChannelHandler or its subclass in your pipeline with equivalent methods:

 channelOpen channelBound channelConnected channelDisconnected channelUnbound channelClose 

A TCP-based channel must be in the CONNECTED state before anything can be read or written to the channel. This includes server channels that can never be read or written, which is not because server channels are invariably used only to control connect work on behalf of the server.

Datagram sockets work differently than TCP based sockets. they can be used to read and write data without actual data (although connecting a datagram socket can be faster since you avoid security checks). Datagram sockets can be effectively used using both state transitions listed for children based on TCP and server channels described above.