search

heiher / hev-socks5-tunnel

A high-performance tun2socks for Linux/Android/FreeBSD/macOS/iOS/WSL2 (IPv4/IPv6/TCP/UDP)
MIT License
651 stars 132 forks source link

关于udp in udp模式，即时视频通讯udp io超时判定的问题 #70

Closed stevezhangzl closed 7 months ago

stevezhangzl commented 7 months ago

老师你好，发现hev-config.c中的read_write_timeout 值在udp in udp的情况下，即时视频通讯会影响视频流的连接，到了超时时间，出现io tiemout 会把udp的任务和连接关掉，这块如果是即时视频通讯就会存在问题（视频会断），请问这块的设计有什么考量么？怎么解决这个问题

stevezhangzl commented 7 months ago

而且现在发现一个问题，如果timeout设置为-1的话，视频通讯一段时间后会阻塞在hev_task_yield (HEV_TASK_WAITIO) 视频也会断

heiher commented 7 months ago

你好，请测试 https://github.com/heiher/hev-socks5-tunnel/commit/1f586d22e56209e86cb3ab2992ff7c89ea4edfd2 能否解决问题？(请注意同步 submodule：git submodule update

stevezhangzl commented 7 months ago

好的，我测试下

stevezhangzl commented 7 months ago

还是会断，断流发生在hev_socks5_task_io_yielder执行hev_task_yield (HEV_TASK_WAITIO)切换任务时就已经断了

heiher commented 7 months ago

而且现在发现一个问题，如果timeout设置为-1的话，视频通讯一段时间后会阻塞在hev_task_yield (HEV_TASK_WAITIO) 视频也会断

之前没注意这条更新。

还是会断，断流发生在hev_socks5_task_io_yielder执行hev_task_yield (HEV_TASK_WAITIO)切换任务时就已经断了

看上去这得我这能复现来看看了，有简便的方法吗？

stevezhangzl commented 7 months ago

现在这个是在内网部署了一套webrtc即时视频来测试udp in udp模式的，经过咱们socks5的代理后，然后走中继服务器转发

stevezhangzl commented 7 months ago

我这边也再定位下，大佬有没有什么猜测么，协程切换任务的时候，出现问题好像是反复在执行hev_task_system_schedule 但没去真正的去切换执行

stevezhangzl commented 7 months ago

发现 timeout -1的情况下，一段时间异常，从日志上看，从tun虚卡中读取出数据，是不是应该切换任务去send to 但是切到的确是recv from任务，又继续读取数据了，然后就异常中断了

tun read后 切换任务没有去执行send

经测试发现 ，大量udp读写后，会出现突然tun read数据后，没有进入到 static void udp_recv_handler (void arg, struct udp_pcb pcb, struct pbuf p, const ip_addr_t addr, u16_t port)

函数里，出现问题

heiher commented 7 months ago

发现 timeout -1的情况下，一段时间异常，从日志上看，从tun虚卡中读取出数据，是不是应该切换任务去send to 但是切到的确是recv from任务，又继续读取数据了，然后就异常中断了

lwip从tun上读取udp frame后，不会同步sendto的，而是放到udp frame list中，唤醒前向链路的协程任务转发。

经测试发现 ，大量udp读写后，会出现突然tun read数据后，没有进入到 udp_recv_handler

能不能写个独立的 udp 收发程序模拟你的场景来辅助复现问题？

heiher commented 7 months ago

另外，你如果怀疑 lwip 侧有问题的话，建议你使用 hev-socks5-tproxy 项目替换 hev-socks5-tunnel 来验证。

stevezhangzl commented 7 months ago

发现 timeout -1的情况下，一段时间异常，从日志上看，从tun虚卡中读取出数据，是不是应该切换任务去send to 但是切到的确是recv from任务，又继续读取数据了，然后就异常中断了

lwip从tun上读取udp frame后，不会同步sendto的，而是放到udp frame list中，唤醒前向链路的协程任务转发。

经测试发现 ，大量udp读写后，会出现突然tun read数据后，没有进入到 udp_recv_handler

能不能写个独立的 udp 收发程序模拟你的场景来辅助复现问题？

lwip侧不太清楚原理，正常tun read后调用 netif.input (buf, &netif) 不是应该先回调udp_recv_handler 现在就是没有回调这个函数，所以不会添加udp frame list 自然没有唤醒send to的协程任务，但是现在就是这个问题很奇怪，为什么收发一段时间后出现这个问题

heiher commented 7 months ago

还是试试 hev-socks5-tproxy 吧。另外问问从会话建立到出大问题，大概需要多久？（不会是客户端侧的路由表被网络管理器重置了吧？[doggy]

stevezhangzl commented 7 months ago

还是试试 hev-socks5-tproxy 吧。另外问问从会话建立到出大问题，大概需要多久？（不会是客户端侧的路由表被网络管理器重置了吧？[doggy]

这个是在android上跑的，恩，我再找找问题试试，会话建立到出问题大概能通讯个4，5分钟左右

heiher commented 7 months ago

我用iperf3压了半小时udp双向传输，目前没有发现问题。

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 8500
        inet 198.18.0.1  netmask 255.255.255.255  destination 198.18.0.1
        inet6 fc00::1  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::8b73:76df:835d:743e  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 17307794  bytes 22984732942 (21.4 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 17307711  bytes 22984606228 (21.4 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
[ ID][Role] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5][TX-C]   0.00-1800.00 sec  21.0 GBytes   100 Mbits/sec  0.000 ms  0/17307684 (0%)  sender
[  5][TX-C]   0.00-1800.01 sec  21.0 GBytes   100 Mbits/sec  0.016 ms  0/17307684 (0%)  receiver
[  7][RX-C]   0.00-1800.00 sec  21.0 GBytes   100 Mbits/sec  0.000 ms  0/17307780 (0%)  sender
[  7][RX-C]   0.00-1800.01 sec  21.0 GBytes   100 Mbits/sec  0.012 ms  302/17307780 (0.0017%)  receiver