Hi Emil, On Thu, Sep 7, 2017 at 1:47 PM, Emil Lenngren <emil.lenngren@xxxxxxxxx> wrote: > Hi > > 2017-09-07 12:22 GMT+02:00 Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx>: >> Hi Jonah, >> >> On Thu, Sep 7, 2017 at 3:09 AM, Jonah Petri <jonah@xxxxxxxxx> wrote: >>> 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!) >> >> I will have to repeat this over and over, there are better solutions >> to this than GATT, what we are seeing here is perhaps the lack of >> support in Android. After these many years of L2CAP CoC being around >> it really beats me why no vendor took the task to just implement it >> and contributed to Android instead of working around it via GATT/ATT >> and then blaming the peripheral stack for the lack of serial over >> GATT/ATT. Not only this would bring proper serial support but things >> like IPSP, Object Transfer, and other profiles that do use L2CAP CoC. >> >>> 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’. >> >> So lets fix that and on the plus side you might get even better >> transfer speeds since we can bypass D-Bus entirely. > > > I fully agree that the GATT specification kind of sucks for > throughput-applications since it is, as you say, only meant to be used > for small data transfers. But we have to remember that there are A LOT > of devices and protocols out there that use GATT to stream data > instead of L2CAP CoC since that was previously the only way to send > data, so this still have to be dealt with. And if one uses Write > Without Response and Notifications, GATT is only 1 extra byte overhead > compared to L2CAP CoC per packet anyway, so it's not _that_ bad if > used optimally. 1 extra byte if you don't do any segmentation/reassembly which is normally the first thing to add follow by some sort of flow control. Also something that most people forget is that L2CAP is connection oriented, we can create dedicated socket per application, something not possible in GATT/ATT which is why locking was necessary for AcquireWrite/AcquireNotify otherwise another application can start sending/receiving which may corrupt the data. -- 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
