Hi Olivier,
On Tue, Jul 11, 2017 at 1:54 PM, Olivier MARTIN <[email protected]> wrot=
e:
> Thanks Luiz for the answer, but I am guessing WriteValue() uses Long Writ=
e.
> But it looks like not all BLE devices support Long Read/Write (including
> Bluez until recently - v5.39 - April 2016). It also seems some/all(?)
> Android devices do not support it.
I wouldn't call recently a more than one year only release and I guess
the versions that don't support, and I though Long Write is mandatory
for the server at least for the complete server:
C.4: Mandatory IF GATT 1/4 =E2=80=9CComplete GATT Server=E2=80=9D is suppor=
ted,
otherwise Optional.
or are you talking about Reliable Writes?
> I did not find this information but is a device that does not support Lon=
g
> Write; would the application still receive GATT packets sent by Long Writ=
e
> in a defragmented manner?
I guess the remaining bytes over the MTU would not be sent since that
would require Prepare Write operation which I guess fail with such
devices and since regular Write Request don't have an offset we cannot
continue sending.
> The workaround often uses is to leave the GATT server fragmenting itself =
the
> packets to send to the GATT client with an arbitrary packet length value.
> Knowing the MTU uses between the two GATT devices could improve the
> throughput.
I guess you mean the GATT server will not be able to reassemble thus
you send in chunks as big as the MTU, but this presumes there is
something in the data payload that is doing sar, so a protocol on top
of GATT.
But be aware that most OSes don't protect against multiple clients
writing to the same attribute, not to mention there can be quite big
latencies since GATT has a 30 seconds timeout for each request which
is why usually Write Without Response procedure is used with such
operations.
If you care about throughput then using D-Bus to pipe data is probably
very inefficient, L2CAP CoC would probably be the best solution to
something like a serial port emulation over LE, but sadly Android and
iOS still don't support that.
--=20
Luiz Augusto von Dentz
Hi Jonah, Luiz and all,
On 14.07.2017 14:02, Jonah Petri wrote:
>>
>>> 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).
>>
>> It would have the same treatment as AcquireWrite and AcquireNotify so
>> at the start it would probably be marked as experimental. Note that
>
> I have a patch for this exact need (reading the negotiated MTU), which
> I can submit later today for consideration.
I also started to look at adding this support this morning. But I had to
interrupt my work. So I will be happy to have a look and review your
patch as I have a clearer idea of the code now.
Thanks to Luiz and after doing a little break, I realised I need to
change my application protocol to take advantage of AcquireWrite and
AcquireNotify.
I am quite convince now I will have a better throughput using these
methods than using my current application protocol.
>=20
>> 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).
>=20
> It would have the same treatment as AcquireWrite and AcquireNotify so
> at the start it would probably be marked as experimental. Note that
I have a patch for this exact need (reading the negotiated MTU), which I =
can submit later today for consideration.
Jonah=
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 <[email protected]>
> 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).
Hi Olivier,
On Fri, Jul 14, 2017 at 1:47 AM, Olivier MARTIN <[email protected]> wrote:
> 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 <[email protected]>
>> 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.
It hasn't been released yet, but at first all API are marked experimental.
> 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.
Read again, I did not suggest you to use Long Write, and when I said
control the server I mean control the attribute/characteristic
definition so you can define it to use write without response and
notifications since that is indicated in the characteristic
properties.
> 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.
There is nothing to detect that Long Write is supported upfront, so
you would have to actually write to see if that works, but then again
why would like to go this way if you can use write without response
and notifications?
> 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).
It would have the same treatment as AcquireWrite and AcquireNotify so
at the start it would probably be marked as experimental. Note that
--
Luiz Augusto von Dentz
Hi Olivier,
On Tue, Jul 11, 2017 at 7:31 PM, Olivier MARTIN <[email protected]> wrot=
e:
> 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-B=
us
> API is marked as not experimental anymore).
>
> As the GATT client might also send packet longer than 20 bytes, the clien=
t
> also needs to support Long Read/Write (same as GATT server).
> From my quick search, it looks Long Read/Write support is not well suppor=
ted
> by all GATT server/client. I do not know whether it is a correct assumpti=
on
> 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 byt=
es
> (+ 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 instan=
ce
> 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 wi=
ll
> 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.
>
>
> On 11.07.2017 15:01, Luiz Augusto von Dentz wrote:
>>
>> Hi Olivier,
>>
>> On Tue, Jul 11, 2017 at 1:54 PM, Olivier MARTIN <[email protected]>
>> wrote:
>>>
>>> Thanks Luiz for the answer, but I am guessing WriteValue() uses Long
>>> Write.
>>> But it looks like not all BLE devices support Long Read/Write (includin=
g
>>> Bluez until recently - v5.39 - April 2016). It also seems some/all(?)
>>> Android devices do not support it.
>>
>>
>> I wouldn't call recently a more than one year only release and I guess
>> the versions that don't support, and I though Long Write is mandatory
>> for the server at least for the complete server:
>>
>> C.4: Mandatory IF GATT 1/4 =E2=80=9CComplete GATT Server=E2=80=9D is sup=
ported,
>> otherwise Optional.
>>
>> or are you talking about Reliable Writes?
>>
>>> I did not find this information but is a device that does not support
>>> Long
>>> Write; would the application still receive GATT packets sent by Long
>>> Write
>>> in a defragmented manner?
>>
>>
>> I guess the remaining bytes over the MTU would not be sent since that
>> would require Prepare Write operation which I guess fail with such
>> devices and since regular Write Request don't have an offset we cannot
>> continue sending.
>>
>>> The workaround often uses is to leave the GATT server fragmenting itsel=
f
>>> the
>>> packets to send to the GATT client with an arbitrary packet length valu=
e.
>>> Knowing the MTU uses between the two GATT devices could improve the
>>> throughput.
>>
>>
>> I guess you mean the GATT server will not be able to reassemble thus
>> you send in chunks as big as the MTU, but this presumes there is
>> something in the data payload that is doing sar, so a protocol on top
>> of GATT.
>>
>> But be aware that most OSes don't protect against multiple clients
>> writing to the same attribute, not to mention there can be quite big
>> latencies since GATT has a 30 seconds timeout for each request which
>> is why usually Write Without Response procedure is used with such
>> operations.
>>
>> If you care about throughput then using D-Bus to pipe data is probably
>> very inefficient, L2CAP CoC would probably be the best solution to
>> something like a serial port emulation over LE, but sadly Android and
>> iOS still don't support that.
>
>
> http://labapart.com
--=20
Luiz Augusto von Dentz
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.
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?
On 11.07.2017 15:01, Luiz Augusto von Dentz wrote:
> Hi Olivier,
>
> On Tue, Jul 11, 2017 at 1:54 PM, Olivier MARTIN <[email protected]>
> wrote:
>> Thanks Luiz for the answer, but I am guessing WriteValue() uses Long
>> Write.
>> But it looks like not all BLE devices support Long Read/Write
>> (including
>> Bluez until recently - v5.39 - April 2016). It also seems some/all(?)
>> Android devices do not support it.
>
> I wouldn't call recently a more than one year only release and I guess
> the versions that don't support, and I though Long Write is mandatory
> for the server at least for the complete server:
>
> C.4: Mandatory IF GATT 1/4 “Complete GATT Server” is supported,
> otherwise Optional.
>
> or are you talking about Reliable Writes?
>
>> I did not find this information but is a device that does not support
>> Long
>> Write; would the application still receive GATT packets sent by Long
>> Write
>> in a defragmented manner?
>
> I guess the remaining bytes over the MTU would not be sent since that
> would require Prepare Write operation which I guess fail with such
> devices and since regular Write Request don't have an offset we cannot
> continue sending.
>
>> The workaround often uses is to leave the GATT server fragmenting
>> itself the
>> packets to send to the GATT client with an arbitrary packet length
>> value.
>> Knowing the MTU uses between the two GATT devices could improve the
>> throughput.
>
> I guess you mean the GATT server will not be able to reassemble thus
> you send in chunks as big as the MTU, but this presumes there is
> something in the data payload that is doing sar, so a protocol on top
> of GATT.
>
> But be aware that most OSes don't protect against multiple clients
> writing to the same attribute, not to mention there can be quite big
> latencies since GATT has a 30 seconds timeout for each request which
> is why usually Write Without Response procedure is used with such
> operations.
>
> If you care about throughput then using D-Bus to pipe data is probably
> very inefficient, L2CAP CoC would probably be the best solution to
> something like a serial port emulation over LE, but sadly Android and
> iOS still don't support that.
http://labapart.com