Hi Luiz, > On Sep 6, 2017, at 3:57 PM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > >>> >>> 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? >> >> I'm merely conforming to an existing protocol, which requires me to only publish GATT attributes which are length <= MTU - 3. This is because we can't depend on Long Read and Long Write support from BTLE clients. In cases where a larger MTU has been negotiated, I need to take advantage of it, for optimal throughput. > > Im afraid I don't follow what you are saying about publishing GATT > attributes, the spec doesn't require Long procedures by clients but > that doesn't mean you should omit attributes where their values are > bigger than the MTU or anything like that. Im also not sure why > throughput would be relevant, GATT/ATT is not throughput oriented, it > is a request/response protocol with 30 seconds timeout and on top of > that we have yet another request/response IPC. The protocol I’m implementing is a fairly typical ‘uart-on-btle’ protocol, of the sort supported by many BT vendors, especially for embedded MCUs. Reads of GATT attributes above the MTU - 3 threshold are truncated in the client’s bt stack, but the clients typically don’t realize it, so they get corrupted data. However, for clients which support a larger MTU, the transfer speeds can be much faster, as the MTU is larger. (yes, we’re still talking about a few kb/sec, but 4x faster is 4x faster!) Of course, you’re right that BTLE isn’t exactly the right way to do this. You don’t need to convince me of this. But I do have a need for getting the MTU, to implement the protocol without corrupting the data. Most people implementing the server half of these protocols like this will have the same need. AcquireWrite and AcquireRead are not useful to me, as I’m implementing a gatt server, and those interfaces are marked as ‘Client Only’. Regards, Jonah -- 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
