Return-Path: MIME-Version: 1.0 In-Reply-To: References: <9B25967D-16B8-4335-BE03-8FFD02D400FB@sense.com> <5234EF82-463D-4521-ABDB-C68132933BD7@sense.com> <1AE5314A-1E01-43B7-AFA3-4D82DA9ED755@sense.com> <1FA6F703-9CED-43FC-8CA0-BD3F1680EED9@sense.com> From: Emil Lenngren Date: Thu, 7 Sep 2017 12:47:26 +0200 Message-ID: Subject: Re: [PATCH v2] gatt-server: Implement NegotiatedMTU property on Device1 To: Luiz Augusto von Dentz Cc: Jonah Petri , Bluez mailing list Content-Type: text/plain; charset="UTF-8" Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi 2017-09-07 12:22 GMT+02:00 Luiz Augusto von Dentz : > Hi Jonah, > > On Thu, Sep 7, 2017 at 3:09 AM, Jonah Petri wrote: >> Hi Luiz, >> >>> On Sep 6, 2017, at 3:57 PM, Luiz Augusto von Dentz wrote: >>> >>>>> >>>>> Also, the AcquireWrite and AcquireNotify should fulfil most of the us= e >>>>> 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 on= ly publish GATT attributes which are length <=3D 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 i= t, 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=E2=80=99m implementing is a fairly typical =E2=80=98uart-= on-btle=E2=80=99 protocol, of the sort supported by many BT vendors, especi= ally for embedded MCUs. Reads of GATT attributes above the MTU - 3 thresho= ld are truncated in the client=E2=80=99s bt stack, but the clients typicall= y don=E2=80=99t realize it, so they get corrupted data. However, for clien= ts which support a larger MTU, the transfer speeds can be much faster, as t= he MTU is larger. (yes, we=E2=80=99re still talking about a few kb/sec, bu= t 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=E2=80=99re right that BTLE isn=E2=80=99t exactly the righ= t way to do this. You don=E2=80=99t need to convince me of this. But I do= have a need for getting the MTU, to implement the protocol without corrupt= ing 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=E2=80=99m implem= enting a gatt server, and those interfaces are marked as =E2=80=98Client On= ly=E2=80=99. > > 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. > > -- > Luiz Augusto von Dentz