mirror of
https://gitee.com/xmz7891/ykxmz.git
synced 2026-10-18 13:40:45 +00:00
xmz7891
b2bfa6ffbf
relay-stability 跑了 30 次真实长轮询，第 1 次耗时 126604ms：
服务端 hold 是 60 秒
剩下 66 秒全是网络停顿（4G 抖动 + 重传退避）
而客户端超时写的是 120000ms
-> 126.6 > 120，那次会被**误判成失败**，尽管服务端已经正常返回
其余 29 次都是 61~62 秒，很正常。不是 hold 太长，是网络尾巴太长。
为什么放宽超时而不是缩短 hold：
A. hold 缩到 45 秒、超时保持 120 -> 最坏 111 秒，安全
但请求数多 33%，而每次请求都要吃隧道 1~2 秒开销
B. hold 保持 60 秒、超时放宽到 180 -> 最坏 180 秒，安全
选 B —— 这条链路的根本问题是丢包抖动，**请求越少越不容易撞上**。
放宽超时只是"别把慢但成功的请求冤枉掉"，不增加任何请求。
客户端已有"连续失败 3 次才判离线"（OFFLINE_AFTER=3），
所以偶尔一次长等待不会让界面闪"已断开"。
超时余量的演进（全是实测逼出来的）：
90 秒 -> 实测 93589ms 不够
120 秒 -> 实测 126604ms 不够
180 秒 -> 60 hold + 120 余量
两边同步改：
windows/lanremote/relay.py POLL_TIMEOUT 120 -> 180
android .../RelayTransport.java POLL_TIMEOUT_MS 120000 -> 180000
（Java 侧确认 setConnectTimeout 另有 15 秒上限、setReadTimeout 吃这个值，
没有别的超时会先把请求掐掉。）