接続が多すぎると、送信クライアントのTCPポートがブロックされる

Question

Windowsのターゲットクライアントマシンでファイル操作を実行し、シェルコマンドを実行するための配布システムがあります。私はカスタムTCPエンドポイントを使用して、サーバー上のWindowsサービスに接続します。

私はこのツールを作成して、あるマシンにそのエージェント（クライアント）の多数のインスタンスを作成し、それらのすべてに対してサーバーから特定のジョブセットを実行しました。問題は、クライアントマシン上のすべての発信TCPポートが数百を超えるエージェントを起動した後にブロックされることです。各エージェントは動的ポートを使用しており、単一のサーバーポートをリッスンしています。

2000-3999のポートで2000エージェントが稼働していて、すべてがサーバーのポート5111をリスンしているとします。

TCP/IPを選択 ローカルエンドポイントは、最近、同じリモート エンドポイントに接続するために使用されたため、発信接続の確立に失敗しました：私は、Windowsイベントログに受信してい エラーメッセージは次のようになります。このエラーは、通常、発信接続が が高速で開閉する場合に発生し、利用可能なローカルポートをすべて にし、TCP/IPで発信用のローカルポートを再使用するように強制します。 データ破損のリスクを最小限に抑えるために、TCP/IP 標準では、指定されたローカルエンドポイントから特定のリモートエンドポイントへの連続した接続の間に最小限の時間が必要です。

これが発生すると、このマシンはTCPポートをもう使用できなくなります。レジストリのTCPデフォルト動作の一部を変更しようとしましたが、役に立たなかったのです。接続を開く間隔は1〜5秒です。

最適な遅延を管理するための回避策は、テストに必要な積極的なネットワークアクティビティに関係なく、アプリケーションを信頼できるものにしますか？

Answer 1

間に適切な間隔を置かずに接続を開くと、攻撃的な動作のためにクライアント上のすべてのポートがブロックされます。最後に、1000ミリ秒から3000ミリ秒までの各接続の間の遅延を増やして、すべてのエージェントを接続する必要があります。私はまだこれのダイナミクスを把握していますが、おそらくプロセスではなく並列スレッドでエージェントを開く方が良いソリューションになるでしょう。同じ名前のプロセスが多数あるように見えても、OSには魅力的ではないようです。