Thiago, I am not sure if there is overriding guidance, but, I *think* that the representation standard is that MAXAGE is 60 seconds unless explicitly stated otherwise in the response. I think that general guidance would hold true here. Devices could (should?) set the MAXAGE to the minimum of the resource lifetimes, the DHCP lease and/or the remaining awake time to inform the client on how often to check. This, of course, is just a hint. A device could go offline at any time (power failure, out-of-range, etc.)
Pat > -----Original Message----- > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- > bounces at lists.iotivity.org] On Behalf Of Thiago Macieira > Sent: Friday, September 11, 2015 12:00 PM > To: iotivity-dev at lists.iotivity.org > Subject: Re: [dev] Dealing with IP address changes > > On Wednesday 09 September 2015 14:59:10 Agrawal, Sachin wrote: > > But, with DTLS security, we would have to find a mechanism to allow > > successful decryption of packets when sender changes its address. > > Or we figure out a way to announce that the address is changing. This is a lot > harder since now we must monitor the network interfaces for the address > attribute: when a temporary address becomes stale and what the new address > is. > That WILL require AF_NETLINK on Linux (bye-bye Android and Tizen...) and we'll > be very, very pressed for the same information on other OS. > > Not to mention that this is about IPv6. For IPv4, the address change can be > instantaneous, with no warning and no ability to send with the previous > address > once it happens. > > Third-party implementations of OIC will also be hard-pressed to implement the > same solution. > > Easy way out: ignore the problem and let the keepalive/timeout mechanism to > break the connection. OBSERVE replies (assuming they're CONfirmed), won't get > confirmed, so the sender stops sending; clients sending to an address and > receiving from another will ignore the reply, until they decide to drop the > address from the cache and restart from multicast discovery. > > That reminds me: what is the time-to-live of a multicast discovery? How long > should discovered resources be cached for? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev
