当使用 Bluez 的 DBus API 编写应用程序以充当 Gatt 服务器时,通过调用ReadValue
和AcquireNotify
命令给出的 MTU 将 MTU 报告为 517。
数据通道有效载荷的最大大小为 251 个字节(27 个没有数据长度扩展)。由于 4 字节 L2CAP 标头,我们的最大 MTU 为 247。
ATT_MTU 是否独立于链路层的数据长度限制?数据是否在较低级别分段?如果是,最大 ATT_MTU 是多少?
当使用 Bluez 的 DBus API 编写应用程序以充当 Gatt 服务器时,通过调用ReadValue
和AcquireNotify
命令给出的 MTU 将 MTU 报告为 517。
数据通道有效载荷的最大大小为 251 个字节(27 个没有数据长度扩展)。由于 4 字节 L2CAP 标头,我们的最大 MTU 为 247。
ATT_MTU 是否独立于链路层的数据长度限制?数据是否在较低级别分段?如果是,最大 ATT_MTU 是多少?
ATT_MTU 是一个 16 位的数字,因此它最多可以是 65535。但是 ATT_MTU 是在两个设备之间协商的,并将设置为两个设备的最大 ATT_MTU 的最小值。
但是一个特征只能是 512 字节,所以像 65535 这样大的 mtu 通常是没有用的。你必须使用“读取多个特征”或类似的方法才能使用这么大的 mtu。
ATT_MTU完全独立于链路层数据长度,由hci和链路层自动分片。L2CAP 主机通常是重组数据包的主机。
是的,ATT_MTU 与链路层的数据长度限制无关。顾名思义,ATT_MTU 与 ATT 层可以传输的最大数据量有关,而普通数据包长度与物理层可以发送的最大数据量有关。
正如您所建议的,这意味着如果 ATT_MTU 大于最大物理数据包长度,则数据将在较低(物理)层中分段。例如,如果最大 ATT_MTU 是 517 而最大块 BLE 块是 251,这意味着您发送的数据将被分成 251 个字节的块。这就是为什么理想的 ATT_MTU/数据包长度组合通常是 ATT_MTU 为 247,数据包长度为 251。
至于最大 ATT_MTU,我认为这不是蓝牙规范中指定的,因此应该取决于芯片。蓝牙规范确实提到属性的最大长度应该是 512(蓝牙核心规范 5.2,第 3 卷,F 部分,第 3.2.9 节长属性值):-
属性值的最大长度应为 512 个八位字节。
因此 ATT_MTU 为 515 或更高肯定能够传输蓝牙规范允许的最大属性。
您还可以查看以下链接以获取更多信息:-