I?ve implemented block-wise transfers (RFC 7959) in IoTivity-Constrained, and am currently trying to test it against an IoTivity application but am seeing some odd behaviors from IoTivity.
At the moment these appear to be bugs in IoTivity?s BWT implementation. My test setup consists of the simpleserver sample in IoTivity-Constrained and simpleclient in IoTivity. In this test, IoTivity-Constrained has been configured to operate under a limited MTU size which results in a block size of 16 bytes. IoTivity_simpleclient issues a GET request and the IoTivity-Constrained_simpleserver sample returns a payload with the block2 option set. However, IoTivity_simpleclient subsequently returns a confirmable GET request for the next block with i) the same token as the original request, and ii) without the uri_path of the resource being requested. I believe this is incorrect. RFC 7959 suggests that every message exchange in a block-wise transfer resemble a typical CoAP request-response with a randomly chosen token and message_id. This also implies that every request must contain the resource uri_path. Furthermore, when we use the block2 option in an OBSERVE response, the RFC states that requests for subsequent blocks must choose a different token. Even if we were to disregard the choice of token for the sake of argument, requests for subsequent blocks must most certainly include the uri_path so that IoTivity can interoperate with other RFC compliant OCF implementations. Note that I haven?t yet exercised the block1 option through IoTivity. I?m using code form an up-to-date IoTivity master branch. -Kishen. - Kishen Maloor Intel Open Source Technology Center
