Hi Kishen, "Maloor, Kishen" <kishen.maloor at intel.com> writes:
> 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. > Taking a look at the commit history, it was my impression that was a plan about using the "CoAP over TCP" CoAP header for BLE connections, which implies that the underlying transport is reliable. See the current version of the draft: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-01 There are no CoAP 'ACK' messages, so the transport layer must maintain that reliability assumption. > 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) > See commit d26e1cb "CoAP over TCP transmission over BLE" in the current master. > 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. > One of my points is that as of now the fragmentation and reassembly mechanism chosen is based on a expired draft: https://datatracker.ietf.org/doc/draft-tschofenig-core-coap-tcp-tls/04/ and is effectively a proprietatry protocol, now that the draft expired. > 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 > Cheers, -- Vinicius
