1

リモート PC に複数の UDP パケットを連続して送信しています。問題は、データ量が多すぎる場合、チャネル間のどこかのデバイスでバッファ オーバーフローが発生することです。UDP パケットの送信レートを制限/調整/制御するつもりです。誰かが最適なレート送信間隔を見つける方法についてのガイドを教えてもらえますか?

ところで、udp よりも tcp を推奨するのはやめてください。目的はデータを確実に送信することではなく、最大スループットを測定することです。

4

3 に答える 3

2

次にこれを試してください：

  • 1KB サイズのパケットから始めます (たとえば)。
  • それらについては、1 秒あたりに送信できるパケット数を計算します。たとえば、1GB イーサネット = 100MBytes の raw 帯域幅 -> 100000 パケット
  • 最初の4バイトがシリアル番号になるようにパックを作成し、残りは何でもかまいません-ここでテストしている場合は、ゼロまたはノイズ（ランダムデータ）で埋めてください
  • 送信側では、パケットを作成し、レート (以前に計算された) の速度で 1 秒間プッシュします。費やされた時間と残りの時間を計算Sleep()し、新しいタイムスロットを待ちます。
  • 受信側でパケットを収集し、シリアル番号を調べます。パケットが欠落している場合は、(別の接続で) 送信者に情報を送信します。
  • 送信者は、失われたパケットに関する情報について、次のようなことを行う必要がありますRATE = RATE * .9-送信レートを以前の90％に減らします
  • 「失われたパケット」メッセージが表示されない場合、送信者は数秒ごとにレートを徐々に上げる必要があります (たとえば 1%)。
  • しばらくすると、RATEは最初に望んでいたものに収束します

いくつかの考慮事項: - バック接続が TCP の場合、そこにいくらかのオーバーヘッドが発生します - バック接続が UDP の場合、ここでパケットをドロップすることもでき (チャネルをフラッディングしているため)、送信者はパケットがドロップされたことを知ることができません - アルゴリズム上記の方法では、データの欠落やデータの順序が正しくない問題は解決されません。スループットを測定するだけです。

于 2010-11-16T06:03:29.647 に答える
2

試行錯誤。点。

  • 制御コマンドを送信するためだけに使用する secnod 接続 (UDP または TCP ベース) を作成します。
  • 失われたパケットなどに関する統計情報をそこに送信します。次に、データレートが高すぎるかどうかを判断できます。
  • 低いパケットから始めて、欠落しているパケットが表示されるまでデータ レートを上げてください。

絶対に (!) すべてのパケットが到着すると仮定しないでください。意味: 欠落しているパケットを再要求する (!) 方法が必要です。完璧な環境下でもパケットが失われることがあります。

損失が問題なく、最小限に抑える必要がある場合、統計的アプローチがこれを処理する唯一の方法だと思います。

于 2010-11-15T07:11:10.833 に答える
1

TCP over UDP を提案しないというあなたの提案にもかかわらず、私はしなければなりません。同じ段落で、テストの主な目的はスループット (帯域幅) を測定することであり、TCP スタック全体を再発明せずに適切に行う唯一の方法は、実際に TCP スタックを使用することであると述べています。

TCP の大部分は、フロー制御の問題に対処するように設計されており、TCP ストリームを使用すると、必要なものを正確に取得できます。特定の接続の最大帯域幅を簡単に「温水発明」なしで取得できます。

この答えがあなたに合わない場合、それはおそらく、問題に関する要件を再度述べなければならないことを意味します。彼らは対立しています。

于 2010-11-15T09:55:20.263 に答える