On Tuesday 24 March 2015 17:52:37 ??? wrote: > Hi Vijay/Thiago, Hi uze
> > If there is very smart logic to decide the appropriate adaptor, it could be > best. > However, framework cannot know which connectivity adaptor is appropriate > for anonymous application. I think in most cases we can make the appropriate decision automatically. See below. > Let's assume there are two devices connected thru BT and WiFi together. > Then, Framework internally can aware that there are BT, WiFi available > adaptors. > One application is Video streaming App. requiring the large bandwidth. > The other is notification messaging App requiring small and not-frequent > data. > How the Framework could be smart in this case? First of all, the framework is aware of the type of data being transmitted. We've discussed having a feature for A/V (lossy) transmission and for reliable streaming, so the framework knows it should switch to the higher bandwidth channel if possible. > Anyway If we definitely need the smart selection logic I would like to make > as follows. > 1) Framework has the priority for adaptor and If Application does not > specify, then follow the framework policy else follow the specified one. > 2) Framework monitors data transmission rate and designate the appropriate > adaptor. > But these trials does not look deterministic. I think we should do it like this: 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. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
