Что может привести к этому значению> 1000 мс в сообщениях канала данных webrtc?

Когда я настраиваю канал данных между двумя браузерами (тестирование на двух разных машинах в одной сети), я получаю разные результаты относительно задержки в следующих двух случаях.

Случай 1: только отправка/получение

Когда я настраиваю одну сторону для отправки тестовых сообщений с интервалом, например, 70 мс, я вижу, что они входят с другой стороны без заметного запаздывания. Время между каждым полученным сообщением близко к 70 мс. Пока все хорошо.

Случай 2: Обе стороны отправляют и принимают по очереди

Когда я настраиваю обе стороны, чтобы отправить сообщение, как только оно получило сообщение с другой стороны И это больше чем 70 мс назад с момента последней отправки, все идет хорошо, за исключением иногда. Каждые несколько секунд (не согласуются) измеряю задержку ~ 1000 мс. Странно, что время между подавляющим большинством сообщений равно или меньше, 200 мс OR > ~ 1000 мс.


Я тестировал оба случая в комбинациях хром и firefox, поведение было аналогичным. Я также тестировал его в сети мобильного телефона (используя привязку), который показал одинаковое отставание, хотя и реже. Канал данных не был настроен с какими-либо специальными параметрами, поэтому он использует надежное упорядоченное соединение.

Что может быть причиной этого? Мне кажется, что он может быть исправлен, так как отправка в одном направлении (в любом случае) отлично работает без задержек. Я также попытался использовать отдельный канал данных для отправки/получения, что не имело значения.


Примеры

Ниже приведен пример результатов тестирования для второго случая. Это список всех дней в оба конца, которые были выше 200 мс для 1000 поездок в оба конца.

(Delay index) round trip time - round trip number - time
(0) 2192 - 0 - "2016-05-06T12:34:18.193Z"
(1) 1059 - 111 - "2016-05-06T12:34:22.777Z"
(2) 1165 - 372 - "2016-05-06T12:34:32.485Z"
(3) 1062 - 434 - "2016-05-06T12:34:35.585Z"
(4) 1157 - 463 - "2016-05-06T12:34:37.598Z"
(5) 1059 - 605 - "2016-05-06T12:34:43.264Z"
(6) 1160 - 612 - "2016-05-06T12:34:44.633Z"
(7) 1093 - 617 - "2016-05-06T12:34:45.857Z"
(8) 1158 - 624 - "2016-05-06T12:34:47.204Z"
(9) 1162 - 688 - "2016-05-06T12:34:50.401Z"
(10) 1158 - 733 - "2016-05-06T12:34:52.962Z"
(11) 1161 - 798 - "2016-05-06T12:34:56.163Z"
(12) 1157 - 822 - "2016-05-06T12:34:58.077Z"
(13) 1158 - 888 - "2016-05-06T12:35:01.281Z"
(14) 1160 - 893 - "2016-05-06T12:35:02.563Z"
(15) 1085 - 898 - "2016-05-06T12:35:03.768Z" 

Вот еще один пример, включающий граф "PacketsSentPerSecond" от chrome://webrtc-internals:

Граф PacketsSentPerSecond

В этом тесте было отправлено ~ 2100 пакетов, что привело к следующим 26 поездкам в оба конца, которые заняли более 900 мс: [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]

Я до сих пор не понял, что вызывает это отставание. Я ожидаю гораздо более плавный график.

+9
05 мая '16 в 18:11
источник поделиться
3 ответа

Хотя я все еще не уверен, что вызывает проблему, я нашел решение. Мое лучшее предположение заключается в том, что проблема вызвана управлением потоком, когда один из сверстников не передает данные некоторое время (или они просто не достигают другого).

Я заметил, что нет проблем, когда оба одноранговых узла передают пакеты друг другу в промежуток времени 70 мс, когда они не ждут пакета друг от друга. Как только я откладываю отправку пакета в ожидании входящего пакета, я получаю ланги > 1000 мс.

Итак, теперь я действительно отправляю пакеты с устойчивой скоростью EVEN, если они пусты. Мое приложение требует отправки данных по очереди, но я просто проверяю с интервалом, если есть что отправить, а если нет, я все равно отправляю пустой пакет. Таким образом, проблема, по-видимому, решена в тестах, которые я сделал до сих пор!

+2
10 мая '16 в 16:57
источник

Возможно, это связано с тем, что люди задерживают 1000 мс? (например, setTimeout/setInterval 1000 мс отставание в фоновых вкладках (Chrome и Firefox))

Вы настроили интервал отправки на 70 мс, что является относительно небольшим интервалом. Вы пытались использовать большой интервал? Также вы можете захотеть сделать некоторые тесты с использованием встроенного решения WebRTC iOS или Android, чтобы вы могли знать, является ли проблема основной реализацией WebRTC (кажется мне маловероятной) или некоторыми ограничениями браузера.

+1
11 мая '16 в 3:58
источник

Я почти уверен, что это вызвано вашим сервером TURN. В прошлом месяце я сделал очень похожий тест, и все пакеты были получены в течение нескольких миллисекунд через TURN (с использованием нашего собственного сервера TURN). Тест был выполнен как с Firefox, так и с Chrome.

0
08 мая '16 в 19:33
источник

Посмотрите другие вопросы по меткам или Задайте вопрос