Netty チャネルには複数の状態がありますが、実際の状態遷移に関するドキュメントは見つかりません。Netty 3.2.x システムで見つけることができる、これに関するドキュメントに最も近いものは hereです。
ここで、チャネルが取りうる状態を見つけることができまし た。
ただし、ある状態から別の状態へのチャネルの通常の遷移について説明するものは何もありません。すべてのチャネルが可能なすべての状態遷移を行うわけではないようです。
実際、異なる Netty チャネルには異なる状態遷移があります。
一般に、TCP ベースのサーバー チャネルで可能な状態遷移は次のとおりです。
OPEN -> ( BOUND -> UNBOUND )* -> CLOSE
パイプラインでSimpleChannelHandlerサブクラスを使用している場合、これらの状態変化のいずれかが発生したときにアップストリーム イベントを処理するための同等のメソッドは次のとおりです。
channelOpen
channelBound
channelUnbound
channelClose
サーバー チャネルがCONNECTED状態になることはありません。
サーバー チャネルが UNBOUND 状態に移行すると、BOUND 状態に戻ることはめったにありませんが、これはYMMV のアプリケーションに依存しているようです。
サーバー チャネルは、子チャネルが開いたり閉じたりしたときにイベントを発生させることができることに注意してください。これらのイベントは、サーバー チャネルがBOUND状態になった後にのみ発生します。これらのイベントがサーバー チャネルに代わってアップストリームに送信されると、 SimpleChannelHandlerサブクラスの次のメソッドが呼び出されます。
childChannelOpen
childChannelClosed
TCP ベースの子チャネルとクライアント チャネルの可能な状態遷移は次のとおりです。
OPEN -> ( BOUND -> ( CONNECTED -> DISCONNECTED )* -> UNBOUND )* -> CLOSE
最初にCONNECTED状態に移行することは 、チャネル コード内では強制されていないようです。ただし、この状態は、チャネルがCONNECTED状態に移行する前に、Netty フレームワーク内の子チャネルとクライアント チャネルの両方に対して常に最初に起動されます。
パイプラインでSimpleChannelHandlerまたはそのサブクラスを使用している場合、同等のメソッドは次のとおりです。
channelOpen
channelBound
channelConnected
channelDisconnected
channelUnbound
channelClose
TCP ベースのチャネルは、チャネルに対して読み取りまたは書き込みを行う前に、CONNECTED状態になっている必要があります。これには、読み取りも書き込みもできないサーバー チャネルが含まれます。サーバー チャネルは常に、サーバーに代わって接続操作を管理するためだけに使用されるため、それほど驚くことではありません。
データグラム ソケットは、実際に接続しなくてもデータの読み書きに使用できるという点で、TCP ベースのソケットとは動作が異なります (ただし、セキュリティ チェックを回避するため、データグラム ソケットの接続は高速になります)。データグラム ソケットは、上記の TCP ベースの子チャネルとサーバー チャネル用にリストされた状態遷移の両方を使用して効果的に使用できます。