4

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.

Kevin Sitze
  • 8,029
  • 3
  • 16
  • 19

1 Answers1

4

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.

Kevin Sitze
  • 8,029
  • 3
  • 16
  • 19
  • good review, thanks, is it based on some tcp articles or just reading netty sources? – yetanothercoder Jun 28 '13 at 09:04
  • and a question: if I need to count active connection count that client does to remote peer, will it be enough to increment in `channelConnected` and decrement in `channelDisconnected`? Will the counter be exact in case of `keep-alive` connections and other features? Thanks! – yetanothercoder Jun 28 '13 at 09:07
  • I read the source for the details. Figured I'd save someone else the bother in case they have similar questions. WRT active connection count, it is indeed enough to increment your counter in `channelConnected` and decrement it in `channelDisconnected`. The HTTP keep-alive and similar protocol-on-TCP constructs have no effect on Netty except indirectly as the application controls the socket connections. – Kevin Sitze Oct 22 '13 at 02:51