Changes between Version 10 and Version 11 of Internal/NewNodeAgent

Timestamp:

Dec 24, 2014, 11:31:19 PM (10 years ago)

Author:

ssugrim

Comment:

—

Internal/NewNodeAgent

@@ -160 +160 @@
 
 ----
-''' 12/15/2015 '''
+''' 12/15/2014 '''
 
 We ran into a race condition of sorts where commands may come in after the connect call was issued. We've decided that the "start_application" directive is the decision point where we've given all the parameters we expect to get. To this end in the node-agent maintains a parameter model of the connection to be made. As parameters come in the node agent updates these parameters from the default. When the "start_application" directive is received, the agent will initiate a connect command. At this point the applicationStarted flag will = true. Once this flag is set, any parameter changes will be applied immediately. Parameters must be split into two types. Those that can be applied immedately (like freq) and those that require a reconnect like mode ibss). Once the applicationStarted flag is set if a reconnect is required when a parameter is changed it is do immedately.
 
-As a side note the different mode connect methods should check if the device is already connected and if so do nothing (regardless of which mode it is connected in). 
+As a side note the different mode connect methods should check if the device is already connected and if so do nothing (regardless of which mode it is connected in).
+
+---
+''' 12/24/2014 '''
+
+The agent commands second argument is a object of type OmfPubSubMessage. The source of this class is located [http://www.orbit-lab.org/browser/omf/omf-common/ruby/omf-common/communicator/omfPubSubMessage.rb here]. The path method produces the output we'll be switching on. The configure command calls the respective device_driver's configure command and expects a hash output. In this configure command is where the connect state needs to be implemented and maintained.