1. 15 Jun, 2018 1 commit
    • Jaehyun Cho's avatar
      Make st regarding logic to library. · 72abe3c1
      Jaehyun Cho authored
      To st_things modules use commonly, it need to
      make that library. Make st_framework module in service
      layer, and move st_app modules to there.
      
      To make prebuilt library for st-app-fw, use make_prebuilt.py
      script in tools folder. thil will copy dependency header in
      prebuilt folder and copy library about st-app-fw(libst-app-framwork.a)
      Detailed usage can check in make_prebuilt.py script file.
      
      Please Add build option ST_APP_FW to build st-app-fw library.
      
      -------------------------------
      Test Case
        st_app (out of box)
           Create Soft-AP  : OK
           Provisioning : OK
           Controlled by ST android app :OK
        st_app (setup is done)  -  OK
        st_app (with reset)  - OK
      
      Change-Id: Ie44b7053a69afe9ad230ecde1655f252bdd45ae7
      Signed-off-by: default avatarJaehyun Cho <jaehyun3.cho@samsung.com>
      Reviewed-on: https://gerrit.iotivity.org/gerrit/25629Tested-by: default avatarIoTivity Jenkins <jenkins-daemon@iotivity.org>
      Reviewed-by: default avatarUze Choi <uzchoi@samsung.com>
      72abe3c1
  2. 15 May, 2018 1 commit
  3. 09 May, 2018 1 commit
  4. 08 May, 2018 1 commit
  5. 02 May, 2018 1 commit
  6. 17 Apr, 2018 1 commit
  7. 21 Feb, 2018 1 commit
  8. 15 Feb, 2018 1 commit
  9. 12 Oct, 2017 1 commit
  10. 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
      samples.
      
      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
      45d912ef
  11. 27 Jun, 2017 1 commit
  12. 26 Jun, 2017 1 commit
  13. 24 Feb, 2017 1 commit
  14. 19 Feb, 2017 1 commit
  15. 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
        internally.
      * 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
        implementation.
      * 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
        changes.
      
      Change-Id: Icb12aa468e683aed55ee410f3df6c91a6b6a8efd
      Signed-off-by: Kishen Maloor's avatarKishen Maloor <kishen.maloor@intel.com>
      Reviewed-on: https://gerrit.iotivity.org/gerrit/16211
      e1b89013
  16. 18 Nov, 2016 1 commit
  17. 06 Oct, 2016 1 commit
  18. 29 Aug, 2016 1 commit
  19. 12 Aug, 2016 4 commits