mirror of
https://gitee.com/xmz7891/ykxmz.git
synced 2026-10-18 13:40:45 +00:00
修局域网/中转对比基准：它自己有两个 bug，害产品背了黑锅
这个基准一直是红的（中转那条路报「连接阶段失败: timed out」），
而且报告里写着"这是中转链路的产品 bug"。**查下来不是产品的问题。**
== bug 1：两条路用了同一个配对码 ==
基准为了排除互相干扰，给两条路**各起一台全新被控端**（设计是对的），
但两台都用了写死的 code="246813"。
中转有「一个配对码只属于一台设备」的规则：
第 1 台（跑局域网）注册成功
-> stop_agent 杀掉进程，但**中转还以为它在线**（last_seen 没过期）
第 2 台（跑中转）用同一个码注册 -> **被拒**
中转日志：配对码 246813 已被 ... 占用，拒绝 ...
而 start_agent 只检查"有没有设备在线" —— 第 1 台僵尸还挂着，
于是**以为新的一台登记成功了**
-> 没有任何进程在回包 -> 超时
对照实验（新增 _build/verify_code_reuse.py）：
场景 A 同一个码 -> **不通**
场景 B 各用不同码 -> 通
修法：两条路各用不同码；start_agent 的判据从"有没有在线设备"
改成"有没有**配对码正好是这一台要用的码**的在线设备"。
== bug 2：attach 用的还是旧码（我第一版补丁也漏了这处）==
relay_connect() 里 `client.attach(code)` 用的还是局域网那个码 ——
attach 到一台已经死掉、但中转以为在线的设备上，pair 自然没人回。
修成 `attach(relay_code)`。
== 顺带更新一段过时注释 ==
原文写着「当前版本经中转只稳定支撑前 1~2 次交互……这是中转链路的
产品 bug」，并据此把中转的轮数调小、超时调短。
那个 bug **已经修好了**（根因：一条 HTTP/1.1 连接被长轮询和发命令
两个线程同时用，撞状态机抛 CannotSendRequest("Idle")，
异常冒到 _client_loop 外面把 client-relay 线程打死）。
注释不更新会误导后人以为产品还有这个问题。
== 修好之后的实测（本地中转，30 次/路）==
局域网 握手 16ms 成功 30/30 (100%) 中位 0ms P90 0ms 最大 1ms
中转 握手 46ms 成功 30/30 (100%) 中位 15ms P90 29ms 最大 32ms
这是本地中转，量的是**协议本身的开销**（长轮询往返 vs 直连 TCP）；
真实跨网络那条腿的 1.0~1.5 秒来自隧道和 4G，是另一回事。
结论：局域网确实是"毫秒级、不耗流量"的那条根本路径 ——
中位 0ms vs 15ms，而且不走任何外网。
踩坑记录：这两处都是"看起来像产品 bug、实际是测试自己的 bug"。
先怀疑测量工具，比先怀疑产品更省时间 ——
上一次（管理页缓存头）也是我拿 curl -I 测 GET 白查了半天。
This commit is contained in:
xmz7891
@@ -237,7 +237,15 @@ def main() -> int:
|
||||
relay_port = free_port()
|
||||
agent_port = free_port()
|
||||
relay_url = "http://127.0.0.1:%d" % relay_port
|
||||
code = "246813"
|
||||
# ⚠ 两条路必须用**不同的**配对码。
|
||||
# 中转有「一个码只属于一台设备」的规则，而这个基准给每条路
|
||||
# 各起一台全新被控端（为了排除互相干扰，设计是对的）。
|
||||
# 要是两台共用一个码，第 2 台的注册会被拒，而第 1 台虽然
|
||||
# 进程被杀了、中转还以为它在线 —— 于是"看着登记成功、
|
||||
# 实际没人回包"，表现为连接阶段超时。
|
||||
# 实测对照见 _build/verify_code_reuse.py：同码不通、不同码通。
|
||||
code = "246813" # 局域网那条路
|
||||
relay_code = "975310" # 中转那条路，必须不同
|
||||
|
||||
print("=" * 66)
|
||||
print(" 局域网直连 vs 跨网络中转 （每种路径 %d 次 cmd:ping）"
|
||||
@@ -285,10 +293,11 @@ def main() -> int:
|
||||
# 真实被控端同时被"一条 TCP 会话 + 一条中转会话"占用时行为
|
||||
# 和单独用一条不一样。搞不清楚就别共用了 —— 每条路起一台干净实例，
|
||||
# 既排除了互相干扰，两边条件也完全一致，对比才有意义。
|
||||
def start_agent():
|
||||
def start_agent(agent_code=None):
|
||||
agent_code = agent_code or code
|
||||
data = Path(tempfile.mkdtemp(prefix="bench_agent_", dir=str(work)))
|
||||
store = Store(data)
|
||||
store.set_pairing_code(code)
|
||||
store.set_pairing_code(agent_code)
|
||||
store.set("setup_done", True)
|
||||
store.set("allow_new_pairing", True)
|
||||
store.set("close_pair_after_first", False)
|
||||
@@ -325,9 +334,17 @@ def main() -> int:
|
||||
snap = json.loads(resp.read().decode("utf-8"))
|
||||
except Exception: # noqa: BLE001
|
||||
continue
|
||||
if any(d.get("online") for d in snap.get("devices", [])):
|
||||
# ⚠ 不能只看"有没有设备在线" ——
|
||||
# 上一台被控端虽然进程被杀，中转还没超时清理它，
|
||||
# 于是这里会被僵尸设备骗过，以为新的一台登记成功了。
|
||||
# 要求：存在一台在线、且配对码正好是**这一台要用的码**
|
||||
# 的设备。
|
||||
live = [d for d in snap.get("devices", [])
|
||||
if d.get("online") and d.get("code") == agent_code]
|
||||
if live:
|
||||
return proc, data
|
||||
raise RuntimeError("被控端 45 秒内没登记到中转")
|
||||
raise RuntimeError(
|
||||
"被控端 45 秒内没登记到中转（码 %s）" % agent_code)
|
||||
|
||||
def stop_agent(proc):
|
||||
if proc is None:
|
||||
@@ -361,26 +378,40 @@ def main() -> int:
|
||||
|
||||
# ---- 跨网络那条路（换一台干净的被控端）----
|
||||
#
|
||||
# ⚠ 这里的轮数**故意比局域网少**，而且超时给得短。
|
||||
# 原因：当前版本经中转只稳定支撑前 1~2 次交互，之后被控端
|
||||
# 就不再回包（详见 _build/diag_relay_leg.py 的时间线：
|
||||
# attach/pair/ping#1 全 0ms 返回，ping#2 开始 relay 一直回 0 字节）。
|
||||
# 这是中转链路的**产品 bug**，不是本测试的毛病 ——
|
||||
# 仓库现成的 _tests/test_relay_local.py 也是同样形状。
|
||||
# 所以这里只做**有界**测量：拿得到就打点，拿不到就如实报错，
|
||||
# 绝不让整个基准卡死。
|
||||
agent_proc, _data = start_agent()
|
||||
# 【历史】这里原来写着"经中转只稳定支撑前 1~2 次交互"，
|
||||
# 并据此把轮数调小、超时调短。那个产品 bug **已经修好了**：
|
||||
#
|
||||
# 根因是一条 HTTP/1.1 连接被两个线程同时用 ——
|
||||
# relay-link 线程的 /v1/agent/poll 要挂 180 秒（长轮询），
|
||||
# client-relay 线程同时 POST /v1/agent/send 发命令，
|
||||
# HTTP/1.1 一条连接同时只能一个在途请求，撞上状态机就抛
|
||||
# CannotSendRequest("Idle")，异常冒到 server.py 的
|
||||
# _client_loop 外面把线程打死 —— 之后电脑再也不回包。
|
||||
#
|
||||
# 修法：发命令走独立连接 + 锁盖住整个请求周期 +
|
||||
# _client_loop 兜住回包异常。_tests/test_relay_local.py
|
||||
# 从"完全卡死"变成 21/21 全过。
|
||||
#
|
||||
# 所以现在两条路用同样的轮数和超时，口径才一致。
|
||||
# （用户可通过 --relay-rounds / --relay-timeout 自行调整。）
|
||||
agent_proc, _data = start_agent(relay_code)
|
||||
|
||||
# attach 只是"接入中转"，协议层还得 pair 一次才算鉴权完成 ——
|
||||
# 这一步等价于局域网那边的 connect()，两边口径才一致。
|
||||
def relay_connect():
|
||||
client = RelayClient(relay_url)
|
||||
attach = client.attach(code)
|
||||
# ⚠ 必须用 relay_code，不是 code ——
|
||||
# code 是局域网那台（已经被 stop_agent 杀掉了，但中转还
|
||||
# 以为它在线）。attach 到死设备上，pair 就发给一个
|
||||
# 不存在的进程，表现成"连接阶段超时"。
|
||||
# 这个漏改让修好的产品背了一次黑锅。
|
||||
attach = client.attach(relay_code)
|
||||
if not attach.get("ok"):
|
||||
return client, {"ok": False,
|
||||
"error": attach.get("error") or "接入中转被拒"}
|
||||
reply = client.call({"cmd": "pair", "deviceId": "bench-relay",
|
||||
"deviceName": "基准测试手表", "code": code},
|
||||
"deviceName": "基准测试手表",
|
||||
"code": relay_code},
|
||||
args.relay_timeout)
|
||||
return client, reply
|
||||
|
||||
|
||||
Reference in New Issue
Block a user