0

node.js 0.6.18> および 0.8.0 との UDP 接続で、重大なデータ損失が発生しています。毎秒約 1200 パケットの高いパケット レートで表示され、フレームは約 1500 バイトの制限があります。各データ パッケージには増分番号があるため、失われたパッケージの数を簡単に追跡できます。

var server = dgram.createSocket("udp4");

server.on("message", function (message, rinfo) {

        //~processData(message);        
        //~ writeData(message, null, 5000);

}).bind(10001);

受信コールバックで、最初に 5000 個のパッケージをファイルに保存した 2 つのケースをテストしました。その結果、ドロップされたパッケージはありませんでした。データ処理ルーチンを組み込んだ後、ドロップ率は約 50% になりました。私が期待していたのは、プロセス データ ルーチンは完全に非同期であり、システムにデッド タイムを導入してはならないということでした。これは、パッケージ内のバイナリ データを処理し、イベントをさらに処理するルーチンに発行する単純なパーサーであるためです。

解析ルーチンにより、イベント ハンドラーが各パケットを処理できないデッド タイムが発生するようです。

低いパッケージ レート (< 1200 パッケージ/秒) では、データの損失は観察されません! これはバグですか、それとも何か間違っていますか?

4

2 に答える 2

1

Node.jsはシングルスレッドシステムとして実行されます。処理を行っている間、プロセスはデータを受信できず、ネットワークデータはOSバッファがいっぱいになるまでキューに入れられ、その後パケットがドロップされます。これを処理する方法はたくさんありますが、通常、データを受信（およびキュー）するプロセスのセットが1つあり、受信プロセスを遅らせることなく別のプロセスのセットが処理を実行します。これを設計するのに役立つモジュールはおそらくたくさんありますが、それは専門家に任せます... ;-)

于 2012-07-02T09:13:37.427 に答える
0

node.js udp も使用するstatsdで同様の問題に遭遇しました。Linux で実行している場合、受信バッファーを変更すると、ドロップを回避するために状況が大幅に改善されるようです。

具体的には、次のようなものを実行できます

sudo sysctl -w net.core.rmem_default=20971520

詳細については、この statsd github issueを参照してください。

于 2013-07-31T05:49:03.990 に答える