Hi Vinicius, On Fri, Feb 19, 2016 at 11:07 AM, Vinicius Costa Gomes < vinicius.gomes at intel.com> wrote: > > When implementing the IoTivity (I couldn't find a complete specification > for this in OIC, so the work used IoTivity as reference) GATT transport > in Soletta[1], we found a couple of problems: > > * IoTivity uses a few BlueZ D-Bus APIs that have changed > upstream, for example, org.bluez.GattManager1.RegisterService() has > changed to org.bluez.GattManager1.RegisterApplication() (this API is > marked as experimental, so the usual stability guarantees doesn't > apply); >
The new BlueZ GATT API you pointed out hasn't been released yet. BlueZ 5.37, the latest release, still implements the older API. IoTivity's Linux BLE transport was originally based on the GATT API exposed by BlueZ 5.31. The BlueZ GATT APIs changed due to a D-Bus specification violation where the GATT service D-Bus object path was incorrectly expected to be rooted at the same level as the Object Manager. No one has gotten around to updating IoTivity to conform to the new (unreleased) BlueZ GATT API yet. * Over Bluetooth Low Energy transport, IoTivity uses the same header > format as CoAP over TCP, but based on a draft that has already > expired, see here: > https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ > (also, the necessity of this header in Bluetooth Low Energy could be > discussed, as GATT maps to a reliable datagram based transport) > > * Performing the fragmentation on IoTivity's side seems unnecessary, if > the value to be written is larger than the negotiated MTU, BlueZ will > perform the Write Long Characteristic procedure if necessary, then > it's just a matter of requiring devices to implement the necessary ATT > operations; > That's only true if the "reliable-write" or "write" property is set for the BlueZ GATT Characteristic. IoTivity (and the OIC Bluetooth Transport Profile) uses "write-without-response", which doesn't exhibit the behavior you described. Furthermore, currently only the Linux BLE implementation in IoTivity uses BlueZ. We can't count on this behavior for the platforms that do not use BlueZ. In any case, I don't know all of the details for why the Write Long characteristic procedure was not chosen for IoTivity's BLE transport, but I assume it's because Write Long blocks waiting for a reply whereas Write Without Response does not. HTH, -Ossama -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160219/27d7bcf9/attachment.html>
