On 05/10/2012 03:05 AM, Gary Kotton wrote: >> 2. One model I was thinking of (which is kind of inline with the >> existing agent implementations), is where the agents are smart, and they >> know what to do in response to changes in the state of the logical >> Quantum resources. In such cases, the Quantum plugin need not have to >> keep track of sending a message to a particular agent. Instead, can we >> have broadcast messages from the plugin to all the agents? If the plugin >> has to unicast messages to specific agents, then it needs to maintain a >> lot more state/topology information which should not be mandated for >> this sole reason. > I too thought about this option. In a sense the above proposal is an > optimization of what you mention. This comes at the cost of complexity. > The broadcast option is nice when the number of agents is small. When > this is large, then for each network update there will be > NUMBER_OF_AGENT messages sent for each update. The advantage of what you > mention is that the code is self contained in Quantum. > > It may be better to start with the broadcast and then deal with the > optimizations afterwards.
Unicasting messages to the agents adds complexity, but is it prohibitively more complex? By using broadcast, you get rid of the polling, but sacrifice some of the scalability benefits you would otherwise get by adopting rpc. There are a whole lot more messages being sent and agents are having to handle a whole lot more messages than they really care about. -- Russell Bryant -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
