"I wonder previous IoTivity stack support the port number setting by API manually, but suddenly disappeared."
I don't believe the port number in OCInit was ever connected to the network adapter, certainly not after the addition of the Connectivity Abstraction. I noticed when I first saw the code that the OCInit arguments were not connected to anything. So the word "suddenly" may not be accurate. John Light -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Thiago Macieira Sent: Monday, January 25, 2016 9:05 AM To: ???(Uze Choi) Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Need API to set static "sid" and "port number". 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 _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
