Was könnte diese 1000ms Verzögerung in webrtc Datenkanalnachrichten verursachen?
Wenn ich einen Datenkanal zwischen zwei Browsern eingerichtet habe (Test auf zwei verschiedenen Rechnern im selben Netzwerk), erhalte ich in den folgenden zwei Fällen unterschiedliche Ergebnisse bezüglich der Verzögerung.
Fall 1: nur Senden / Empfangen
Wenn ich eine Seite für das Senden von Testnachrichten mit einem Intervall von beispielsweise 70 ms einstelle, sehe ich, dass sie auf der anderen Seite ohne merkliche Verzögerung ankommen. Die Zeit zwischen jeder empfangenen Nachricht liegt nahe bei 70 ms. So weit so gut.
Fall 2: Beide Seiten senden und empfangen nacheinander
Wenn ich beide Seiten so eingestellt habe, dass sie eine Nachricht senden, sobald sie eine Nachricht von der anderen Seite erhalten UND es vor mehr als 70ms seit dem letzten Senden ist, geht alles gut, außer manchmal. Alle paar Sekunden (nicht konsistent) messe ich eine Verzögerung von ~ 1000ms. Das Seltsame ist, dass die Zeit zwischen den meisten Nachrichten entweder & lt; 200ms ODER & gt; ~ 1000ms.
Ich testete beide Fälle in (Kombinationen von) Chrom und Firefox, das Verhalten war ähnlich. Ich habe es auch in einem Mobilfunknetz getestet (mit Tethering), das die gleiche Verzögerung zeigte, wenn auch seltener. Der Datenkanal wurde nicht mit speziellen Optionen konfiguriert, daher wird eine zuverlässige, geordnete Verbindung verwendet.
Was könnte das verursachen? Es scheint mir, dass es behoben werden kann, da das Senden in einer Richtung (egal) ohne Verzögerung funktioniert. Ich habe auch versucht, einen separaten Datenkanal zum Senden / Empfangen zu verwenden, was nicht wichtig war.
Beispiele
Hier ist ein Beispiel für Testergebnisse für den zweiten Fall. Es ist eine Liste aller Hin- und Rückreisezeiten, die für 1000 Hin- und Rückflüge über 200ms lagen.
%Vor%Hier ist ein weiteres Beispiel, einschließlich eines 'PacketsSentPerSecond'-Graphen von chrome: // webrtc-internals:
In diesem Test wurden ~ 2100 Pakete gesendet, was zu den folgenden 26 Rundreisen mit mehr als 900 ms führte:
[1762.6050000000014, 1179.7200000000012, 1765.375, 1149.945000000007, 1180.1399999999994, 1180.9550000000017, 1246.2450000000026, 1750.2649999999994, 1388.0149999999994, 1100.7499999999854, 4130.475000000006, 1160.1150000000052, 1082.4399999999878, 1055.2300000000105, 1498.715000000011, 1105.8850000000093, 1478.1600000000035, 2948.649999999994, 1538.2549999999756, 1839.9099999999744, 1768.6449999999895, 1167.929999999993, 1139.1750000000175, 1173.8850000000093, 1245.6600000000035, 1075.375]
Ich habe immer noch nicht herausgefunden, was diese Verzögerung verursacht. Ich würde eine viel glattere Grafik erwarten.
3 Antworten
Obwohl ich immer noch nicht sicher bin, was das Problem verursacht, habe ich eine Lösung gefunden. Meine beste Vermutung ist, dass das Problem durch die Flusskontrolle verursacht wird, wenn einer der Peers eine Weile keine Daten sendet (oder sie nur die andere nicht erreichen).
Ich habe bemerkt, dass es keine Probleme gibt, wenn beide Peers Pakete in einem 70ms Intervall verschicken, wenn sie nicht auf ein Paket von einander warten. Sobald ich das Senden eines Pakets verzögere, während ich auf ein eingehendes Paket warte, bekomme ich die & gt; 1000ms Verzögerungen.
Also, was ich jetzt mache, ist eigentlich das Senden von Paketen mit einer gleichmäßigen Rate, selbst wenn sie leer sind. Meine Anwendung erfordert das Senden von Daten der Reihe nach, aber ich überprüfe nur in einem Intervall, wenn etwas zu senden ist, und wenn nicht, sende ich noch ein leeres Paket. So scheint das Problem in den bisherigen Tests gelöst zu sein!
Vielleicht hat es etwas mit den 1000ms zu tun, die die Leute diskutieren? (wie folgt setTimeout / setInterval 1000ms Verzögerung im Hintergrund Tabs (Chrome und Firefox) )
Sie haben das Sendeintervall auf 70 ms konfiguriert, was ein relativ kleines Intervall ist. Haben Sie versucht, ein größeres Intervall zu verwenden? Vielleicht möchten Sie auch ein paar Tests mit der webRTC iOS oder Android nativen Lösung durchführen, so dass Sie wissen können, ob das Problem von der Kern-WebRTC-Implementierung herrührt (scheint mir unwahrscheinlich) oder einer Browser-Einschränkung.
Ich bin mir fast sicher, dass dies von Ihrem TURN-Server verursacht wird. Ich habe einen sehr ähnlichen Test im letzten Monat gemacht und alle Pakete wurden innerhalb von ein paar Millisekunden über TURN empfangen (mit unserem eigenen TURN Server). Der Test wurde mit Firefox und Chrome durchgeführt.
Tags und Links javascript webrtc network-programming lag