java.netとjava.nio

Question

どの時点でjava.netからjava.nioに切り替えるほうがよいですか？ .net（Microsoftエンティティではない）は理解しやすく、より馴染みがありますが、nioはスケーラブルで、いくつかの特別な機能が追加されています。

具体的には、この状況を選択する必要があります。複数のリモートサイトでハードウェアを管理する1つのコントロールセンターがあります（各サイトに複数のハードウェアユニット（トランシーバー、TNC、ローテーター）を管理する1台のコンピューターがあります）。私のアイデアは、コントロールセンターから無線ハードウェアへのゲートウェイとして機能し、各ユニットに1つのソケットを持つ、各マシンにサーバーアプリを作成することでした。私の理解では、NIOは1つのサーバー、多くのクライアントを対象としていますが、私が考えているのは1つのクライアント、多くのサーバーです。

3番目のオプションはMINAを使用することですが、単純な問題でそれが多すぎるかどうかはわかりません。

---

各リモートサーバーには、すべて同じクライアントからの最大8つの接続があります（すべてのハードウェアを制御し、TX / RXソケットを分離します）。ただし、単一のクライアントは一度に複数のサーバーに接続する必要があります。各サーバーを異なるポートに配置する代わりに、クライアント側でチャネルセレクターを使用することは可能ですか、それともクライアント側でマルチスレッドioを使用してサーバーを異なる構成にする方が良いですか？

---

実際、リモートマシンは他のハードウェアと対話するためだけに使用されるため、RMIまたはIDL / CORBAの方が優れたソリューションでしょうか。本当に、コマンドを送信し、ハードウェアからテレメトリを受信できるようにしたいだけで、それを行うためにアプリケーション層プロトコルを作成する必要はありません。

Answer 1

スケーラビリティにより、おそらくパッケージの選択が促進されます。 java.netでは、ソケットごとに1つのスレッドが必要です。コーディングは非常に簡単になります。 java.nioははるかに効率的ですが、コードを作成するのは面倒です。

処理する接続数を自問します。比較的少ない場合（たとえば<！> lt; 100）、java.netを使用します。

Answer 2

使用する正当な理由がない限り、NIOは使用しないでください。 あまり面白くなく、あなたほど有益ではないかもしれません考えるだろう。数万の接続を処理するとスケーラビリティが向上する場合がありますが、数が少ない場合は、IOをブロックすることでスループットが向上する可能性があります。いつものように、後悔するかもしれないことにコミットする前に、独自の測定を行います。

他に考慮すべきことは、SSLを使用したい場合、NIOが非常に苦痛になることです。

Answer 3

現在、この種のネットワークコードをゼロから作成する理由はほとんどありません。 netty.io のようなパッケージは、ほとんどの場合、手作りのソリューションよりも少ないコード行で、より信頼性が高く柔軟なコードを取得します。意志。また、Nettyを使用すると、実装を複雑にすることなくSSLサポートを利用できます。 nettyのようなライブラリも、<！> quot; async vs threads <！> quot;を不要にします。ほぼ完全に質問し、優れたパフォーマンスを提供し、必要に応じてスレッドモデルを調整できます。

Answer 4

話している接続の数から、java.netを使用する必要があることがわかります。本当に、タスクをノンブロッキングI / Oで複雑化する理由はありません。 （リモートシステムの能力が不足している場合を除き、なぜJavaを使用しているのですか？）

ApacheのXML-RPC パッケージをご覧ください。使い方は簡単で、ネットワーク関連のものを完全に隠し、優れたHTTPで動作します。プロトコルの問題を心配する必要はありません...それはすべて、両端でメソッド呼び出しのように見えます。

Answer 5

関係する接続の数が少ないことを考えると、java.netは適切なソリューションのように思えます。

他のポスターは、XML-RPCの使用について話しました。これは、出荷されるデータの量が少ない場合に適していますが、大量のデータを出荷するプロセス間通信（たとえば、大きな要求/応答、または頻繁に少量のデータ）。通常、XML解析のコストは、最適化されたワイヤ形式（ASN.1など）よりも桁違いに高くなります。

低ボリューム制御アプリケーションの場合、XML-RPCのシンプルさがパフォーマンスコストを上回るはずです。大量のデータ通信を行うには、より効率的なワイヤープロトコルを使用することをお勧めします。