利用可能な最大のアップロードとダウンロードを計算し、プログラムの使用をその割合に制限する必要があるという問題があります。ただし、最大値を見つける良い方法は思いつきません。
現時点で私が思いつく唯一の解決策は、クライアントとサーバー間で数メガバイトを転送し、転送にかかる時間を測定することです。ただし、この解決策は非常に望ましくありません。100,000 クライアントの場合、サーバーの帯域幅使用量が大幅に増加する可能性があるためです (これはすでに高すぎます)。
誰にもこの問題の解決策はありますか?
私が主に関心を持っているのは、ISP のネットワークを離れる時点までに転送されるデータの制限です。これは、他のプログラムの通信を低下させるボトルネックが発生する可能性が最も高いと思います。ただし、間違っている場合は修正してください。
編集：さらに調査した結果、これは可能ではないと思います。ISP のネットワークを離れるときの最大転送速度を正確に測定するには、変数が多すぎます。ただし、誰かが正確な解決策を思いついた場合に備えて、質問を開いたままにしておきます。
コードを Windows Vista 以降に制限できる場合 (可能性は低いですが、誰にもわかりません)、 と を使用しSetPerTcpConnectionEStatsて、Windows に接続の帯域幅を推定させ、後でその推定値を取得できます。次に、その見積もりに基づいて、使用する帯域幅を調整できます。GetPerTcpConnectionEStatsTCP_ESTATS_BANDWIDTH_RW_v0
したがって、現在と同じようにアプリケーションの実行を開始し、しばらく統計を収集してから、その最初の期間に測定したものに基づいてスロットリングを課すことになります。
これには、帯域幅情報を収集するためだけに余分なデータを送信することを回避できるという利点があります。とにかく、送信しているデータに関する統計を収集するだけです。利用可能な帯域幅の推定値を取得するまで、全帯域幅に近いものを使用するという欠点があります (これはほぼ避けられないと思います)。まだ普遍的に利用可能です）。
接続の両端に Windows デバイスがある場合は、バックグラウンド インテリジェント転送サービス (BITS) を使用して情報を移動し、帯域幅の問題全体を回避できます。(ほぼ) 常にインストールされるコンポーネントについては、http://msdn.microsoft.com/en-us/library/aa362708(VS.85).aspxで説明されています。
帯域幅の使いやすさが必要なのか、単にコストの問題なのかについては言及していないため、これは適切ではない可能性があります.
問題が生の帯域幅である場合、フィードバック メカニズムがここで機能する可能性があります。セッションを開始すると、サーバーはデータを送信するレートをクライアントに伝えます。クライアントは、データを受信する速度を監視できます。受信したデータのレートがデータの送信レートよりも低い場合 (ここでは、90% 以下などのしきい値を使用できます)、クライアントはサーバーにデータ レートを下げてプロセスを再開することを通知します。これは、基本的な QoS メカニズムとして機能します。
接続の遅延やジッターが大きいことが問題である場合は、より小さなパケット (実際の IP/TCP パケット) で情報を送信してみてください。通常、システムは最大パケット サイズを使用しようとしますが、インターネット上のパケットの断片化によってトラフィックが遅延する可能性があります。それでもレイテンシが改善されない場合は、TCP の代わりに UDP を使用するようにフォールバックできます。ただし、これではデータ配信が保証されません。
1 つのオプションは、 uTorrent の UDP トランスポート プロトコルのようなものをクライアントとサーバーの間に実装して、遅延を抑えることです。生のスループットを測定するだけでは、他のプロセスが帯域幅を使用し始めて、空き帯域幅が減ってしまうと役に立ちません。
私が見る唯一の答えは次のとおりです。
問題を複雑にするいくつかの問題:
クライアントは他のタスクを実行している可能性があり、ホスト (送信マシン) は別のタスクを実行している可能性があるため、転送速度は異なります。
データのチャンクを送信してタイミングを計ること、別のデータを送信してタイミングを計ることに投票します。これらの期間を累積し、チャンク数の平均をとります。これにより、動的なタイミングが可能になり、事前に計算されたタイミングよりも正確になります。