20210301思路总结 - ziyouzy/2021blog GitHub Wiki

服务端暂时只设计到通过udp返回给ui端一个无状态physialNode，而是否超限的逻辑判断则留给前端去做

Errors只录入日志，而Siganls往往会是触发逻辑+录入日志

对于Signal/Error的错误编号我呢提，采用了限定错误编号范围，目前river-node包为0199，usr-io808为200219

对于river与river的对接问题，那当前的package riverconn，我将原来的字段名进行了如下修改

type Client struct{
    Sources net.Conn
}

他与river-node的Raws是对应的，区别在于Sources不需要必须是一个管道数据类型，也不介意自身是一个管道类型,之后很可能会有如下的操作方式：

newRiver := &NewRiver{
                Sources:    crcPassNews,
                XXX:        xxx,
            }

取消密文的相关逻辑，画蛇添足了

对于riverconn最后的收尾操作：

外层接下来要做的并不是基于添加好Stamps的数据去实现Msgs，而是在流入physicalNodes之前进行必须的分流操作：
一个支流会流入physicalNodes

而假如riverDoor真的会让usrio808每隔1秒钟会发来一个反馈门状态的modbus码
则需要分离出这些非physicalNode的modbus码
从而设计出另一个支流流入管道（具体管道内的数据类型未知），这就是你所需要设计的第一个自定义river-node适配器的职责
在你设计他的过程中，自然而然就会想明白Msgs末端该设计成什么样了了

不过将判定交给前端做现在遇到了个不好的地方，那就是短信报警，mysql录入这些操作后端不能独立去完成了
之前是package nodesdo会进行这些工作，会分离出“短信机报警末端“、“mysql末端”
我或许需要更深的思考下这个问题
基于单向调用链原则，虽然可以让客户端经过udp或者tcp连接返回相关预警，但是也相当于数据流动逆流了，这很不合理
正确的方式应该是让前端去直接连接mysql，以及短信机从而实现功能，这样也不好，因为目前本来可以让后端独立的运行，你这样一折腾又变得在功能上不伦不类了
所以还是将判定继续交给后端吧