Hi Jonah, On Wed, Sep 6, 2017 at 4:55 PM, Jonah Petri <jonah@xxxxxxxxx> wrote: > Hi Luiz and Emil, > > Thanks for your comments! > >> On Sep 6, 2017, at 9:01 AM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: >> >>> I know there were some discussions regarding if it should be called >>> max attribute size or mtu. >>> Maybe I'm a bit late but in my opinion I think mtu is a better option. >>> >>> "The maximum supported byte size of attributes, as negotiated between >>> this host and the remote device" is a bit misleading/wrong since the >>> BLE spec allows up to 512 byte attribute values no matter of the MTU. >> >> Note that the MTU can be in fact even bigger than 512 bytes since it >> can be used by things like discover, etc, which is not bound to a >> single attribute, though for practical reasons BlueZ will always >> request 512 bytes since buffer size is usually not a concern in >> systems running Linux. >> >>> You can still perform a Long Write where the attribute value is larger >>> than the MTU for example. >>> Also, the max value size for transfer is different depending on >>> method. Max value size for a notification/indication or normal write >>> is ATT_MTU-3 while max value size for a normal read is ATT_MTU-1. >> >> Yep, we can't really use the same value for read/write since the >> actual payload changes depending on the opcode. >> >>> With the current patch it's not clear (by only looking at the >>> documentation) which value "max attribute size" really means. If it's >>> called MTU it's on the other hand very clear what it is (like it is >>> called in Android's implementation). Even if there is a difference >>> between BD/EDR and LE MTU negotiation, the packet format for ATT and >>> the meaning of MTU is still the same. >> >> The fundamental part missing here is that over BR/EDR the MTU can be >> asymmetric meaning we need the MTU value for input and output to be >> separated. > > Hm. BR/EDR isn't even the intended use case here, and (as you point out) complicates the API greatly. And in general, I agree with Emil that the MTU is really what many clients of this API are interested in. > > What if I reformulate the API as LE-specific, and instead of making the API about Maximum Attribute Size, I return to simply making the MTU available to dbus clients. That's all I really want for my use case, and I'll make an effort to make the documentation sufficiently educational that developers should be able to do the right thing. What about this? Your implementation is not really LE specific, in fact it will cause the clients to believe they connected over LE if the MTU appears, besides with cross transport pairing and dual mode topology this has to work either way or then we have to disable GATT completely on BR/EDR. Also, the AcquireWrite and AcquireNotify should fulfil most of the use cases where GATT is used just as transport to another protocol, is that what you are intending to do? Having an API just for a very specific use case that in the future may actually disappear with OSes adopting L2CAP CoC is not very nice. > + int16 LENegotiatedATTMTU [readonly, > + optional, > + experimental] > + > + The Maximum Transmission Unit of the ATT protocol, > + as negotiated with this device by bluetoothd. This > + property is only available for devices connected via > + BTLE, and only after MTU negotiation is complete. > + If this property is not available, clients may > + only assume a MTU of 23 bytes, as required by the > + Bluetooth specification. > + The maximum GATT attribute data is MTU - 3, although > + some devices may support Long Read and Long Write > + commands, allowing for larger attribute data sizes. > + > > Best, > > Jonah > > -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
