User Tools

Site Tools


the_re-discovery_problem

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
the_re-discovery_problem [2016/05/19 15:21]
John Light
the_re-discovery_problem [2016/05/19 15:29] (current)
John Light
Line 6: Line 6:
   * Currently, IoTivity discovery typically requires many (if not most) IoTivity servers to respond, given the small amount of information in the discovery packets on which to base a response.   * Currently, IoTivity discovery typically requires many (if not most) IoTivity servers to respond, given the small amount of information in the discovery packets on which to base a response.
   * As IoTivity becomes ubiquitous, two issues will become critical that may not be considered very important today: scaling and energy. We should start orienting IoTivity to support those issues now.   * As IoTivity becomes ubiquitous, two issues will become critical that may not be considered very important today: scaling and energy. We should start orienting IoTivity to support those issues now.
-  ​* The scaling issue is that IoTivity is intended to support large number of systems from a variety of companies, and each system may consist of multiple client, gateway and server applications. For example, a server node might have a dozen or more independent IoTivity server ​application ​sharing the same IP stack, and a network may support hundreds of different server applications in various groupings across thousands of server nodes. +    ​* The **scaling issue** is that IoTivity is intended to support large number of systems from a variety of companies, and each system may consist of multiple client, gateway and server applications. For example, a server node might have a dozen or more independent IoTivity server ​applications ​sharing the same IP stack, and a network may support hundreds of different server applications in various groupings across thousands of server nodes. 
-  * The energy issue only becomes apparent when we consider the intended scale of IoTivity. Over time, we expect IoTivity to be used in millions and possibly billions of devices. This means that any unnecessarily repetitive activity can potentially waste much energy. Making the problem worse is that much of that energy will be in devices depending on batteries or scavenged power, where energy usage can determine the lifetime or availability of IoTivity systems.+    * The **energy issue** only becomes apparent when we consider the intended scale of IoTivity. Over time, we expect IoTivity to be used in millions and possibly billions of devices. This means that any unnecessarily repetitive activity can potentially waste much energy. Making the problem worse is that much of that energy will be in devices depending on batteries or scavenged power, where energy usage can determine the lifetime or availability of IoTivity systems.
   * Networks can experience temporary disruptions. Such disruptions can interrupt or otherwise interfere with IoTivity systems. The disruptions can occur in both wired and wireless networks, and their cause can be natural (such as wireless interference) or as a result of technology issues such as re-configuring a network. Networks talking directly to IoTivity server nodes are more likely to experience disruptions. We can't eliminate disruptions.   * Networks can experience temporary disruptions. Such disruptions can interrupt or otherwise interfere with IoTivity systems. The disruptions can occur in both wired and wireless networks, and their cause can be natural (such as wireless interference) or as a result of technology issues such as re-configuring a network. Networks talking directly to IoTivity server nodes are more likely to experience disruptions. We can't eliminate disruptions.
-  * The consistency issue is that many IoTivity systems want to present predictable behavior as much as possible. For example, a sensor value coming from an IoTivity server node may be presented to a user or an application on a regular basis. For another example, an actuator on an IoTivity server node may want to be exercised on a regular basis. A disruption in network connectivity may interfere with the regular action in either case. Minimizing the apparent disruption in both cases may make an IoTivity-based system appear “better” to humans observing it.+  * The **consistency issue** is that many IoTivity systems want to present predictable behavior as much as possible. For example, a sensor value coming from an IoTivity server node may be presented to a user or an application on a regular basis. For another example, an actuator on an IoTivity server node may want to be exercised on a regular basis. A disruption in network connectivity may interfere with the regular action in either case. Minimizing the apparent disruption in both cases may make an IoTivity-based system appear “better” to humans observing it.
  
 The need for optimizing re-discovery comes from the **energy issue** and the **consistency issue**. ​ The **scaling issue** places constraints on the solution. The need for optimizing re-discovery comes from the **energy issue** and the **consistency issue**. ​ The **scaling issue** places constraints on the solution.
Line 17: Line 17:
   - Client A uses the IP address and port number of Server B to perform IoT functions using IoTivity protocol.   - Client A uses the IP address and port number of Server B to perform IoT functions using IoTivity protocol.
   - The power of Server B is cycled, causing it to restart. ​ The restart will likely result in Server B getting a new port number, and it may also get a new IP address. ​ Client A needs to know how to communicate with the new instance of Server B.   - The power of Server B is cycled, causing it to restart. ​ The restart will likely result in Server B getting a new port number, and it may also get a new IP address. ​ Client A needs to know how to communicate with the new instance of Server B.
-  - Client A will note that Server B fails to respond to requests or fails to make any more Observer reports. ​ After some indefinite time (likely determined by timeout processes), Client A determines that Server B is no longer ​connected.+  - Client A will note that Server B fails to respond to requests or fails to make any more Observer reports. ​ After some indefinite time (likely determined by timeout processes), Client A determines that Server B seems no longer ​available.
   - Client A performs IoTivity discovery and determines the connection information for the new instance of Server B.  System operation resumes.   - Client A performs IoTivity discovery and determines the connection information for the new instance of Server B.  System operation resumes.
  
the_re-discovery_problem.txt · Last modified: 2016/05/19 15:29 by John Light