手离开后触点没消失，怎样核对 TUIO 会话结束事件

2026-10-23

TUIO 1.1的触点结束应根据有效帧的alive集合判断：此前存在的会话ID不再出现在完整alive列表中，接收端才移除它。不能等一条并不存在的统一“up命令”，也不能因一个UDP包没来就断言手已抬起。

先固定哪些条件

下文只讨论/tuio/2Dcur，不混用TUIO 2.0。set包含会话和位置属性，alive给出存活集合，fseq帮助识别帧序；实际网络使用OSC二进制束。下载的文本是可解析语义夹具，不能直接当UDP字节报文发送。

记录服务端版本、接收库版本、端口和帧序处理策略。先回放单点创建、移动、移除，再回放两个点交错移除；每帧列出前一存活集合、本帧alive和产生的add/update/remove事件。
增加重复帧、乱序帧、缺失一帧和暂时无数据四类输入，接收端按它所声明的策略记录忽略或接受。不要只保存最终触点数，要保存会话ID与事件时间，才能看见同一点是否被错误创建两次。
将语义夹具转为实际OSC束须由已验证的编码器完成，然后在隔离环境复测；真实发送时记录包长、源地址和fseq。额外的失联超时属于应用保护策略，应显示失联原因，不冒充协议保证的抬手事件。

合成序列100帧alive=[7]创建7，101帧仍有7并移动，102帧alive=[]移除7。若102帧丢失，接收端暂时保留7并不等于解析错误；后续完整alive再次不含7才提供移除依据。附件同时提供空白日志，要求写明是否采用失联保护及触发时间。

fseq	alive	set	期望事件
100	7	7在(0.2,0.3)	add 7
101	7	7在(0.4,0.3)	update 7
102	空	无	remove 7

下载合成输入CSV、空白记录CSV、可打印测试协议与完整字段JSON，另有本地只读核验脚本，以及OSC十六进制对照和100帧、101帧、102帧二进制束。先用合成输入熟悉字段，再复制空表填写自己的环境、测试时间和证据路径；不要把示例行改成真实项目名称后当作测量结果。协议中已经列出准备条件、顺序、通过条件、失败记录和复核人位置，可按本项目约定填写后打印。

把verify.py与100、101、102三个OSC帧文件放在同一目录，用 python verify.py 执行。脚本离线解析二进制类型、长度与帧序，再核对add、update、remove，不读取设备、不向UDP端口发包。

把对象class ID当作session ID会让相同物件或新入场触点串号。收到旧帧就回滚alive会让已移除的点复活。若日志缺少fseq而无法判断顺序，应补接收端原始记录；不要通过每秒清空全部触点来掩盖生命周期问题。

完成协议级核对后再验内容端拖动锁释放、按钮取消和下一位重新进入，协议移除不保证UI已释放资源。

本篇取证范围：已本地解析合成alive序列并核对add/update/remove；实际OSC二进制收发、丢包与引擎行为未测。

协议层的正确解析不等于内容层已处理所有移除与失联分支。接收库、互动引擎及下游动作要分别保留版本与日志，任何自定义超时都需向运营说明。

来源核对日期：2026-10-23。规范支持相应机制，表内输入和数值为本文合成演示；厂商声明仍须在指定版本与配置上验证。

评论发布后会被人工复核，违规内容将被删除。

如果发表没有反应，可以前往联系我们告诉我们。