站长统计
像所有的⽹络传输协议⼀样，应⽤层能感知到的丢包有可能产⽣于应⽤层之下的所有层。
滚刷
对于蓝⽛BLE⽽⾔，进⼀步细化从机到主机的数据传输场景(假设使⽤的是Notify⽅式传输)，其数据传输路径为：
检查井盖1、从机的应⽤层产⽣数据。
2、从机将数据从Host上位机转交给Controller下位机。网络巡检
3、从机Controller通过调制器，将数据在连接事件的射频Tx阶段发出。
4、主机Controller同时开启射频Rx阶段，接收⽆线电波并通过解调器还原数字信号。
5、主机将数据从Controller下位机转交给Host上位机。
6、主机的应⽤层接收数据。
根据上⾯的流程，进⼀步分析⼀下可能产⽣数据丢包的环节。
在步骤2中，Host调⽤HCI函数将数据提交给Controller发送之前，会先将数据存放在Controller的数据缓冲区中，不同的蓝⽛芯⽚这个缓冲区的⼤⼩不同，⽐如Ti CC2541的射频缓冲区只有4个PDU(4*20字节)的⼤⼩。在缓冲区存满后继续调⽤HCI的Notify等函数会返回缓存区满状态位标识。这是第⼀个有可能产⽣丢包的位置，若缓冲区满且开发者没有对此状态位进⾏校验，则应⽤层产⽣的数据会在传递给链路层之前丢失。炭化
在步骤3、4中，从机的Controller在连接事件的Tx阶段，会通过射频依次发送缓冲区数据，并在下⼀个Rx阶段根据捕获和解析对端主机的数据包，从其链路层报头中读取NESN来确认其在上⼀个Tx阶段发送的数据包是否被对端主机链路层正确接收。由于链路层数据包序列号校验机制(SN 和NESN)和重传机制的存在，基本可以保证数据在物理层和链路层阶段不会产⽣丢包，这跟互联⽹的传输层TCP协议校验数据包序列和完整性基本类似。 之所以上⾯⽤“基本”⼆字，是因为这⾥还是存在第⼆个有可能产⽣丢包的位置。由于BLE中使⽤的CRC校验是弱CRC，其只能保障传输字节的全部偶数位和部分奇数位不产⽣错误，并⽆法保证所有数据在传输过程中不出错。那么⼀个可能性极⼩的场景是：CRC弱校验通过，但实际上NESN出现了错误，⽽将本来应该是0的位识别成了1，或者相反。⽽这个位差错让本来应该是错误的序列号交替变成了正确的。
在步骤5中，主机将数据从Controller向上派发到Host，并转到应⽤层触发回调通知。这⾥是第三个可能产⽣丢包的地⽅。原因同步骤2，但这⾥还有⼀点⼩区别，就是notify跟indicate的区别(反向传输中的write with/without response也是同理)，其本质区别是数据接收成功的判断标志是以链路层确认为准还是以应⽤层确认为准。前者是notify采⽤的⽅式，⽽后者是indicate采⽤的⽅式。可见如果采⽤notify做数据传输，链路层到应⽤层这⼀步依然是有丢包的可能，⽐如链路层的数据传输速率⼤于应⽤层的回调函数中对数据处理的速率，导致Host中数据缓冲区持续增长，当缓冲区满后，主机的Controller将丢弃⽆法继续保存的数据，并不会通知对端设备重传。
⽽indicate⽅式下，每⼀个数据包的成功确认都是以应⽤层回调处理执⾏完成为标志，⽽通常数据的逻辑处理是⼀个耗时的操作，并且由于数据是在连接事件内接受到，但同⼀个连接事件在开始的时候主从机两端的数据就已经准备好，由于连接事件的持续事件极短，在这段时间内Controller 的所有⼯作都集中在射频的发射上，⽽不会从Host上位机接受数据和响应，甚⾄有的蓝⽛芯⽚会有选项在这段时间内直接挂起CPU，以防⽌其他中断信号同步到达，⼲扰到射频数据的发送效率。所以在indicate⽅式下，⼀个数据包⾄少要横跨两个甚⾄更多的连接事件时长才可以确认到达，从⽽发送下⼀个数据包，这就是有响应的数据发送⽅式⽐⽆响应要慢的原因。
最后⼀点，由于Android操作系统封装了蓝⽛低层驱动和实现，以上的6个步骤即使都正确完成，也只是意味着Bluez或者Bluedroid这⼀层正确拿到了数据，但App要接收到这些数据还存在⼀个从操作系统
弹簧制作到App的数据派发过程，indicate的数据确认是在App得到数据派发并执⾏完成回调后确认，但notify会在Bluedroid接受到数据后即完成链路层确认。⽽Bluedroid向App的数据派发⼜存在⼀个缓冲区，当蓝⽛连接⽽App没有运⾏的情况下缓冲区满依然会产⽣丢包。(Android好像很难模拟这种情况，iOS在通过调试器终⽌App进程的时候经常会造成蓝⽛连接链路不同步断开)
>氢氧化钙生产
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议