Write Without Response (and notification) characteristics were chosen because of their asynchronous behavior at the LE layer, whereas reliable write/write along with the write long characteristic procedure enforces the need for acknowledgements to every write over the LE network layer.
Furthermore, it is IoTivity PDUs going over the air directly, and not UDP packets (so your suggestion of CoAP over TCP doesn?t and shouldn?t even apply here) Since IoTivity PDUs happen to be larger than (I think) 20 bytes, we require fragmentation and reassembly which is performed in the application (IoTivity framework in this case). This is the design, and that is how it is implemented in all supported IoTivity platforms. Support for secure connections (i.e. to be secured by IoTivity?s security model) over BLE is currently an open issue, and I believe is/will be addressed. -Kishen. On 2/19/16, 1:04 PM, "iotivity-dev-bounces at lists.iotivity.org on behalf of Vinicius Costa Gomes" <iotivity-dev-bounces at lists.iotivity.org on behalf of vinicius.gomes at intel.com> wrote: >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 >_______________________________________________ >iotivity-dev mailing list >iotivity-dev at lists.iotivity.org >https://lists.iotivity.org/mailman/listinfo/iotivity-dev
