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
