实际在Android和iOS中央/外围设备上协商Bluetooth LE ATT MTU

Question

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

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

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

Answer 1

根据我的理解，requestMtu()应该从中央角色设备发起，因为它知道要传输和接收多少数据。一般来说，在任何客户端服务器模型中，始终由客户端告知或协商会话参数。因此，我觉得即使在 BLE 的情况下，同样的规则也适用。