问题: 现在中控设备不支持90 02读取设备数据,只支持93 02,但是ws需要读取中控设备数据,如何支持? 背景: 现在ws支持的命令有: - 发送指令:90
- 发送指令:无限制(90,93,94)
- 接受指令:91
- 接受指令:92
- 接受指令:无限制(93,94)
现有方案: - app发送 c2s_raw(93),
- 设备回复(94),app接受到s2c_raw(94)
缺点:没有数据点解析,只能传原始数据 修改方案: - 接受端修改方案:
- app发送 c2s_raw(93),
- 设备回复(94),ws解析数据点
- app接受s2c_noti
- 缺点:发送指令和接受不一致,容易混乱,设计不合理
- 接收端 + 发送端修改方案:
- app发送和以前一样的c2s_read 或 c2s_write
- ws解析是否是中控设备:是的话协议解析93;不是的话为90
- 设备回复(94),ws解析数据点
- app接受s2c_noti
- 缺点:数据点协议和设备类型硬编码绑定,ws还需要知道设备是什么类型
- 接收端自主选择方案:
- app发送采用新的指令,c2s_read2或write2
- ws解析为93
- 设备回复94,ws解析
- app接受到s2c_noti
- 看上去完美
- 细化方案3
- 93指令需要sn,sn如何生成?
- 客户端发过来 那么c2s_read2里多了个sn,这样就可以合并到c2s_read,有无sn即可判断出90还是93
- 94回复指令也有sn,sn如何处理?
- 回复给客户端 那么s2c_noti里多了个sn,这样也可以和c2s_read有sn的成对出现
- 看上去很完美了,没有坑了
- 隐藏问题
90指令是app发给dev,91是dev发给app。但是93,94并没有方向,app和dev都可以发送93或者94。
这样ws会接收到93和94,ws接收到设备发送的93,解析出sn和数据点发送给app。
但是94指令可能存在内容为空,这个和93不一样。
问题1:
- s2c_noti的内容是数据点,用s2c_noti内容为空,是否合适?
- 设备回复94,带上数据点。ws解析后noti返回给app; 设备发送93,带上数据点。ws解析后noti返回给app,但设备还在等待app回复94
- 问题本质是:现在回复有93,94,都用s2c_noti表达,不能准确表达94需要回复的语义了
方案1:新增一个指令s2c_ack,只有sn。这样94就变为ack - 方案2:同样是s2c_noti,但字段不同。在字段上做手脚区分。发送的时候为req_sn,回复res_sn
问题2:app回复设备的93,发送94+空内容,采用read吗?
方案1:采用read,内容为空- 方案2:新增指令c2s_ack,只有sn
疑问 - c2s_ack需要设备做,是否可以ws完成?
这个看是否合适,ws当然可以完成。包括,发送的sn也可以由ws完成。
这种做还是不做的问题,需要回归到问题的定义和本质了。即需不需要做?
这个ack是94指令,94的语义是客户端确认收到。如果ws做了,意味着app到手机这层之间没有确认,可能发丢了,但是设备认为已经接收到app发的94了
类比于mqtt的qos=1的ack。这个ack是客户端和服务端的确认。而94是客户端到客户端的ack。作用范围和功能一下就能明确出来
小结 - 解决问题采用隐藏,自动化全解决,还是解决部分,放出条件,留给选择?这是2种不同思路。
比如:让客户端选择调用不同指令read还是read2,ws封装是90还是93。还是ws自动判断
说明:智能是需要代价的,如果这个代价太大,宁可不那么智能,放出选择性,更能提供选择,适应多个场景 - 分析问题时,如何判断是否合适的标准?
比如 :发送c2s_raw,接收到s2c_noti,合适吗?
说明:设计需要容易理解,不造成混乱,逻辑性强 - 隐藏问题,以及分析问题如何推导?
比如:设备回复93,94,但是都采用noti回复,隐藏了bug如何分析出。 比如:如何分析出read和read2,还是增加sn字段来,以及ack指令来?
说明:分析就一步步将各种场景推导一遍,先分支,在各分支深入 - 多种方案,可做可不做的问题如何决策?
比如:采用字段,还是新开指令
比如:ack需要客户端做吗
说明:回归本质,明确定义,作用,范围
|