On Friday 22 January 2016 16:33:48 ??? wrote: > Hi Thiago, > > Theoretically everything could be changed. > However, we can expect that IP can be maintained in the home from most of > cases.
Device addresses are regular properties and subject to max-age, which the server should send upon discovery. You must design software that deals with that property (the address) expiring, which means your software must re- discover in a periodic basis. > The whole process execution of ?Discovery some list of devices and > identify one of them? need to be avoid as much as possible once it has > been done. Right. It can be cached for max-age of the property. The device knows how long its addresses are valid for and should include that information in the discovery reply. If it doesn't, we need a suitable default. I'd say one hour, assuming the device is still responding. If the device does not respond to unicast queries to a cached address within a suitable timeout, the client needs to re-do discovery. The timeout for retransmitting unicast is probably specified in CoAP already. > So that port num. random generation policy does not fit this requirement I > think. Even though Dynamic port num. increment is good feature. That's not under our control. The port number is assigned by the OS. If you want a different assignment policy, please change your OS. Besides, a running IoTivity stack will not change the port number. It will never close the socket. So if the port number changed, it's because the application shut down, most likely because the device rebooted. In that case, a rediscovery is the correct thing to do, as any state was probably lost too. > Additionally, providing the way to fix device id is essential also for the > same reason above. This is a separate issue. As already explained, the di is supposed to remain constant. It is retrieved by the stack via a callback to the secure storage API. The application must implement that callback. If that is not working, then it might be a bug. > Even though we deliver the OIC secure mode product, we should test it from > non-secure mode. No product will operate in non-secure mode, therefore testing non-secure mode is not necessary. Testing in secure mode, however, is required. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
