User Tools

Site Tools


proposal_for_cloud_interface_in_iotivity

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
proposal_for_cloud_interface_in_iotivity [2015/08/19 02:19]
MyeongGi Jeong [Contribution approach]
proposal_for_cloud_interface_in_iotivity [2017/01/03 01:46] (current)
Phil Coval [Cloud Interface in IoTivity]
Line 1: Line 1:
 =========== Cloud Interface in IoTivity =========== =========== Cloud Interface in IoTivity ===========
 This is a contribution proposal about cloud/​server interface of OIC devices. This is a contribution proposal about cloud/​server interface of OIC devices.
-Currently, IoTivity doesn'​t have the capability to interact with internet service provided by cloud.+Currently, IoTivity doesn'​t have the capability to interact with internet service provided by [[cloud]].
 So, this feature enriches the OIC device functionality and extends the coverage of OIC device interoprability. So, this feature enriches the OIC device functionality and extends the coverage of OIC device interoprability.
  
Line 11: Line 11:
 =====Scenario and sequences===== =====Scenario and sequences=====
 Initially, following two scenarios are considered. Initially, following two scenarios are considered.
- 
-{{:​Scenario-CoAP_over_TCP.png|}} 
  
 1. OIC device send event notification to the Cloud service. 1. OIC device send event notification to the Cloud service.
Line 32: Line 30:
      * Only message type transported when using CoAP over TCP is the Non-Confirmable message (NON).      * Only message type transported when using CoAP over TCP is the Non-Confirmable message (NON).
      * Message ID is meaningless and thus elided.  ​      * Message ID is meaningless and thus elided.  ​
 +     * This feature will be supported optional through build option set.
  
      * Use URI Scheme      * Use URI Scheme
Line 40: Line 39:
      * Support keep alive ( 2nd phase )      * Support keep alive ( 2nd phase )
      * Support auto-reconnection to recover abnormal disconnection ( 2nd phase )      * Support auto-reconnection to recover abnormal disconnection ( 2nd phase )
 +     * Support IPv6 ( 2nd phase )
  
  
Line 46: Line 46:
  
 {{:​sequence.png|}} {{:​sequence.png|}}
- 
  
 <Device control> <Device control>
Line 52: Line 51:
 {{:​sequence-devicecontrol.png|}} {{:​sequence-devicecontrol.png|}}
  
 +
 +<RI Interface>​
 +
 +{{:​sequence_ri.png|}}
  
 =====Contribution approach===== =====Contribution approach=====
-  * Cloud CI(Cloud Interface) server side +====Cloud CI(Cloud Interface) server side==== 
-     ​* Use Netty framework ( http://​netty.io ) +  * Use Netty framework ( http://​netty.io ) 
-     ​* Contribution ‘CoAP over TCP codec’ part only +  * Contribution ‘CoAP over TCP codec’ part only 
-     ​* User wants to enable cloud interface, he/she should setup the Netty framework.+  * User wants to enable cloud interface, he/she should setup the Netty framework.
  
-  * Device side +====Device side==== 
-    * Some enumerations represent TCP transport type will be added in RI layer( octypes.h ) +  * Some enumerations represent TCP transport type will be added in RI layer( octypes.h ) 
-      * OCTransportFlags::​OC_IP_USE_V4_TCP +  * OCTransportFlags::​OC_IP_USE_V4_TCP 
-      * OCConnectivityType::​CT_IP_USE_V4_TCP+  * OCConnectivityType::​CT_IP_USE_V4_TCP
  
-    ​* Some interface will be added in RI layer to get information from application,​ this should be required to connect and register device at cloud service +  ​* Some interface will be added in RI layer to get information from application,​ this should be required to connect and register device at cloud service ​(RegisterResourceToCloud(..),​ UnregisterResourceToClould(..)) 
-      * Connect +      * IP, Port parameter for Connection/​Disconnection 
-        * Even though the OIC device is resource server, the device should try to connect the Cloud service. Because the information of Cloud server depends on the application. the information of Cloud service should be passed from application. So, IoTivity should provide the interface for this. +        * Even though the OIC device is resource server, the device should try to connect the Cloud service. Because the information of Cloud server depends on the application. the information of Cloud service should be passed from application. ​ 
-      * Disconnect +        * So, IoTivity should provide the interface ​through parameter of RegisterResourceToCloud(..),​ UnregisterResourceToClould(..) Method in OCPlatform. 
-        * To terminate ​the TCP connection, the new interface ​will be provided+      * payload, Payload Size parameter ​for Register 
-      * Register +        * To send device information. its resource information is depends on Resource Directory of RD Server.  
-        * To send device ​information( including device IDtyperesource uriUIDaccess tokenapplication itetc ), new interface should be required.+        * since Resource Data Type will be required by RD server. ​this Resource data should be included in Payload parameter of new RegisterResource(...) by Application. 
 +        * Again, since OCResource of RI can't be covered for resource data of RD server, it should be provided from Application as new RegisterResource(...,​ payload, payloadSize) directly. 
 + 
 +    * Some interface will be not added in CA layer
 +      * new RegisterResource / UnregisterResource API of RI will be called SendRequest of CA finally. 
 +        * if there was no TCP session with Cloud server, TCP adapter will be checked and then CA will try to connect with CI server before send request to register resource.  
 +        * For the register, CA can use CoAP advertising flow. If the transport type is TCP, CA sends registration information to Cloud server, else CA sends multicast message according to the selected transport types. 
 +        * when UnregisterResource(..) is called from Base API, sendRequest of CA will be called in first and then TCP disconnect will be tried
 +      * Some data structures will be modified in CA layer 
 +        * CATransportAdapter_t::​CA_TCP_ADAPTER ( 1 << 4 ) will be added 
 +        * To store the CI server ​information, ​tcpsockets structure will be added. 
 +        * To store the CI server listu_arraylist_t will be added. 
 +      * This logic will be implemented in other adapter.(catcpadapter - ci(cloud interface)) 
 + 
 + 
 +  typedef enum { 
 +      CA_DEFAULT_ADAPTER ​        = 0, 
 +      CA_ADAPTER_IP ​             = (1 << 0), 
 +      CA_ADAPTER_GATT_BTLE ​      = (1 << 1), 
 +      CA_ADAPTER_RFCOMM_BTEDR ​   = (1 << 2), 
 +  #ifdef RA_ADAPTER 
 +      CA_ADAPTER_REMOTE_ACCESS ​  = (1 << 3), 
 +  #endif 
 +      CA_ADAPTER_TCP ​            = (1 << 4), // CoAP over TCP 
 +      CA_ALL_ADAPTERS ​           = 0xffffffff 
 +  } CATransportAdapter_t;​
  
-    * Some interface will be added in CA layer. 
-      * CACreateTCPConnection( const CATCPServerInfo* serverinfo ) / CADestroyTCPConnection( const CATCPServerInfo* serverinfo ) 
-        * To create and terminate dedicated TCP session with Cloud service, new interface will be added. 
-      * For the register, CA can use CoAP advertising flow. If the transport type is TCP, CA sends registration information to Cloud server, else CA sends multicast message according to the selected transport types. 
-    * Some data structures will be modified in CA layer 
-      * CATransportFlags_t::​CA_IPV4_TCP ( 1 << 8 ) will be added 
-      * To store the CI server information,​ CATCPServerInfo_t will be added. 
-      * To store the CI server list, CATCPServerList_t will be added. 
-       ​{{::​ca_changes.png?​800|}} 
-        
     * To handle different header for TCP, we are going to change libcoap interface.     * To handle different header for TCP, we are going to change libcoap interface.
       * Add parameter to all APIs using coap_hdr_t to decide which header should be constructed       * Add parameter to all APIs using coap_hdr_t to decide which header should be constructed
-        * typedef enum { udp = 0, tcp = 1 } coap_hdr_type;+        * typedef enum { coap_udp ​= 0, coap_tcp ​= 1 } coap_transport_type;
       * coap_hdr_t will be changed.       * coap_hdr_t will be changed.
-{{::coap_hdr_t.png?800|}}+      * As coap header is changed, some API in libcoap will be also changed as per transport type. 
 + 
 +====KeepAlive==== 
 +In order to ensure that the connection between an OIC Devices, when using CoAP over TCP,  
 +OIC Device should send application layer KeepAlive messages. (Please refer the Core Specification Project B documents ( 12.6. CoAP serialization over TCP ))  
 + 
 +  * The reason to support application layer KeepAlive are as follows : 
 +    * TCP KeepAlive only guarantees that a connection is alive at the network layer, but not at the application layer. 
 +    * Interval of TCP KeepAlive is configurable only using kernel parameters and is OS dependent. ( eg. 2 hours by default in Linux ) 
 + 
 +  * Detailed Features{{ :ex1_keepalive_for_coap_over_tcp.png?300|}} 
 +    * Use Fixed Ping resource 
 +      * URI: /oic/ping, Type ID: oic.wk.ping,​ Interfaces: oic.if.rw 
 +    * Fixed Interval Time 
 +      * Start from 2 minutes and increases in multiples of 2 up to  64 minutes. 
 +    * Disconnect logic 
 +      * OIC Client does not receive the response with 1 minutes. 
 +      * OIC Server does not receive a PUT request within interval time. 
 +      *  
 +  * Base Layer Changes 
 +    * Support a resource of type oic.wk.ping 
 +    * Maintain the OIC Device Information connected by CoAP over TCP to send KeepAlive message. 
 +      * New API be added in RI & CA Layer (to pass the change of connection state from CA to RI) 
 +{{ :​ex2_keepalive_for_coap_over_tcp.png |}} 
 + 
 +=====References===== 
 +  * What is Netty Framework ? 
 +    * Netty is an asynchronous event-driven application/​framework making it easy for users to write network socket programs. Originally It was developed by JBoss, and now being developed and maintained by the Netty Project Community. It supports HTTP, websocket, SSL/TLS and so on. The latest version is 4.0.30 final(stable) and 5.0.0 Alpah2(development) when this document is written. 
 +    * Official home page : http://​netty.io/​ 
 +    * Maven repository : http://​mvnrepository.com/​artifact/​io.netty
  
 +  * How to build CoAP/TCP codec for Netty?
 +    * '​CoAP/​TCP codec for Netty' is a CoAP/TCP implementation for Netty based on "​draft-tschofenig-core-coap-tcp-tls-04.txt"​. This adds the functionality for encoding/​decoding CoAP over TCP messages to Netty framwork. The repository has complete source codes for Netty framework including the CoAP/TCP codec for Netty.
 +      * 1. pull source from the repository
 +      * 2. maven clean and build with pom.xml
 +      * 3. get library ​ named "​netty-coaptcp-codec-0.0.1-SNAPSHOT.jar"​ in target directory
 +      * {{:​example_of_programming_coapovertcp_codec_server.docx|}}
proposal_for_cloud_interface_in_iotivity.1439950748.txt.gz · Last modified: 2015/08/19 02:19 by MyeongGi Jeong