Hi Thiago, It would be good practice to document (email/wiki/jira/...) the arguments (use cases/assumptions) that lead to the decisions we make (expose interface/...) so one can verify the validity over time. So please consider sharing those use cases you refer to below that convince you. Does iotivity already have a preferred place for this? Thank you, Stephane.
-------- Original message -------- From: Thiago Macieira Date:25/03/2015 05:21 (GMT+01:00) To: iotivity-dev at lists.iotivity.org Subject: Re: [dev] IPv6 changes to IoTivity On Tuesday 24 March 2015 10:41:10 Thiago Macieira wrote: > The framework should allow the application to create either a whitelist or > a blacklist of adapters (not both) to operate on. This should allow > routers to disable the port connected to the Internet and thus reduce the > attack surface for hacking -- I'm assuming that remote access will be a > different API anyway. > > Though by default the blacklist is empty: all adapters are enabled. So, by > default, all multicast is sent on all channels. The framework matches > multiple replies from the same service so it knows which channels allow > communication with a given target service. > > By default, the framework chooses one specific channel for communication > with a given service from the list of channels it found during discovery. > We should make this priority list documented. I don't know whether it > should be modifiable, though. > > The list may be different depending on the type of communication: small- > payload, low-latency CRUDN may be done over a different channel from a high- > bandwidth transmission. > > The framework also needs to keep up-to-date the list of channels a service > is reachable under. If it periodically sends multicast, it will soon know > if a device or channel went away. We may want to expose that list, but I > still don't know for sure. Hi everyone I had a chat with Vijay and others today and I was convinced there are legitimate use-cases for letting the application developer choose which interface adapter to send unicasts on in order to contact a service that is reachable via multiple channels. So I agree with Uze's proposal: > > 1) Framework has the priority for adaptor and If Application does not > > specify, then follow the framework policy else follow the specified one. I don't think we need to do this part: > > 2) Framework monitors data transmission rate and designate the appropriate > > adaptor. I don't think we need to monitor transmission and loss rates. That's a job for the lower below OIC -- the reliable delivery. -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150325/1505e6a1/attachment.html>
