RFC 3393 (Ipdv パケット遅延変動) を C で実装するにはどうすればよいですか?

Question

私は一方の側からパケットを送信し、もう一方の側でパケットを受信するイーサネットアプリケーションを構築しています。RFC 3393のように受信側でパケットの遅延を計算したいと考えています。したがって、送信者側でパケットにタイムスタンプを挿入し、パケットを受信したらすぐに受信者側でタイムスタンプを取得する必要があります。値 i を減算するとタイムスタンプの差が得られ、この値と後続の差 i を減算すると、一方向 ipdv 遅延が得られます。 両方のクロックが同期していません。 ご協力をよろしくお願いいたします。ありがとう。

Answer 1

RFC 3393 は、 分散 遅延そのものを測定するためのものではなく、パケット遅延の中で使用されます。

例を挙げると、次のようになります。あなたはビデオストリーミングアプリケーションを作成しています。バッファリングするビデオ データをできるだけ少なくする必要があります (ビデオができるだけ早く再生を開始できるように)。データは常に常にあるとしましょう いつも マシン A からマシン B に到達するのに 20 ミリ秒かかります。この場合 (マシン A が再生に必要な速度でビデオ データを送信できると仮定すると)、バッファはまったく必要ありません。最初のフレームを受信するとすぐに、次のフレームが必要になるまでにそのフレームが到着していることがわかっているので、安全にプレイを開始できます (データが到着するまでに常に正確に 20 ミリ秒かかり、マシン A は少なくとも次のフレームを送信しているため)プレイしているときと同じくらい速くなります）。

これは、20 ミリ秒がどれだけ長くても、常に同じである限り機能します。1000 ミリ秒になる可能性があります。最初のフレームが到着するまでに 1000 ミリ秒かかりますが、到着したらすぐにプレイを開始できます。次のフレームも 1000 ミリ秒かかり、最初のフレームの直後に送信されるためです。つまり、フレームはすでに開始されています。しばらくの間ここに来るでしょう。明らかに現実の世界はそうではありません。

もう一方の極端な例を考えてみましょう。ほとんどの場合、データは 20 ミリ秒以内に到着します。ただし、5000 ミリ秒かかる場合は除きます。バッファを保持せず、フレーム 1 ～ 50 の遅延が 20 ミリ秒の場合、最初の 50 フレームは問題なく再生できます。その後、フレーム 51 が到着するまでに 5000 ミリ秒かかり、5000 ミリ秒の間ビデオ データが存在しない状態になります。ユーザーは、かわいい猫の動画を求めて別のサイトにアクセスします。本当に必要なのは 5000 ミリ秒のデータのバッファーでした。それがあれば問題ありません。

長い例と短いポイント:あなたは何に興味がありませんか 絶対 パケットの遅延とは何か、興味があるのは、 分散 その遅延の中で、それはバッファーの大きさが必要であるということです。

測定するには 絶対 遅延がある場合は、両方のマシンのクロックを同期させる必要があります。マシン A はタイムスタンプ 12337849227 のパケットを送信します。 28 そしてそれがマシン B に到着したとき、時刻は 12337849227 でした。 48, 、パケットが到着するまでに 20 ミリ秒かかったことがわかります。

しかし、あなたはそれに興味があるので、 分散, 、(RFC 3393 に記載されているように) マシン A からのいくつかのパケットが必要です。マシン A がタイムスタンプ 1233784922 のパケット 1 を送信します。 72 8、その後 10 ミリ秒後にタイムスタンプ 1233784922 のパケット 2 を送信します 73 8、その後 10 ミリ秒後にタイムスタンプ 1233784922 のパケット 3 を送信します 74 8.

マシン B は、タイムスタンプ 1233784922 と思われる時刻にパケット 1 を受信します。 12 8.この場合、マシン A とマシン B の間の一方向の遅延は (マシン B の観点から) -600 ミリ秒です。これは明らかにまったくのゴミですが、私たちは気にしません。マシン B は、タイムスタンプ 1233784922 と思われる時刻にパケット 2 を受信します。 15 8.片道の遅延は -580ms になりました。マシン B は、タイムスタンプ 1233784922 と思われる時刻にパケット 3 を受信します。 16 8.片道遅延は再び -580ms でした。

上記のように、絶対的な遅延がどのくらいであるかは気にしません。したがって、それがマイナスであるか、3 時間であるかなども気にしません。ここで気になるのは、遅延量が 20ms 変化していることです。したがって、20ms のデータのバッファが必要です。

ここではクロック ドリフトの問題を完全に無視していることに注意してください (つまり、マシン A と B のクロックはわずかに異なる速度で実行されているため、たとえばマシン A の時間は実際には 1 秒ごとに 1.00001 秒の速度で進みます)。合格した）。これにより測定に不正確さが生じますが、実際の影響はほとんどのアプリケーションで問題になることはありません。