Hi Ossama, "Othman, Ossama" <ossama.othman at intel.com> writes:
> 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. >From what I understand, using the CoAP over TCP headers it is implied that you are using a reliable transport (as there are no ACK messages), for example. just after issuing a Write Without Response request, you receive an event informing that a disconnection occurred, without the reliable-write procedures you have no way to know if the transmission succeeded (or not). > > HTH, > -Ossama Cheers, -- Vinicius
