6

一度に数時間 (おそらく > 24) さまざまなサーバーへの TCP 接続を維持 (または試行) する Scala アプリケーションがあります。各サーバーは、約 30 文字の短いメッセージを 1 秒間に約 2 回送信します。これらのメッセージは iteratee に送られ、そこで解析され、最終的にデータベースの状態が変更されます。

これらの接続のいずれかが何らかの理由で失敗した場合、別の方法で指定するまで、アプリは継続的に再接続を試みる必要があります。メッセージが失われるのは悪いことです。接続するサーバーや使用するプロトコルを制御できません。

一度に 300 もの接続があると考えられます。正確には高負荷のシナリオではないので、NIO は必要ないと思いますが、あるといいかもしれません。アプリの他のビットは高負荷です。

これらの接続を可能な限り確実に維持できる、ある種のソケットコントローラー/マネージャーを探しています。現在、独自のブロッキング コントローラーを実行していますが、ソケット コーディング (およびさまざまな設定、オプション、タイムアウトなどすべて) に慣れていないため、可能な限り最高の稼働時間を達成できるとは思えません。さらに、将来的には SSL サポートが必要になるかもしれません。

NIO は実際に利点を提供しますか?

ここではNettyが最良の選択でしょうか? Uptime の例をここで見たことがあり、単純に複製することを考えていましたが、下位レベルのネットワークに慣れていないため、より良いオプションがあるかどうかわかりませんでした。

4

1 に答える 1

1

ただし、失われるパケットをできるだけ少なくするための最善の戦略については確信が持てず、これはいずれかのライブラリで「解決済み」の問題になると想定していました。

うん。JMS がその例です。

その多くは、タイムアウトの推測戦略に帰着すると思いますか? ソケットを閉じて再度開くのが早すぎると、途中のパケットが失われます。

それは正しいです。特に接続が定期的に上下する場合、そのアプローチは信頼できません。

実際の解決策には、受信した内容を相手側に追跡させ、接続が再確立されたときに送信者に知らせることが含まれます。それができない場合、失われる量を制御する実際の方法はありません。(これは、信頼できるメッセージング サービスが行うことです ...)

接続するサーバーを制御できません。したがって、JMS を一般的な TCP ストリームに適合させる別の方法がない限り、うまくいかないと思います。

うん。これを手動で実装しようとすると、同じことが当てはまります。相手は協力しなければなりません。

各リモートサーバーで JMS エンドポイントを (たとえば) 実行し、エンドポイントが UNIX ドメインソケットまたはループバック (つまり 127.0.0.1) を使用してサーバーと通信するようなものを作成できると思います。ただし、メッセージが失われる可能性は依然としてあります。

于 2012-10-22T11:21:01.620 に答える