Question

Netty channels have multiple states but I am unable to find any
documentation on the actual state transitions. The closest to any
documentation on this that I could find for Netty 3.2.x system is
here.

I was able to locate the possible states that a channel can be in
here.

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

Answer 1

Different Netty channels do indeed have different state transitions.

In general the possible state transitions for TCP based server
channels are:

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

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

channelOpen
channelBound
channelUnbound
channelClose

Server channels never move into the CONNECTED state.

Server channels rarely move back into the BOUND state once they
move into the UNBOUND state, however this appears to be dependent
on the application so YMMV.

Note that server channels can fire events when a child channel is
opened 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 then the following methods on
your SimpleChannelHandler subclass are called:

childChannelOpen
childChannelClosed

The possible state transitions for TCP based child and client channels
are:

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

It appears that moving into the CONNECTED state first is not
enforced within the channel code; however this state is invariably
fired first for both child and client channels within the Netty
framework before the channel is moved into the CONNECTED state.

If you are using SimpleChannelHandler or a subclass thereof in
your pipeline the equivalent methods are:

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,
which can never be read from or written to, which is not much of a
surprise as server channels are invariably used only for managing the
connect operation on behalf of the server.

Datagram sockets operate differently than TCP based sockets in that
they can be used to read and write data without actually being
connected (though connecting a datagram socket can be faster as you
avoid security checks). Datagram sockets can be effectively used
using both of the state transitions listed for TCP based child and
server channels described above.