1. 15 Apr, 2020 1 commit
  2. 21 Feb, 2019 1 commit
  3. 09 Jan, 2019 1 commit
  4. 27 Nov, 2018 1 commit
  5. 06 Nov, 2018 1 commit
  6. 13 Aug, 2018 2 commits
  7. 26 Jun, 2018 1 commit
  8. 30 May, 2018 1 commit
  9. 22 May, 2018 1 commit
    • Kishen Maloor's avatar
      Keep two pools of messages in oc_buffer · f5a5db4b
      Kishen Maloor authored
      This change updates oc_buffer to maintain separate pools for
      incoming and outgoing messages. This is done to ensure that rapid
      bursts of incoming messages over the network do not starve a device’s
      ability to respond to known requests.
      To aid this change, oc_message_t has been updated to maintain a handle
      to the pool it was allocated from.
      This change also adds new APIs to:
      -Allocate messages from a given pool (struct oc_memb) instead of
      the preset incoming messages pool. This may be utilized by the connectivity
      implementation, if necessary.
      -Set a buffers_avail callback. This may be utilized by connectivity
      implementations to stall the network thread until a buffer is available
      to ingest an incoming message.
      Change-Id: I2ce5d11ab9539771f0e54bdb1d14a7a6ecbda30d
      Signed-off-by: Kishen Maloor's avatarKishen Maloor <kishen.maloor@intel.com>
      Reviewed-on: https://gerrit.iotivity.org/gerrit/25353Tested-by: default avatarIoTivity Jenkins <jenkins-daemon@iotivity.org>
  10. 07 May, 2018 1 commit
  11. 26 Apr, 2018 1 commit
    • Kishen Maloor's avatar
      Update connectivity interface · fbbb44f9
      Kishen Maloor authored
      * Added new interface to terminate sessions bound to
      connection-oriented transports (Eg. TCP). A connectivity
      implementation would be required to appropriately handle
      this function by interacting with the network stack.
      This function is called by the core framework when its
      time to tear down connections.
      * A connectivity implementation is expected to return
      complete messages to the upper layer. On stream-oriented transports,
      it relies on length information conveyed by the protocol to
      assemble the complete message to send above. However, libraries
      used in the upper layers (Eg. mbedTLS) that are designed ingest
      messages from streams over multiple steps need a means to pick
      up at the spot where they previously left off. For this purpose,
      oc_message_t now has a read_offset property to track this information,
      which is updated at every step, so the oc_message_t object may be
      freed only after all the bytes it contains have been read.
      Change-Id: Idbf7cd5fce13974fdd937273eac893fce19dd92c
      Signed-off-by: Kishen Maloor's avatarKishen Maloor <kishen.maloor@intel.com>
      Reviewed-on: https://gerrit.iotivity.org/gerrit/24941
  12. 03 Apr, 2018 1 commit
  13. 28 Mar, 2018 1 commit
  14. 08 Oct, 2017 1 commit
  15. 22 Sep, 2017 1 commit
  16. 26 Jul, 2017 1 commit
    • Kishen Maloor's avatar
      OCF 1.0 discovery, endpoints, multi-device support · 45d912ef
      Kishen Maloor authored
      This commit brings in many significant changes to the
      handling and processing of discovery requests and
      responses, and also aligns the resource architecture and
      core representations to the OCF 1.0 specification.
      It adds support for OCF 1.0 endpoints to interpret the
      the coap and coaps schemes over IPv4/v6 with platform
      neutral functions to convert IPv4/v6 addresses to/from
      strings and the ability to construct and maintain lists of
      endpoint descriptions for a remote entity by allocating
      from a pool of endpoint structures in both the
      server/client roles.
      In keeping with OCF resource model concepts of a platform
      with logical devices, this commit adds support for the
      definition of multiple virtual servers with an
      application that reside on a single platform.
      Virtual servers are bound to different ports and behave
      as independent entities, separately handling requests.
      All virtual servers expose the required set of core OCF
      resources (oic/res, oic/d, oic/con, security resources, etc.),
      but share a single oic/p resource corresponding to the underlying
      platform. Virtual servers would each have to be independently
      onboarded and provisioned in the security context in order
      for their resources to be accessed. Application resources
      are instantiated and bound to a specific logical device
      in the application, and resource handlers are made aware of
      their hosting device. This design is usually employed in
      a bridging scenario with OCF.
      The new multi_device_server/multi_device_client samples
      for Linux illustrate these concepts in action.
      Logical devices are defined using the oc_add_device() API
      and are identified by their zero based index in the order
      of oc_add_device() calls.
      Internal APIs now take the device index as the parameter.
      The interfaces to initialize and teardown
      connectivity also take device index as a parameter. The
      expectation is that implementations that wish to support
      multiple logical devices would allocate the required
      set of resources to hold multiple sets of handles, port
      numbers, addresses etc., one set for each logical device.
      A new interface to obtain the set of endpoints hosting
      a logical device must be realized in connectivity
      implementations, and is invoked in the discovery resource
      handler to populate the "eps" parameter.
      The Linux IP adapter incorporates full support for
      defining multiple logical devices by implementing the new
      interfaces, where each logical device maintains
      secured/unsecured ports over IPv6, and optionally over
      IPv4. The IP adapters for constrained OSes have been updated
      to return the list of endpoints, but continue to handle
      only a single logical device, as would be expected for
      constrained platforms.
      The build with security is NOT functional at the moment
      and has yet to be updated for OCF 1.0 security.
      However, the above changes were successfully tested for
      interoperability with IoTivity 1.3 (master) using the
      OCF 1.0 scheme and by running the simpleclient/simpleserver
      Additional notes:
      -Clients are now upon successful discovery handed a
      linked list of oc_endpoint_t structures that they may use to
      reach a server. This eliminates the oc_server_handle_t
      structure and all client APIs instead accept an oc_endpoin_t
      handle. These oc_endpoint_t structures are allocated from
      a pool, and the oc_free_server_endpoints() API may be used
      to free all server endpoints back to the poool when the client
      has no more interest to contact the server.
      -The handler for collections has been updated to include the
      “eps” property containing the list of endpoints to reach
      a referenced resource in a link.
      -The oic/d handler now returns the pid property containing
      a UUID.
      -The default OC_MAX_APP_DATA_SIZE for dynamic builds has been
      raised to 8192 bytes.
      -oc_connectivity_init() for each logical device is invoked
      through every oc_add_device() call.
      -Elimination of duplicate requests now happens by checking
      both the message id and logical device index.
      -Interfaces into the security implementation have been updated
      to mesh with the above changes, but the implementation itself
      is NOT currently functional.
      Change-Id: Iccf9e174b7d41d81eba89c010b8dbef9b090fc4e
      Signed-off-by: Kishen Maloor's avatarKishen Maloor <kishen.maloor@intel.com>
      Reviewed-on: https://gerrit.iotivity.org/gerrit/21607
  17. 20 Mar, 2017 1 commit
    • Kishen Maloor's avatar
      Add optional support for dynamic memory allocation · 4e36b13b
      Kishen Maloor authored
      * This feature allows IoTivity-Constrained to dynamically
        allocate memory from the heap on rich environments that
        provide a full C library and an allocator (Linux, Windows,
        iOS, etc.)
      * When enabled, the core framework internally invokes functions
        from the C standard library (malloc(), free(), etc.) while
        ignoring all constraints that were set in config.h.
      * This is an optional feature, and is enabled by setting
        #define OC_DYNAMIC_ALLOCATION in config.h. In addition,
        port/linux/Makefile now takes a new command-line option
        DYNAMIC=1 to include it.
        When OC_DYNAMIC_ALLOCATION is not set, the resulting build
        statically allocates all memory under the set constraints,
        as before.
      * This feature is completely transparent to both
        IoTivity-Constrained applications and port implementations.
        However, the application now has the added ability to set
        two parameters via new APIs at runtime: prescriptive
        MTU size, and maximum application data size.
        The MTU size is used to compute a maximum supported block
        size (16 - 1024 bytes), and the application data size is
        used to allocate internal buffers of that size to hold the
        entire application payload for block-wise transfers, separate
        responses and resource observations.
      * Modified server_block_linux and client_block_linux to
        demonstrate the use of these APIs: oc_set_mtu_size()
        and oc_set_max_app_data_size().
      * Cleaned up some parts of the internal flow to fix up
        previously hidden issues (when all memory was statically
      Change-Id: I50fba434ea2073371b27c260569ed147d22e2804
      Signed-off-by: Kishen Maloor's avatarKishen Maloor <kishen.maloor@intel.com>
      Reviewed-on: https://gerrit.iotivity.org/gerrit/17877Reviewed-by: default avatarFlavio Ceolin <flavio.ceolin@intel.com>
      Tested-by: default avatarFlavio Ceolin <flavio.ceolin@intel.com>
  18. 13 Mar, 2017 1 commit
    • Kishen Maloor's avatar
      Add build flag OC_BLOCK_WISE for block-wise-transfers · 52db01dc
      Kishen Maloor authored
      For constrained builds, config.h simply sets OC_BLOCK_WISE_SET_MTU
      at build-time to serve multiple functions; to include the block-wise
      transfers feature, for prescribing an MTU size upper-bound, and to
      automatically pre-allocate the required amount of memory for proper
      For builds on systems that support dynamic memory allocation, MTU
      size could be made configurable by an application at runtime.
      However, while building such an application or the iotivity-constrained
      libraries, we could (or not) set OC_BLOCK_WISE to include (or exclude)
      the block-wise transfers feature.
      Change-Id: Ifa5f164bc0ff128ca29fe3f54ff8aa975daf2d04
      Signed-off-by: Kishen Maloor's avatarKishen Maloor <kishen.maloor@intel.com>
      Reviewed-on: https://gerrit.iotivity.org/gerrit/17875
  19. 17 Feb, 2017 1 commit
  20. 27 Jan, 2017 1 commit
    • Kishen Maloor's avatar
      Update the connectivity interface · 093da610
      Kishen Maloor authored
      * Added new transport flag for IPV4 (and renamed IP to IPV6).
      * Renamed transport flag MULTICAST to DISCOVERY.
      * Removed transport flag IPSP (since it would simply talk through an IP
      * Renamed oc_send_multicast_message() to oc_send_discovery_request().
        This is more general and aligned to its purpose.
      * Updated all connectivity implementations and other impacted modules.
      Change-Id: Ic5c659bf5e0aeb27327a6bf44203de386d388928
      Signed-off-by: Kishen Maloor's avatarKishen Maloor <kishen.maloor@intel.com>
      Reviewed-on: https://gerrit.iotivity.org/gerrit/16849
  21. 26 Jan, 2017 2 commits
  22. 19 Jan, 2017 1 commit
    • Kishen Maloor's avatar
      Refinements to the block-wise transfer logic · 91be096e
      Kishen Maloor authored
      * Ensure that block-wise request/response buffers get freed in
        case of failure to handle the request (one that results in a
        4.xx error response).
      * Cleanly handle the creation and destruction of uri_query in request
      * Make servers respond to block1/block2 requests with a NON/ACK based
        on the request message type.
      * Set content-format for all block2 responses. (This was caught by
        the OCF conformance test tool).
      * Refactor routines that handle resource observations to clear up
        block-wise response buffers while clearing the observe handle,
        sending the first block of block-wise notifications in a CON message,
        and setting the content type (was previously missing).
      * Increase OC_PDU_SIZE to over 2 * OC_BLOCK_SIZE. This was necessary as
        encrypted messages over DTLS would exceed OC_BLOCK_SIZE.
      Change-Id: I4f56876bd6442cc46e36e9e750a07f949b90c6f5
      Signed-off-by: Kishen Maloor's avatarKishen Maloor <kishen.maloor@intel.com>
      Reviewed-on: https://gerrit.iotivity.org/gerrit/16595
  23. 06 Jan, 2017 1 commit
    • Kishen Maloor's avatar
      Add implementation of RFC 7959 (block-wise transfers) · e1b89013
      Kishen Maloor authored
      This change was accompanied by a massive restructure and rewrite
      of the messaging protocol flows.
      * Implemented a comprehensive state machine for performing block-wise
        transfers in requests and responses with both block options in
        control and descriptive usages, block size negotiation, handling
        block-wise transfers of observe notifications and separate
        responses, handling many corner cases for fault tolerance
        and to accurately reflect the RFC.
      * Requests and responses are processed atomically on arrival of all
        blocks from the exchange. Applications need have no knowledge of an
        ongoing block-wise transfer as the framework handles all of the logic
      * Buffers are internally allocated to hold state and are freed on
        completion of the exchange or after EXCHANGE_LIFETIME.
      * The entire feature may be conditionally compiled in by setting
        OC_BLOCK_WISE_SET_MTU in the framework configuration. This asserts an
        MTU size limitation of the lower protocol layers, a maximum block size
        is appropriately computed and a block-wise transfer is automatically
        initiated if the request/response payload size exceeds this limit.
        Not setting OC_BLOCK_WISE_SET_MTU excludes the feature entirely
        (so lower code size) and resulting applications would be
        unable to handle block options (except they would reject requests
        containing them).
      * Despite the existence of parallel flows (with/without block-wise
        transfer), there is no code duplication; the implementation is
        distributed over the set of appropriate modules with the parallel
        paths clearly demarcated by #ifdefs.
      * Added client/server samples to exercise the block-wise transfer
        feature in both the request and response directions. Added the samples
        to .gitignore.
      * Added a new framework configuration parameter OC_MAX_PDU_BUFFER_SIZE
        which sets the size of preallocated buffers to be able to
        accommodate the complete request/response payload.
      * Defined a new macro OC_PDU_SIZE which will be the size of data buffers
        in the oc_message_t struct and will decide the maximum data size that may
        be sent to or received from the lower layers in the connectivity
      * Updated oc_rep to fail prematurely on encountering CborErrorUnexpectedEOF
        during a parse so as to signal the remote endpoint that it has received
        incomplete data with a 4.13 response.
      * Updated the Linux, Zephyr, Contiki and RIOT ports to adapt to the above
      Change-Id: Icb12aa468e683aed55ee410f3df6c91a6b6a8efd
      Signed-off-by: Kishen Maloor's avatarKishen Maloor <kishen.maloor@intel.com>
      Reviewed-on: https://gerrit.iotivity.org/gerrit/16211
  24. 06 Oct, 2016 1 commit
  25. 12 Sep, 2016 1 commit
  26. 12 Aug, 2016 3 commits
    • Flavio Ceolin's avatar
      Missing "void" in functions in headers · 16d129b1
      Flavio Ceolin authored
      Change-Id: I9cad76f8c6495cb5a2463be96ec9a05335476865
      Signed-off-by: default avatarFlavio Ceolin <flavio.ceolin@intel.com>
      Reviewed-by: default avatarOtavio Pontes <otavio.pontes@intel.com>
      Signed-off-by: default avatarThiago Macieira <thiago.macieira@intel.com>
      Reviewed-on: https://gerrit.iotivity.org/gerrit/10427
    • Kishen Maloor's avatar
      Feature updates and fixes · 1a59c6c5
      Kishen Maloor authored
      * Added a mechanism for injecting incoming messages over the wire
        into the framework on an event-driven basis. Messages are passed
        in via a simple API and queued up for processing, and it allows for
        passing in multiple messages to the extent that there are available
        buffers. As a result, there is no need for polling, and the framework's
        event loop may sleep until woken up for any processing.
        This work involved the addition of interfaces to the platform abstraction
        for defining a locking mechanism to use over the network event handler,
        and an interface for signaling tiny OCF's event loop to wake up for
        handling new work.
      * Updated the IP adapters for both Linux and Zephyr to adopt the above
        scheme. On Linux, the adapter defines a thread to wait indefinitely
        on sockets; On Zephyr, the adapter defines fibers for performing
        net_receive and wait indefinitely on each net_context for new data.
      * Added API for applications to pass in pointers to tiny OCF callbacks
        via a structure.
      * Updated client/server samples to include their own implementations of
        main(), and demonstrate how to initialize and run tiny OCF. The samples
        incorporate definitions for both Linux and Zephyr. In the Zephyr case, it
        includes the definition of the background task.
      * Fix to time out non-observe and non-confirmable requests after a certain
        period if in case it didn't receive a response, and free the client
        callback so it may be used for a subsequent request.
      * Updated handlers for doxm and pstat resources to align with recent
        security spec clarifications that have been adopted by IoTivity's
        provisioning tool.
      * Added few parameters to config.h.
      * Miscellaneous sylistic changes.
      Change-Id: I1330172624f020c829df324ab4348be73c892ad6
      Signed-off-by: Kishen Maloor's avatarKishen Maloor <kishen.maloor@intel.com>
      Signed-off-by: default avatarThiago Macieira <thiago.macieira@intel.com>
      Reviewed-on: https://gerrit.iotivity.org/gerrit/10361
    • Kishen Maloor's avatar
      Tiny OCF sources · 6188f12a
      Kishen Maloor authored
      Signed-off-by: default avatarThiago Macieira <thiago.macieira@intel.com>
      Signed-off-by: Kishen Maloor's avatarKishen Maloor <kishen.maloor@intel.com>
      Change-Id: I3cb7030f20704c47bc459678a5f84eceffffffff
      Reviewed-on: https://gerrit.iotivity.org/gerrit/10349