5

在 Android 上，我们有requestMtu和onMtuChanged，这似乎意味着我们必须手动协商 MTU 大小，如果中央设备和外围设备都是基于 Android 的（但我可能错了，它可能在连接时自动发生而无需我干预）。仅讨论写入请求（无响应写入）操作的文档requestMtu并没有提及通知，并且还说它是用于“连接”但没有提及它是来自中央还是外围。 因此，尚不清楚连接的哪一侧可以/应该使用requestMtu以及它如何影响通知大小和写入大小？

在 iOS 上，似乎没有直接的替代方案requestMtu，我们只有central.maximumUpdateValueLength（我猜是从 iOS 7 开始）。它的文档（与 Android 的文档相反）说这maximumUpdateValueLength仅用于通知更新，这意味着它仅在外围设备端有用，因为您将通知从外围设备发送到中央。 但是写呢？如果我正在写入（再次没有响应）从中央到外围的特征，我如何知道我的批量大小以确保高效写入？

考虑到混合系统（Android/iOS 中央/外围），这一切都变得令人困惑，并且完全不清楚哪一方以及何时可以/应该请求/响应 MTU 大小协商。是否有任何文档描述 ATT MTU 交换选项，对应于真正的 Android 和 iOS 实现？

4

2 回答 2

1

根据我的理解requestMtu()，应该从中心角色设备开始，因为它知道它将发送和接收多少数据。通常，在任何客户端服务器模型中，总是由客户端告知或协商会话参数。因此，我觉得即使在 BLE 的情况下，同样的规则也适用。

于 2017-03-28T16:41:45.497 回答
0

根据BLE标准，双方可以交换MTU。当设备充当客户端和服务器时，相同的 MTU 适用于两者。

于 2017-03-29T11:20:31.063 回答