XXXX 字节的 UDP 发送失败，出现错误 11
我在Ubuntu 16.04上运行WebRTC流媒体应用程序。 它在Electronjs桌面应用程序中从Logitec高清网络摄像头c930e流式传输视频和音频。
这一切都在我的另一台机器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服务器充当握手服务器来建立WebRTC连接。两者都具有以下配置：
{'urls': 'stun:stun1.l.google.com:19302'},
{'urls': 'stun:stun2.l.google.com:19302'},
以及来自 numb.viagenie.ca 的附加 Turn Server
连接建立，在前 10 秒内质量非常高，完全没有滞后。但是在 10-20 秒后出现滞后，在 Ubuntu 控制台上我收到这些 UDP 错误。
运行 Ubuntu 的 PC：
处理器/芯片组：
CPU 英特尔酷睿 i3 (第二代( 2310M/2.1 GHz
内核数量：双核
缓存：3 MB
64 位计算：是
芯片组类型： 移动式英特尔 HM65 高速
内存：
内存速度： 1333 兆赫
内存规格合规性：PC3-10600
技术： DDR3 硬盘内存
安装大小： 4 GB
额定内存速度：1333 MHz
图形
图形处理器英特尔核芯显卡 3000
任何人都可以给我一些提示或任何可以解决这个问题的东西吗？
谢谢
=============编辑==
=============我在我非常大的跟踪日志中发现了这两行：
7671 sendmsg(17, {msg_name(0)=NULL, msg_iov(1)=[{"CHILD_PING ", 11}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 11
7661 <... recvmsg resumed> {msg_name(0)=NULL, msg_iov(1)=[{"CHILD_PING ", 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
首先，为了首先了解正在发生的事情，我会用 strace 来查看。启动应用程序时
strace -e network -o log.strace -f YOUR_APPLICATION
如果您的应用程序也在寻找另一个正在运行的进程来转换工作，请使用参数启动它，这样它就不会这样做。例如，对于 Chrome，传入与默认值不同的--user-data-dir值。
在输出文件中查找= 11log.strace之后，并查看之前和之后发生的事情。这将使您大致了解正在发生的事情，并且您可以排除愚蠢的错误，例如将sendtos发送到0.0.0.0左右(出于这个原因，这也是包含在堆栈溢出问题中的非常重要的信息，例如通过将输出上传到gist(。
使用Wireshark或其他数据包捕获程序来大致了解正在发送的内容也可能有所帮助。
假设您可以使用 strace 确认发生了有效的send调用，则可以进一步分析错误条件。
错误 11 是 EAGAIN。send的文档说明了此错误何时发生：
再次 (...套接字标记为非阻塞，请求的操作将阻塞。(...)
EAGAIN (因特网域数据报套接字( 所指的套接字 Sockfd以前没有绑定到一个地址，并且 试图将其绑定到临时端口，确定所有 临时端口范围内的端口号当前正在使用中。 看 对/proc/sys/net/IPv4/ip_local_port_range 的讨论 知识产权(7(.
这两个条件都可能适用。 如果您跟踪所涉及的套接字的创建，则第一个在 strace 日志中会很明显。
要排除第二个，您可以运行netstat -una(或者，如果您想知道所涉及的程序，sudo netstat -unap(以查看哪些端口已打开(如果您希望 Stack Overflow 用户查看它，请将输出发布在 gist 或类似内容上并链接到此处(。您的端口范围net.ipv4.ip_local_port_range=1024 65535不是标准32768 60999;这看起来您已经尝试对缺少端口号执行某些操作。追溯更改该参数的原因以及说服您这样做的条件会有所帮助。