20210421关于baitsfilter于modbusbox是属于被动性组件的原因 - ziyouzy/2021blog GitHub Wiki

首先说modbusbox的问题
虽然表面上他是程序初始化结束后，自始至终像tousrio808发送消息
他和之前所构思的诸如fromflutter组件中的door功能模块
或者也可能会设计出的独立的door模块是有区别的
因为door的逻辑是先发送开门modbus，然后每隔一秒发送报告前端“还差几秒关闭”的event，最后秒数为0时再发送关门modbus door逻辑是一种触发逻辑，从执行开始到结束大概会使用8到10秒的时间
然后你可以理解成：
modbusbox逻辑也是一种触发逻辑，从执行开始到结束大概会花费“从程序开始运行到退出的时间”

---

接下来探讨baitsfilter
是一个似乎需要去设计的river-node，它可以处理如下场景：
1.usrio808_firstconnectfilter的功能，可以将firstconnect的baits转化成event从而发送给main以及eventbox进行后续处理
2.当一个from进行与to的连接操作时，往往会用到如下逻辑的方法：

func (p *TcpServer_6668)USRIO808_2_FlutterUI(uid string){
ch := fromTcpUSRIO808_Chs[uid]
go func(){
	for baits :=range ch{
		if len(toTcpFlutter_Chs) ==0 {
			_=baits
		}
		
		for _,toCh :=range toTcpFlutter_Chs{
			toch<-baits
		}
	}
}()
}

可以看到如果能始终保持这些代码是最好的，但如过希望from将baits“定向发送”给某个to，就会被迫在这里添加额外的代码逻辑：

for _,toCh :=range toTcpFlutter_Chs{
    containsxxx
    xxxx
    xxxx
    toch<-baits
}

这样不好，因此我准备换一个思路：
那就是永远都让from的baits发送到所有的to，而在to的内部安装用来过滤“是否属于他的baits”的逻辑
这就是我要新设计的river-node，他会作为第一个river-node被装配于各个toRiver
同时他大概会拥有两种mode：

1.ignore模式，如果是不属于自身river的baits直接交给“_”
2.newChan模式，如果是不属于自身river的baits交给newChan_News管道
3.event模式，如果是不属于自身river的baits转化为(交给)events
4.error模式，如果是不属于自身river的baits转化为(交给)errors

或许会担心如果我想同时使用newChan于event两个模式怎么办，是否需要实现“newChan|event”这样的组合功能？答案是不
正确的解决方法是，让这个river拥有两个baitsfilter模块，一个模式为newChan，一个为event，并在river内部实现他们的相互连接
ps：之前所设计的eventfliter同样是这种使用技巧