Hi Thiago, Thank for your answer and I put more detail explanation in-line.
BR, Uze Choi -----Original Message----- From: Thiago Macieira [mailto:[email protected]] Sent: Friday, January 22, 2016 5:02 PM To: ???(Uze Choi); iotivity-dev at lists.iotivity.org Subject: Re: [dev] Need API to set static "sid" and "port number". 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. > Every design has the re-discovery mechanism, however, I want to propose the way to minimize this action. >> 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. Unfortunately, we don't have the ttl information from the discovery due to the light-weight protocol concept. >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. > I wonder previous IoTivity stack support the port number setting by API manually, but suddenly disappeared. >Besides, a running IoTivity stack will not change the port number. It will >never close the socket. > I claim that if the application can store port name, it could be maintained. And we also have the another use case for the setting port for CoAP over TCP, which require port setting for each company server operation policy. >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. > Please give the decision to the developer whether application try to connect the existing ip/port or not for better performance. >> 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. > I requested this for non-secure mode also. >> 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. > The developer may want to make the application from the non-secure mode for the testing and so on, IoTivity cannot restrict how to develop. At least, this is required from our several development teams. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
