Hi Zoltan, You are right in your general observation
For #2 - (based on current spec) it would have to be based on what properties that the resource exposes - if the resource exposes a couple of additional properties like "data sample size" and "message rate" then the query part of the request can be used to specify the bounds on these properties. the reason that "Observe" is defined a "request that is cached against the resource and then *evaluated* against that resource whenever the state of that resource changes" is to allow for the request to be evaluated and only if the query parameters evaluations are met in such a way that a response is sent - no response is sent if the evaluation fails. NOTE: this OIC statement on Observe is different from CoAP which has no evaluation requirement (going from memory based on my last reading of CoAP Observe. (So #1 below is the mode of operation only if the query part of the request only has the observe flag) For #3 - this would require a "negotiation" process (which is a work item that I am working on). The reason is that there is an "offer" with the required QoS (i.e. 1KHz sampling with 1 message per second rate) and there is a "counter offer" from the server indicating what it can provide this client (i.e. 500 sampling rate with 1msg/sec); note this does not have to be fixed but could depend on the processing and resource load of the server at the time the observe request is made). The client then has to accept or reject that counter offer and then the two parties should agree on the final values (which *may* take a few more rounds). (This general negotiation flow is for many other items and has more considerations than the simple outline here but is to address situations like in the observe case #3). We also have to clearly define QoS - so there is more work to be done here. Thanks for raising these cases ... Ravi -----Original Message----- From: cftg at openinterconnect.org [mailto:[email protected]] On Behalf Of Kis, Zoltan Sent: Wednesday, December 9, 2015 7:03 AM To: cftg at openinterconnect.org Cc: iotivity-dev at lists.iotivity.org Subject: [cftg] Observe indication with parameters Hello, I would like to ask if OIC has a solution for the following flow control related use cases: 1. client1 wants to observe sensor1, and wants 1 update message sent per second with 1 reading sample. 2. client2 wants to observe sensor1, and wants the data sampled with 100 Hz, but max 1 message per 10 seconds (each update containing 100*10 samples). 3. client3 wants to observe sensor1, and wants data sampled with 1 KHz, with 1 message per second. The server1 response is an error telling "I cannot handle that, but I could handle max 500 Hz sampling rate with 1 message per second", or "I could handle max 1000 Hz sampling rate with 1 message in 2 seconds". Then client3 can decide if it wants to observe still, and modify the observe parameters. So far OIC seems to support for the first use case, but not 2 and 3. My reasoning: in the client I want to avoid a flood of unneeded updates, and in the sensor implementation I want to use the observe parameters to optimize power, networking etc resources. It would be nice to have an optional parameter to observe indication, telling a desired sampling rate, and a desired update rate (or the number of samples per update message). The default value for these could be 1 sample for each update, with the update message sent at the server discretion (whenever the value changes, or as frequently the server can send it). Best regards, Zoltan
