Nice to hear converging. Regarding persistent storage, I didn?t mentioned we should use the storage only for security purpose, but just want to explain currently security module manages the storage by itself for security exclusive purpose. We cannot depend on or reuse it for itself. Of course, IoTivity resource model layer can manage it internally away from security module.
Ashok, could you give your opinion for this implementation considering implementation effort also from the maintainer perspective? BR, Uze Choi From: cftg at openconnectivity.org [mailto:[email protected]] On Behalf Of Light, John J Sent: Tuesday, May 03, 2016 3:28 AM To: uzchoi at samsung.com; ashok.channa at samsung.com; 'Dave Thaler'; Keane, Erich; Jacob_Gladish at cable.comcast.com; Macieira, Thiago; cftg at openconnectivity.org Cc: iotivity-dev at lists.iotivity.org Subject: RE: [cftg] RE: [dev] [cftg] Re: [cftg] Re: Re: [cftg] Re: Re: [cftg] RE: OCF IANA Port Number Assignment It seems we are starting to converge on an answer. I will respond to your two points. First, persistent storage. I don?t understand why persistent storage is exclusively for security. It is a historical artifact that security has been developed separately from the rest of IoTivity, worked on by a separate team. But I don?t know any reason for exclusivity in the storage. The existence of security assures us that persistent storage is available, and we only need two bytes to store the current port number. A further storage question is where IoTivity gets the Device ID (GUID) that is unique for each server. I understand that this must also be persistent for everything to work. If it comes from the application, it is only available because there is persistent storage available to the application. Second, random port assignment. (These ports are also called Ephemeral ports.) Each OS allocates these port according to rules that make sure no collisions occur. For example, Linux allocates ephemeral ports in the range 32768 ? 61000, so there is no chance that port 80 will be assigned. (Thank you Dave Thaler for commenting on this.) Please note that the port allocation rules have been working for decades. The fixed assignments are based on the assumption that the minimum number of ports are defined for each usage. Typically, IANA assigned ports are used for rendezvous and startup, and very few instances of multiple assignments will be found. This is why HTTP scales across vast numbers of browsers and servers using only one assigned port number. The IANA port assignments are a fixed resource that has to last forever. We should respect that by following the rules. John Light Intel OTC OCF development From: ???(Uze Choi) [mailto:[email protected]] Sent: Sunday, May 01, 2016 7:45 PM To: Light, John J <john.j.light at intel.com>; ashok.channa at samsung.com; 'Dave Thaler' <dthaler at microsoft.com>; Keane, Erich <erich.keane at intel.com>; Jacob_Gladish at cable.comcast.com; Macieira, Thiago <thiago.macieira at intel.com>; cftg at openconnectivity.org Cc: iotivity-dev at lists.iotivity.org Subject: RE: [cftg] RE: [dev] [cftg] Re: [cftg] Re: Re: [cftg] Re: Re: [cftg] RE: OCF IANA Port Number Assignment Thank you for your detail coding level design. However I?d like to claim two points. One is persistence storage is for security exclusively for their purpose. Other purpose beyond security is not eligible. Furthermore, it is not accessible in case of non-secure build, You implementation requires additional persistence storage on somewhere which Ashok claims architecture concept change. The other point is that initially random port assignment policy is also problematic. IoTivity happen to assign the 80 port for example, then what happen? Nomad should move out when original owner comes. BR, Uze Choi -------------- next part -------------- HTML ?????? ??????????????... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160503/b8c5bb76/attachment.html>
