Hi Luiz,
On 13.07.2017 13:18, Luiz Augusto von Dentz wrote:
Hi Olivier,
On Tue, Jul 11, 2017 at 7:31 PM, Olivier MARTIN <olivier@xxxxxxxxxxxx>
wrote:
Hi Luiz,
Ubuntu 16.04 LTS is shipped with bluez v5.37. You could argue Bluez
v5.37
does not officially support GATT over DBus as the support is still
experimental which is true. And because v5.37 does not support GATT
Long
Write, developers should not use Bluez prior to v5.42 (date when GATT
D-Bus
API is marked as not experimental anymore).
As the GATT client might also send packet longer than 20 bytes, the
client
also needs to support Long Read/Write (same as GATT server).
From my quick search, it looks Long Read/Write support is not well
supported
by all GATT server/client. I do not know whether it is a correct
assumption
or developers are not aware of its support.
At the moment I am using a protocol on top of GATT to send my payload
in
chunk. I sometimes send payloads as large as 200 bytes. By sending 19
bytes
(+ 1 bytes for the application protocol to support chunk) I need 11
GATT
characteristic writes while I could send only 1 packet if I knew the
ATT MTU
could have been increased to 203 bytes or more.
Throughput is not critical but it has a high importance in my use case
(Human Machine interface).
By increasing my hardcoded payload from 20 bytes to 200 bytes (because
I
know the negociated ATT MTU is 512 bytes), my application test time
execution dereases from 32sec to 11sec. If I knew the ATT MTU (for
instance
from D-Bus Bluez), I could replace the hardcoded value by the
negociated
one.
So it is 22 sec of round trips, not only over the air but also D-Bus
message round trips between processes.
If I had some confidence Long Read/Write feature was well supported, I
will
be happy to use it. But I am worry it is not - but I could be wrong.
What do
you think?
If you control both GATT server and client why not use write without
response and notifications, then you can use AcquireWrite and
AcquireNotify and write/read using the given fd and MTU.
I can see AcquireWrite and AcquireNotify are marked as experimental in
the current Bluez. So it means it will not be supported by current
distributions.
Unfortunately I do not control the GATT server and client. My project is
a software protocol that I aim to deploy on various Bluetooth software
stack/firmware from various vendors (Bluez, Windows, Apple, Android +
different firmware vendor, MCU such as Nordic).
I am a bit concern if I use Long Write/Read, I will spend a lot of time
supporting Bluetooth stack variations.
I would be happy to use Long Write/Read if the feature could be probed
to know if it is supported by the BLE device and fallback to the
application protocol if not supported. But I guess by specification, it
is assumed the feature is always be present and supported.
I am considering to use my application packet protocol by default and
use a mechanism to let know the GATT server and client Long Write/Read
are supported by both devices to then switch to use them.
Exposing the ATT MTU through Bluez D-BUS API would solve my issue even
if it is a workaround in term of GATT specification. For diagnostic
purpose, it might still be helpful to have the MTU exposed in D-BUS API.
I am happy to have a try to add the support for ATT MTU to Bluez D-BUS
Device API myself if you think it is feasible and the patches will be
accepted (obviously after being approved on the mailing-list).
--
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
