有一个情形我突然之间想明白了。
注意下面情形：
假设节点A与节点B已经 正常的建立了连接，并且进行了通讯。
假设 节点B收到了 节点A 的 "建立连接"命令
节点B上的连接定时器启动，假设定时为10秒， 同时 节点B置位他的已连接标志
LinkedHard_Flag=1 ; 同时，节点B给节点A上传正常的响应帧， 告知节点A ，节点A与节点B 已经握手成功。
在接下来的10秒内，节点A可以向节点B发送 写数据命令的数据帧，节点B正常的接收的节点A的命令帧以后，就返回给节点A响应帧。
注意两点：（1）在接下来的10秒内，节点B若收到了节点A的命令帧以后，又会将自己（节点B）的定时器的初值重新装载，即重新开始10秒计时。
（2）节点B处于连接中状态（即LinkedHard_Flag=1），在这个前提下，节点B才能接收 写数据 或者 读数据，或者 删除连接的命令帧。
下面就是问题的表现形式了：
LinkedHard_Flag=1标志 对于节点B来讲，仅仅表示了他和网络上的某一节点正在连接，但是具体和哪个网络节点连接是不清楚的，（我目前写的软件，是区分不了B和网络上哪个节点连接的。如果在软件中要体现连接关系，软件会变复杂）。
假设某一时刻，在该时刻B节点处于连接中状态（LinkedHard_Flag=1 ），假设此时C节点 要发送写数据命令帧，给B节点，B节点知道自己在连接状态，固可以接受来自C节点的命令，（目前我软件中是可以接受来自C节点发送的写数据 或者 读数据命令的，我没有区分,这个现象也在试验中验证了，但此时 我如果规定让节点C先发送连接命令，则我软件是可以简单处理的，并告知C节点不能正常连接），
所以：如果节点B处于和节点A的连接中的时候， 节点C突然不按照规则的发送了一个连续 写 或者 连续 读命令帧， （我目前的软件 B可以接收C） ， 那么 我现在该怎么办呢。
实际上： 你还是没有理解这个具体的过程，
硬规定：主机在和网络上某一节点通讯的时候，必须先向从机发送建立连接， 然后从机空闲的情况下，接收到主机的命令，并发送了应答帧。 主机在接收到应答帧以后， 然后置位自己的状态，连接 成功， 主机在这个连接成功的前提下， 才会发送后面的命令帧。。
主机在不建立连接的情况下，命令帧根本就发不出去。
综上，以前的困惑迎刃而解。 你也就理解了握手帧的意义。 这样的规定也使软件的设计简化。
把上面的东西 最后用图画表示。
该部门没有视频与程序