Skip to content

GitLab

I
iotivity-lite
Switch branch/tag
  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
  3. 15 May, 2018 1 commit
  5. 09 May, 2018 1 commit
  7. 08 May, 2018 1 commit
  9. 02 May, 2018 1 commit
  11. 17 Apr, 2018 1 commit
  13. 21 Feb, 2018 1 commit
  15. 15 Feb, 2018 1 commit
  17. 12 Oct, 2017 1 commit
  19. 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
  21. 27 Jun, 2017 1 commit
  23. 26 Jun, 2017 1 commit
  25. 24 Feb, 2017 1 commit
  27. 19 Feb, 2017 1 commit
  29. 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
  31. 18 Nov, 2016 1 commit
  33. 06 Oct, 2016 1 commit
  35. 29 Aug, 2016 1 commit
  37. 12 Aug, 2016 4 commits