7

約 400 kbps の RTP ストリームを提供する C++ アプリケーション (Linux 上で実行) を作成しました。ほとんどの宛先ではこれで問題なく動作しますが、一部の宛先ではパケット損失が発生します。問題のある送信先は一般的に接続が遅いようですが、送信しているストリームには十分な速度であるはずです。

これらの宛先は、パケット損失なしで他のアプリケーションの同様の RTP ストリームを受信できるため、アプリケーションに問題がある可能性があります。

私はすでにいくつかのことを確認しました: - tcpdump で、すべての RTP パケットが送信側のマシンで送信されていることがわかります - UDP 送信バッファーが配置されています (64KB から 300KB の間のサイズを試しました) - RTP パケットはほとんど 1400 バイト未満のままです断片化を避けるために

パケット損失の可能性を最小限に抑えるために送信側アプリケーションができることと、そのような状況をデバッグする最善の方法は何ですか?

4

5 に答える 5

9

大きなバースト チャンクでパケットを送信しないでください。

パケット損失は、通常、パケット バッファ サイズが制限された低速のルーターが原因で発生します。遅いルーターは、別の 10 パケットを受信する前にたとえば 10 パケットを送信する時間があれば、1 Mbps を問題なく処理できるかもしれませんが、100 Mbps の送信側が 50 パケットの大きなチャンクを送信すると、ドロップするしかありません。それらの40。

各時間帯に必要なものだけを書くように、送信を広げてみてください。5 秒ごとに 1 パケットを書き込む必要がある場合は、1 秒あたり 5 パケットではなく、そのようにします。

于 2010-04-27T18:46:40.123 に答える
6

netstat には、状況をデバッグするための便利なオプションがいくつかあります。

1 つ目は netstat -su (UDP 統計のダンプ) です。

dima@linux-z8mw:/media> netstat -su                                                      
IcmpMsg:                                                                                 
    InType3: 679
    InType4: 20
    InType11: 548
    OutType3: 100
Udp:
    12945 packets received
    88 packets to unknown port received.
    0 packet receive errors
    13139 packets sent
    RcvbufErrors: 0
    SndbufErrors: 0
UdpLite:
    InDatagrams: 0
    NoPorts: 0
    InErrors: 0
    OutDatagrams: 0
    RcvbufErrors: 0
    SndbufErrors: 0
IpExt:
    InNoRoutes: 0
    InTruncatedPkts: 0
    InMcastPkts: 3877
    OutMcastPkts: 3881
    InBcastPkts: 0
    OutBcastPkts: 0
    InOctets: 7172779304
    OutOctets: 785498393
    InMcastOctets: 525749
    OutMcastOctets: 525909
    InBcastOctets: 0
    OutBcastOctets: 0

「RcvbufErrors」と「SndbufErrors」に注意してください

追加のオプションは、プロセスの送受信 UDP バッファーを監視することです。

dima@linux-z8mw:/media> netstat -ua
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
udp        0      0 *:bootpc                *:*
udp        0      0 *:40134                 *:*
udp        0      0 *:737                   *:*
udp        0      0 *:mdns                  *:*

ここで、関心のある接続の Recv-Q および Send-Q 列を確認する必要があります。値が高くてゼロにならない場合、プロセスは負荷を処理できません。

これらのコマンドは、送信側と受信側のマシンで使用できます。

また、traceroute と ping を組み合わせたmtrを使用することもできます。これは、ルート内の各ホップに対して ping を実行します。これにより、ルートの低速ホップが検出される場合があります。他のマシンで実行して、2 番目のマシンへの接続を確認します。

于 2010-04-27T18:46:05.187 に答える
4

RTPは通常、本質的に損失が多いUDPを使用します。パケットは送信者と受信者の間のどこかで失われる可能性があるため、ローカル デバッグでは役に立たないことが示されます。

やるべきことは明らかです：

  • a: 全体的なデータ レートを下げる
  • b: 数秒ごとに 1 つの巨大なチャンクを送信するのではなく、小さなパケットをより頻繁に送信することにより、「ピーク」データ レートを下げます。つまり、UDP 送信バッファを減らします - たぶん 1400 バイトまでです。
  • c: RTP の TCP バリアントに切り替えられるかどうかを確認します。

他のすべてが失敗した場合、WireSharkはあなたの味方です。どのくらいの量のデータが、いつアプリから送信されているかを正確に把握できます。

于 2010-04-27T19:33:14.030 に答える
0

パケットを送信する速度を下げてみてください。遅い接続はあらゆる種類のことを意味する可能性があり、高速でパケット (小さいまたは大きい) を送信しようとしても役に立ちません。

于 2010-04-27T18:11:18.467 に答える
-3

これはあなたが望む答えではないかもしれませんが、パケット損失の問題が発生した場合は、アプリケーションを TCP を使用するように切り替えて、パケット損失のほとんどの心配を取り除こうとします。

于 2010-04-27T18:02:30.587 に答える