Как решить: UDP-отправка байтов xxx завершилась с ошибкой 11 в Ubuntu? - PullRequest
0 голосов
/ 13 мая 2018

Ошибка отправки UDP XXXX байтов с ошибкой 11

Я запускаю потоковое приложение WebRTC в Ubuntu 16.04.Он передает видео и аудио с веб-камеры Logitec HD Webcam c930e в приложении Electronjs для настольных ПК.

Все это отлично работает и работает на моем другом компьютере Macbook Pro.Но на моем компьютере с Ubuntu я получаю ошибки через 10-20 секунд, когда установлено одноранговое соединение:

[2743:0513/193817.691636:ERROR:stunport.cc(282)] Jingle:Port[0xa5faa3df800:audio:1:0:local:Net[wlx0013ef503b67:192.168.0.x/24:Wifi]]: UDP send of 1019 bytes failed with error 11
[2743:0513/193817.691775:ERROR:stunport.cc(282)] Jingle:Port[0xa5faa3df800:audio:1:0:local:Net[wlx0013ef503b67:192.168.0.x/24:Wifi]]: UDP send of 1020 bytes failed with error 11
[2743:0513/193817.696615:ERROR:stunport.cc(282)] Jingle:Port[0xa5faa3df800:audio:1:0:local:Net[wlx0013ef503b67:192.168.0.x/24:Wifi]]: UDP send of 1020 bytes failed with error 11
[2743:0513/193817.696777:ERROR:stunport.cc(282)] Jingle:Port[0xa5faa3df800:audio:1:0:local:Net[wlx0013ef503b67:192.168.0.x/24:Wifi]]: UDP send of 1020 bytes failed with error 11
[2743:0513/193817.712369:ERROR:stunport.cc(282)] Jingle:Port[0xa5faa3df800:audio:1:0:local:Net[wlx0013ef503b67:192.168.0.x/24:Wifi]]: UDP send of 1029 bytes failed with error 11
[2743:0513/193817.712952:ERROR:stunport.cc(282)] Jingle:Port[0xa5faa3df800:audio:1:0:local:Net[wlx0013ef503b67:192.168.0.x/24:Wifi]]: UDP send of 1030 bytes failed with error 11
[2743:0513/193817.713086:ERROR:stunport.cc(282)] Jingle:Port[0xa5faa3df800:audio:1:0:local:Net[wlx0013ef503b67:192.168.0.x/24:Wifi]]: UDP send of 1030 bytes failed with error 11
[2743:0513/193817.717713:ERROR:stunport.cc(282)] Jingle:Port[0xa5faa3df800:audio:1:0:local:Net[wlx0013ef503b67:192.168.0.x/24:Wifi]]: UDP send of 1030 bytes failed with error 11 

==> Кстати, если я НЕ транслирую аудио, а только видео.Я получил ту же ошибку, но только с "видео" между строками журнала ...

где-то между строк. У меня также есть одна строка, которая говорит:

[3441:0513/195919.377887:ERROR:stunport.cc(506)] sendto: [0x0000000b] Resource temporarily unavailable

Я также посмотрелв sysctl.conf и увеличил значения там.Мой ток sysctl.conf выглядит так:

fs.file-max=1048576
fs.inotify.max_user_instances=1048576
fs.inotify.max_user_watches=1048576
fs.nr_open=1048576
net.core.netdev_max_backlog=1048576
net.core.rmem_max=16777216
net.core.somaxconn=65535
net.core.wmem_max=16777216
net.ipv4.tcp_congestion_control=htcp
net.ipv4.ip_local_port_range=1024 65535
net.ipv4.tcp_fin_timeout=5
net.ipv4.tcp_max_orphans=1048576
net.ipv4.tcp_max_syn_backlog=20480
net.ipv4.tcp_max_tw_buckets=400000
net.ipv4.tcp_no_metrics_save=1
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_synack_retries=2
net.ipv4.tcp_syn_retries=2
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_wmem=4096 65535 16777216
vm.max_map_count=1048576
vm.min_free_kbytes=65535
vm.overcommit_memory=1
vm.swappiness=0
vm.vfs_cache_pressure=50

Как здесь предлагается: https://gist.github.com/cdgraff/7920db287988463aafd7ea09eef6f9f0

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

Дополнительная информация: в Ubuntu приложение Electronjs подключается к серверу Heroku ( Nodejs ) и другой стороне соединения с равноправным узлом.(Браузер Chrome) также подключается к нему.Heroku Server действует как сервер рукопожатия для установления соединения с WebRTC.Оба имеют конфигурацию:

{'urls': 'stun:stun1.l.google.com:19302'},

{'urls': 'stun:stun2.l.google.com:19302'},

, а также дополнительный сервер поворотов с numb.viagenie.ca

Соединение установлено, и в течение первых 10 секунд качество очень высокое, и нетотстает на всех.Но затем через 10-20 секунд происходит отставание, и на консоли Ubuntu я получаю следующие ошибки UDP.

ПК, на котором работает Ubuntu:

PROCESSOR / CHIPSET :

Процессор Intel Core i3 (2nd Gen) 2310M / 2,1 ГГц

Количество ядер: двухъядерный

Кэш-память: 3 МБ

64-разрядные вычисления: Да

Тип набора микросхем: мобильный Intel HM65 Express

RAM :

Скорость памяти:1333 МГц

Спецификация памяти Соответствие: PC3-10600

Технология: DDR3 SDRAM

Установленный размер: 4 ГБ

Номинальная памятьСкорость: 1333 МГц

Графика

Графический процессор Intel HD Graphics 3000

Может кто-нибудь дать мне немногонамеки или что-нибудь, что может решить эту проблему?

Спасибо

============== РЕДАКТИРОВАТЬ =============

Я нашелв моем очень большом журнале strace где-то эти две строки:

7671  sendmsg(17, {msg_name(0)=NULL, msg_iov(1)=[{"CHILD_PING\0", 11}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 11

7661  <... recvmsg resumed> {msg_name(0)=NULL, msg_iov(1)=[{"CHILD_PING\0", 12}], msg_controllen=32, [{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, {pid=7671, uid=0, gid=0}}], msg_flags=0}, 0) = 11

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

https://gist.github.com/Mcdane/2342d26923e554483237faf02cc7cfad

1 Ответ

0 голосов
/ 13 мая 2018

Во-первых, чтобы получить представление о том, что происходит в первую очередь, я бы посмотрел со стразами.Запустите ваше приложение с

strace -e network -o log.strace -f YOUR_APPLICATION

Если ваше приложение ищет другой работающий процесс, который тоже должен перевернуть работу, запустите его с параметрами, чтобы он этого не делал.Например, для Chrome, передайте значение --user-data-dir, отличное от значения по умолчанию.

Найдите = 11 в выходном файле log.strace и посмотрите, что произошлодо и после.Это даст вам приблизительное представление о том, что происходит, и вы можете исключить глупые ошибки, такие как sendtos для 0.0.0.0 или около того (по этой причине это также очень важная информация для включения в вопрос stackoverflow, например, путем загрузки выходных данныхto gist ).

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

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

Ошибка 11 - EAGAIN .Документация send говорит, когда эта ошибка должна произойти:

EAGAIN (...) Сокет помечен как неблокирующий, и запрошенная операция заблокируется.(...)

EAGAIN (сокеты дейтаграмм домена Интернета) Сокет, на который ссылается sockfd, ранее не был привязан к адресу, и при попытке привязать его к эфемерному порту было определено, что весь портномера в диапазоне эфемерных портов в настоящее время используются.См. Обсуждение / proc / sys / net / ipv4 / ip_local_port_range в ip (7) .

Могут применяться оба условия.Первый будет очевиден по журналу strace, если вы проследите за созданием соответствующего сокета.

Чтобы исключить второй, вы можете запустить netstat -una (или, если вы хотите знать, какие программы задействованы, sudo netstat -unap) чтобы увидеть, какие порты открыты (если вы хотите, чтобы пользователи Stack Overflow просматривали его, опубликуйте вывод на gist или аналогичный и сошлитесь на него здесь).Ваш диапазон портов net.ipv4.ip_local_port_range=1024 65535 не является стандартным 32768 60999;похоже, вы пытались что-то сделать с отсутствующими номерами портов.Это помогло бы проследить причину, по которой вы изменили этот параметр, и условия, которые убедили вас сделать это.

...