Changes between Version 11 and Version 12 of Internal/NewNodeAgent


Ignore:
Timestamp:
Jan 16, 2015, 10:43:10 PM (10 years ago)
Author:
ssugrim
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Internal/NewNodeAgent

    v11 v12  
    166166As 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).
    167167
    168 ---
     168----
    169169''' 12/24/2014 '''
    170170
    171171The 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.
     172
     173----
     174''' 1/16/2014 '''
     175
     176We've decided that the drivers will store config state. We've also said that there must be an explict call to connect. In the ethernet context connect means bring the interface up. In the wifi context it will mean something different. 
     177
     178To that end I've implemented a config method in the ethernet that stores what configs were pushed in. I've also overridden the setter for device name. The new devicename method checks if the kmod as loaded before allwoing name assignment. If the kmod is loaded and name assignment succeeds, the connected state is checked (via ifconfig) and recorded, as well as the hardware mac.
     179
     180When a call to configure is made the connection state is checked. If it is connected the configure call tries to apply the change immedately, if it is not connected the configure call merely updates the hash.
     181
     182When a call to connect is made, the config hash is checked for values and if any exist the approriate configure call is made. The set of possible props is stored in a frozen has along with a pointer to the function that will handle that prop. Configure it self takes 2 string arguments, the first is the "prop name" to be configured, and the second is a value string. e.g. ("ip","192.168.1.1."). If a prop name hit occurs in the hash, the mapped function is called and the value feed as an argument to that function.
     183
     184A similar design is going to be worked into the WIFI class.