2016-04-07 6 views
0

Ich habe ein Projekt, an dem ich arbeite, die ein kleines 9-Byte-Paket an 7000 verschiedene Hosts außerhalb des lokalen Netzwerks senden muss, nachdem Sie wartet auf ihre Antworten auf dem gleichen Port und verarbeitet die Antworten.Senden von vielen kleinen Paketen aus Node.js UDP sendet nicht alle

Das Problem, das ich habe, ist Node.js dgram (Udp4) scheint nicht alle Pakete zu senden. Ich bin in keiner Weise einschränkend, also könnte es dort ein Problem geben.

Ich bin Schleifen, Erstellen der Pakete, dann feuern sie direkt mit .send(). Bei geöffnetem Wireshark kann ich sehen, dass von den 7000 "gesendet" nur ~ 1300 von ihnen scheinen, die Leitung zu treffen und zu gehen.

Das Skript selbst meldet alle Pakete als gesendet ohne Fehler, Wireshark zeigt ein anderes Ergebnis, und die Hosts am anderen Ende widerspiegeln, was Wireshark sagt, sie empfangen das Paket nicht. Ich verwende Folgendes zum Senden und Verifizieren, Paket ist ein Puffer.

udpServer.send(packet, 0, packet.length, port, address, function(error) { 
    if (!error) { 
    successes++; 
    console.log(successes + "/" + total); 
    } else { 
    console.log(error); 
    } 
}); 

Irgendwelche Ideen auf, was ich hier falsch mache, oder was übersehen?

+0

Ich denke, es den Rest der Pakete verloren, vielleicht haben Sie eine Lösung finden Sie hier: https://github.com/nodejs/node-v0.x-archive/issues/6696 – Jer

+0

@ C0dekid.php I Hab 'mal geschaut. Das scheint sich hauptsächlich um die Empfangsseite zu drehen, anstatt zu senden. Es hat auch keine Vorschläge, außer unter Unix zu laufen. Ich habe verschiedene Plattformen mit dem gleichen Ergebnis ausprobiert. Danke für den Link, leider noch keine Lösung. –

+0

Interessant. Haben Sie versucht, anstelle von Buffer eine einfache Zeichenfolge zu senden, nur um sicher zu gehen, dass dies nicht das Problem ist? (was es nicht sein sollte, aber nur für den Fall) –

Antwort

0

Es gibt viele Verbindungsstellen, wo Ihr Paket fallen gelassen werden könnte:

  1. gelöscht, wenn auf Kernel zu senden. Bist du auf Linux? Versuchen Sie, strace zu verwenden, um den Rückgabewert des Systemaufrufs (wahrscheinlich send, sendmsg oder sendto) zu finden. Wenn der Systemaufruf einen Fehler zurückgibt, würde ich erwarten, dass dies in "error" von Node gemeldet wird.

  2. in der Kernel-TX-Warteschlange abgelegt. Unter Linux können Sie z. B. /sys/class/net/eth0/statistics/ überprüfen und sehen, ob die Anzahl der Drop-Zähler steigt.

  3. fiel in der Hardware-TX-Warteschlange. Wenn Sie eine Intel NIC verwenden, können Sie ethtool -S eth0 ausführen, um zu sehen, ob irgendwelche Drop-Zähler inkrementiert werden.

  4. in Zwischenhardware (z. B. Switches/Router) fallengelassen. Das ist schwieriger zu sehen, da es abhängig vom Anbieter und vielleicht unsichtbar ist. Sie können dies beseitigen, indem Sie Ihre Maschinen direkt miteinander verbinden.

  5. in Hardware-RX-Warteschlange fallengelassen. Überprüfen Sie auf der Gegenseite alle gleichen Statistiken, um festzustellen, ob dort ein Überlauf auftritt.

+0

Danke für diese Antwort, eine Menge ausgezeichneter Punkte zu prüfen. Ich habe mir die Punkte 1, 2 und 3 angeschaut und keine von ihnen zeigte irgendwelche Anzeichen von Problemen. Ich habe keinen Blick darüber hinaus geworfen, da Wireshark nicht zeigt, dass diese Pakete weggehen, also macht die Überprüfung über die Maschine keinen Sinn? Leider habe ich das Problem noch nicht gelöst. Ich schätze deine Antwort sehr. –

+0

Noch eine Verlustschicht, haben Sie die vom Knoten erzeugten Syscalls gezählt? Passt es zu dem, was Sie erwarten, dass es sendet? Vielleicht gibt Node eine interne Datenstruktur auf oder überläuft sie. – jdizzle

+0

Alle sendmsg werden berücksichtigt.Im Test habe ich nur Logging für 7558 gesehen, strace meldete 7558, aber Wireshark sah nur 1267 davon. –