Return-Path: Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH v2] gatt-server: Implement NegotiatedMTU property on Device1 From: Jonah Petri In-Reply-To: Date: Wed, 6 Sep 2017 20:09:23 -0400 Cc: Emil Lenngren , Bluez mailing list Message-Id: <1FA6F703-9CED-43FC-8CA0-BD3F1680EED9@sense.com> References: <9B25967D-16B8-4335-BE03-8FFD02D400FB@sense.com> <5234EF82-463D-4521-ABDB-C68132933BD7@sense.com> <1AE5314A-1E01-43B7-AFA3-4D82DA9ED755@sense.com> To: Luiz Augusto von Dentz Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi Luiz, > On Sep 6, 2017, at 3:57 PM, Luiz Augusto von Dentz = wrote: >=20 >>>=20 >>> 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? >>=20 >> I'm merely conforming to an existing protocol, which requires me to = only 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 it, for optimal throughput. >=20 > 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, especially for embedded MCUs. Reads of GATT attributes = above the MTU - 3 threshold are truncated in the client=E2=80=99s bt = stack, but the clients typically don=E2=80=99t 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=E2=80=99= re still talking about a few kb/sec, but 4x faster is 4x faster!) =20 Of course, you=E2=80=99re right that BTLE isn=E2=80=99t exactly the = right 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 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=E2=80=99m = implementing a gatt server, and those interfaces are marked as =E2=80=98Cl= ient Only=E2=80=99. Regards, Jonah