この本は、背面に接続された構成要素を紹介し続けています。
紹介ChannelHandler
ChannelHandler成分は、コアビジネス処理ロジックを含む、コンテンツは、ユーザ定義、開発者コードナインChannelHandlerのパーセントです。網状ChannelHandlerからChannelHandlerによって定義される2つの重要なサブインターフェースを提供します。
すべての着信データとステータス変更イベントを処理する（受信チャネルが読み出し操作等によってトリガイベントを指す） - ChannelInboundHandler
ChannelOutboundHandlerは - （アウトバウンド書き込み動作がユーザによってトリガイベントを指し、イベントがリモートサーバーに送信される）傍受の各種操作を可能にし、アウトバウンド・データを処理します
ChannelHandlerクラス階層を見て：
このようChannelHandler、デフォルトのアクションの多くを提供アッパークラスアダプタクラス、多くの多くの方法がありますが、私たちは時々、すべてをオーバーライドする必要があり、ユーザー定義の方法は、あなただけはアダプタクラスを使用することができ、1つのまたは2つのメソッドをオーバーライドする必要があり、それは、多くのデフォルトのメソッドが含まれています。フレームワークのもう一方の端はまた、アダプタクラスを働いているので、大きいです。我々はネッティー、ChannelHandlerを達成するために、多くの場合、少しの直接インタフェースを使用するときに、多くの場合、アダプタクラスを継承しています。
チャネルのライフサイクル
いくつかのメソッドをオーバーロードされたとき、私たちは、これらのライフサイクルの一部である、入門の例を記述します。イベントのライフサイクルの各段階を結合するので、我々は、チャネルのライフサイクルを理解する理由は、我々は、処理のためにこれらのイベントに対処することである主な内容Handlerクラスをこのイベントをキャプチャすることができます。私たちは、チャンネルのステータスを見て：
状態間の次の遷移は以下のとおりです。
上記の状態やイベントの4種類が、私たちは入門の例を確認する必要があり、クライアントがリモートサーバーに接続されているアクティブな状態であるチャネルである、我々は一つのことをやる、それがメッセージを送信することです：
これは、状態遷移時のチャネルは、ストップアウトバウンドクラスは、これらのクラスの後に継承された私たちのハンドラを聞くことができたときに、あるイベント、過負荷を処理することができます。
ChannelHandler ChannelPipeline、またはChannelPipelineから除去するために添加した場合、対応するイベントは、対応するメソッドが呼び出されるまで聴取されるいくつかの状態の変換が存在することになります。
チャネル状態の変化を関連し、通話やデータを受信したときステーションは、たくさん持っているときChannelInboundHandlerメイン処理インバウンドのイベントは、イベントが発生します。ChannelInboundHandlerライフサイクルライフサイクルとチャンネル近く、多くのミドルおよびビジネス関連のイベントがあります。
ここから私たちは、私たちの入門の例では、処理された読み取りイベントをよく知られている方法の多くを参照してください。対応するイベントを処理するビジネスニーズを持っている場合こちらとき、私たちはあなたがハンドラを書くことができ、対応するメソッドをオーバーライドします。同様に、ChannelOutboundHandler、多くのメソッド、およびイベントがあります。
ChannelPipelineコンポーネント
ChannelInboundHandlerとChannelOutboundHandlerを理解し、我々は見てChannelPipelineを取ります。ChannelPipeline ChannelHandlerは、インバウンドおよびアウトバウンドのイベントチャネルを通って流れ、各チャネルはChannelPipelineを有し、実際にインターセプトするために使用されるChannelHandlerインスタンスのシリーズを含む容器であり、我々は、処理クラスを追加するためのチャネルを与える、ChannelPipelineによって改変することができます動的に追加し、インバウンドとアウトバウンドのイベントに応答するために豊富なAPI呼び出しを定義ChannelHandlerを、削除します。
当社独自のハンドラの定義もそれに追加されます：
上記の方法を呼び出すことができる3つの動作のこの複数個。
ChannelHandlerContextコンポーネント
問題は、パラメータハンドラが渡す方法、接続が確立され、ありますか？それは渡すChannelHandlerContextです。ChannelHandlerContextはChannelHandlerは、2つのChannelPipeline関係ChannelHandlerContextショーを作成追加、ChannelHandlerとChannelPipelineとの間の関連を示し、
ChannelHandlerContext各ChannelHandlerに対応しているので、実際ChannelHandler間にリンクが存在しない、ChannelHandlerContextによって一緒に連結されています。エントリ、イベントを読み込む処理時間の私達の例では、またChannelHandlerContextによってパラメータを取得することがあることを忘れてはならない印象を持っています：
プロセスの概要
上記のプロセスの概要を大まかにまとめることができ、サーバはEventLoopGroup、各EventLoopGroupは、多くのイベントループ、チャネルの多くを登録し、各イベントループがセレクタ、セレクタがあり、私たちのネッティーサーバーは接続が1チャネルで受信しました各チャネルはChannelPipelineを有し、そしてChannelPipelineはインスタンスChannelHandlerの数内に格納され、ChannelHandler容器です。ChannelHandlerの例では、我々がビジネスクラスを扱っているものです。私たちは、チャネルがどのように文字列を一緒に、たくさんChannelHandlerを有することがありますか？実際には、直直接ChannelHandlerContextに各ChannelHandlerの対応に関連しない複数ChannelHandler横切って、ChannelHandlerContextの接続関係があり、よりChannelHandlerは、それぞれ対応するChannelHandlerContextに連結頼ります。ビューの流動点：
なぜChannelHandlerContextは双方向ですか？実際にChannelPipelineは、インバウンドとアウトバウンドオペレーションを含むリストの上にある、確かに異なる方向の内と外、それがインバウンド業務であれば、私はちょうど全体のリストを見てそう、例えば、ChannelHandlerContext間の双方向でありますInBoundHandlerは、OutBoundHandlerはそう言って、インバウンドとアウトバウンドのではなく、二つの鎖の、チェーンに配置されます、スキップします会いました。
プログラム例
サーバーのプログラム、同じプロセス、外観の例で見てみましょう：
このコードの内部と実質的エントリの同じ基本的な例が、2つのチャネル構成が複数、遮断することは、keepalivedのであり、128です。私たちは、channelpipline設定を見て：
ServerHandlerプロトコルを符号化及び復号化に見ることができる上に最下層のクラスまたはビジネスプロセス、およびStringEncoder StringDecoder、それはトップDelimiterBasedFrameDecoderデコーダであり、この後者のパラメータデコーダ（8192、Delimiters.lineDelimiter（） ）、ロウデコーダによるものである、TCPパケットは、改行記号としてNメッセージに、来る8192へのデータのサイズは、例えば、パケット廃棄を入れ、ない場合、パケットは、次のようになります。
このISN Aネッティーworldn
つまり、二つのパッケージです。
私たちは、ハンドルの内側ServerHandlerを見ます
このプロセスは、プリントアウトした後、ライトバックに戻って、プラス改行の終わりされ、非常に単純な、channelRead方法です。ctx.channel（）。[リモート（）は、リモート接続のアドレスを示します。この方法は、フラッシュは、ネットワークに送信され、プリントサーバが完了読み込み、channelReadCompleteが完了読み出しを表します。
クライアントコードと実質的にエントリの例と同じです。
これは、また、より多くの3つのプロセッサのを払っているpiplineであり、コンテンツ、サーバーは基本的に同じであるクライアントハンドラのコードチャネルの内側とは異なります。
マルチオーバーロードされ、私たちはライフサイクルの前で話すの対応する状態を見ることができるのいくつかのクライアントハンドラメソッドの後、channelRegistered方法が成功した登録情報の後に印刷され、channelActiveは、印刷情報をアクティブにし、リモートチャネルに接続することですハローを送信する、channelReadはクライアントから情報を読み取るがコンソールに印刷した後、サーバから返され、その後、サーバーに送信されると、channelReadComplete伝送方法は、異常が発生した場合exceptionCaught方法動作を示し、読み出し及び背面印刷されています我々は結果で、サーバーとクライアントの外観を開始します。
改行文字列ハローを除去した場合、クライアントとサーバの両方が見る、互いに無限ループ効果送信もたらす、他端にメッセージバックを受信したため、上部で送信N個の第1のハローメッセージの後結果で：
最初のハンドラプログラムは、データパケットに基づいて、改行で区切られているため、印刷を見ることができない、これはプログラムは、メッセージが終わっていないと信じているので、ここでのメッセージは、何も改行されていない、この時間は、最初のハンドラ内で立ち往生となります内部には、以下の文字列が合意に達することはありませんが、中にServerHandlerを来ることはありません。これはまた、パッケージの終わりではありませんネットワークプログラミングの半分パック問題であり、完全なものではありません。
加算処理の順序に従ってpiplineハンドラは、我々の方法をaddLast実行されます。
これは、いくつかのハンドラの順序を決定します。
コードのアドレスします。https：//gitee.com/blueses/netty-demo 07
ブログ記事複数のプラットフォームからこの記事OpenWriteリリース！