3

UDP ソケットから等間隔でパケットを送信すると、最初に送信されたパケットが遅延しているように見えることに気付きました。たとえば、パケットを 100 ミリ秒ごとに送信している場合、パケットを受信する間の遅延は、ネットワーク上で平均 100 ミリ秒、平均標準偏差 4 で正規分布することがわかります。ただし、最初のパケットと 2 番目のパケットの受信時間のギャップは、通常 10 ～ 40 ミリ秒程度です。ご覧のとおり、これは明らかに統計的に有意な差です。私の質問は、何が原因でしょうか?

Linux で C の sendto 関数を使用しています。宛先IPがMACアドレスに変換されるまでパケットが送信されないようにするARP解決が遅延の原因である可能性があると誰かが示唆しました-これは可能性が高いですか? 送信プログラムを再起動すると、最初のパケットに再び時間がかかりすぎて、遅延に一貫性がなくなります.10から40ミリ秒はかなり大きな範囲です.

この最初のパケットに時間がかかりすぎる理由と、それを回避する方法を見つける必要があります。

編集: pcap を使用してさらに分析すると、送信プログラムが適切な間隔でパケットを送信していることが示されます。select() を使用して読み取り可能なソケットを待機し、recvfrom を呼び出してパケットを出力している受信側に問題があるはずです。私が知らないかもしれない何らかのバッファリングが行われていますか?

4

5 に答える 5

2

ほとんどの場合、ARPアドレスの解決に必要な時間です。これは、MACアドレスをIPアドレスに解決するプロトコルです。

これを回避するには、arpキャッシュの静的エントリを。で使用してみてくださいarp -s ip-address hw_address。

于 2010-12-20T11:00:09.613 に答える
1

憶測は私たちをどこにも連れて行きません.Wiresharkを起動すると、あなたが知る必要があるすべてを教えてくれます.

于 2010-12-20T10:57:26.647 に答える
0

これは単一のLAN上にありますか？もしそうなら、それは (おそらく) ARP やホスト名の解決にかかっています。それが大規模なネットワークにまたがっている場合、それは何でもかまいません (ただし、ルート検索とキャッシュの人口に関連している可能性があります)。

于 2010-12-20T12:11:59.007 に答える
0

私は最善の解決策であると考えるものに投票するのに十分な「評判」を持っていないので、ARP メッセージについて言及した人がおそらく正しいとだけ言っておきます。ARP メッセージは LAN にのみ適用されるべきだと思います。それらは「192.168.0.24 を持っているのは誰?」として Wireshark に表示されます。たとえば...そして、そのIPアドレスを持っていると主張するホストからの応答があります。UDP 経由でこのアドレスに送信される最初のパケットは、IP アドレスをイーサネット MAC アドレスに解決するために ARP 応答を取得する必要があります。 ARP アドレスが解決されます。よくわかりませんが、LAN 上にないアドレスに UDP を送信している場合は、ARP は必要ないはずです...プライマリ ゲートウェイの検索に問題がない限り。

于 2013-09-29T20:58:12.677 に答える
0

あなたは回避策について尋ねました。パケットの受信時間を知ることが重要である場合、考えられる回避策の 1 つは、SO_TIMESTAMPソケット オプションを設定することです。これにより、各パケットが宛先カーネルによって受信された時間を取得できます。その後、「現在の時間」ではなく、この時間を後続の処理で使用できます。

または、送信者が送信するパケットに高解像度のタイムスタンプを含めて、それらを使用することもできます。

于 2010-12-21T01:11:12.080 に答える