Hi Vinicius, My explanations were based entirely around OIC?s BLE-GATT profile that I authored about a year ago, and which documented the design. I believe all LE connectivity adapters had eventually conformed to it. Also, the profile made NO mention of ever using the CoAP_TCP serialization over BLE, and instead proposed to utilize CoAP?s own reliability semantics over GATT.
I just briefly looked at the commit you mentioned, and see a few recent changes, and see why you?re asking this question. It might be OK to use CoAP_TCP over BT EDR (which uses RFCOMM), but not over BLE, at least the way it was initially designed for OIC. I?m not sure what the developer had in mind, or if they?ve also updated OIC?s BLE profile to address the consequences of these changes. I?m glad to at least see TCP support as a build-time option. >> ..fragmentation and reassembly mechanism chosen is based >> on a expired draft: ? fragmentation and reassembly >> mechanism chosen is based on a expired draft: ? and is >> effectively a proprietatry protocol I don?t disagree on that point. I?m not aware of what is currently being done. I had suggested the possible use of CoAP block options for this purpose, which seemed like a natural choice, but the decision was made and agreed upon by the implementers. So, to hasten your progress at this point, my suggestion would be to adhere to the BLE profile (i.e. without the CoAP TCP adaption) and check/discuss with the associated developer(s) to understand their chosen fragmentation/reassembly procedure. Thanks, -Kishen. On 2/22/16, 6:23 AM, "Gomes, Vinicius" <vinicius.gomes at intel.com> wrote: >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
