On Monday 25 January 2016 17:37:58 ??? wrote: > >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. Understood, that makes sense. > >> 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. We don't currently send that information, but we could. There's an on-going discussion inside SWG on how to properly transmit RD replies for multiple transport types. I believe I have posted part of my proposal to iotivity-dev too, when we talked about MAC addresses in URLs. Also note that the proper way of discovering this information on Linux is AF_NETLINK and both Tizen and Android are known to block this communication, probably due to an overly-strict SELinux rule. For Android, there's not much we can do. For Tizen, Samsung can probably adjust the security rules to permit the information. > >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. Apparently it wasn't intentional. > >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. Correct, but why? > 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. Please explain this. > >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. That I agree with. For performance reasons, the application in the device that rebooted could choose to resume operations on the port number that it used before the reboot. That would be like DHCP giving the same IP address that it had leased before. So I agree on having this API. It should be clear that it is a port *hint*, not a setting. The stack may fail to set that port number and that is not a problem. This also allows us to introduce the change during testing, to ensure that other devices do correctly re-discover. We should also advise the Plugfests to have a DHCP server that forces an IP address change after reboot. > >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. Fair enough, but non-secure mode is not a priority. > >> 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. Agreed, but as I said, not a priority because that does not match "real world conditions". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
