最近遇到一个蓝牙传输问题的BUG。
BUG描述:测试机与辅助机发送文件,测试机显示传输100%,辅助机显示接收99%。
BUG结论:测试机最后没有收到辅助机发送的credit信息,导致测试机不能再发送data过去。需要辅助机侧查看问题问题原因。
借此机会,梳理了部分RFCOMM/L2CAP的阻塞逻辑,在此简单记录一下。
阻塞分两个地方 : RFCOMM 和 L2CAP
RFCOMM的阻塞由credit决定,RFCOMM建立之初,接收方会给发送方授权credit = 7。允许发送方发送7包,接收方每接收一个rfcomm数据包,就会将可接受的数据-1,当可接收的数据<=4的时候,接收方就会再次给发送方credit。由于最大可接收的credit设定为34,所以此时接收方将发送一个credit = 34 - 4 到发送方,发送便可继续发送rfcomm,不然就默认当前rfcomm拥塞。发送端一旦将授权的个数用完之后,就将处于拥塞状态,等待接受方的授权credit来了,此继续发送。
L2CAP的阻塞由自身决定。当RFCOMM建立的时候后,双方交互每一个put的最大值,一般情况为65334,每一包为1004,差不多就是64包的样子。每一次协议栈都从上层读取65334长度的数据,然后一股脑就发送到L2CAP。L2CAP在每个channel上接收到一包需要发送的数据之后,都会去判断quota是否已经过大,上限一般设置为34,所以一旦l2cap包缓存了35时,就会认为拥塞,不再接受rfcomm的数据,直到缓存数据只有最大值的一般,也就是17的时,结束拥塞,上层才可以继续下发数据包。