这个设计图是根据多年的经验，在多种不同平台上应用，总结出来的。

因为任何平台，速度都是 服务器CPU > HOST CPU（Linux主机或Openwrt主机） > 协调器CPU > 串口传输 > 无线传输（zigbee传输）。

协议栈需要做的就是把ZDP的Data Confirm开放出来，可以回溯对应的发送指令。

第一个串口应答ACK是ZGC的ACK，HOST的UART可以发一条等一条，因为这个影响时间是SOC的CPU决定，SOC的CPU即使再慢，也肯定是比无线传输快的，也比UART传输快。

然后就是Send Confirm的信息，ZGC里面也有这个接口，但是ZDP的Send Confirm里面无法获取对应哪条发送指令。根据实际测试，协调器向不同设备发送指令，收到Send  Confirm的延迟时间也不同，而且收到Send Confirm的顺序会乱序，同时在等待Send Confirm的时候会收到其它设备发给协调器的消息，通常这些消息都不应该丢弃。而且如果目标设备被人为断电的情况下，Send Confirm会等很长时间，然后返回错误。

在协调器对多个目标发送多条指令的时候，可以把Send Confirm利用起来。每次给一个目标发送指令后，需要等待该目标的Send Confirm，在等待的间隙可以给其它设备发指令。另外遇到目标设备关机的情况下，Send Confirm返回错误信息，HOST就不用再去等待Response。

这种情况常见于大量设备同时入网，网关需要读取目标设备的Active Endpoint和Simple Description信息。当前版本协议栈，ZDP Send Confirm无法回溯对应的指令，导致我们在应用中都强制要求客户一次性同时入网的设备不能太多，比如禁止同一个AC电路上同时上电的入网设备不能超过10个。