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. -- Luiz Augusto von Dentz -- 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
