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 <olivier@xxxxxxxxxxxx>
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
--
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
