Changes between Version 33 and Version 34 of Internal/OpenFlow/Controllers/MultiCtl

Timestamp:

Nov 16, 2012, 7:42:49 PM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/Controllers/MultiCtl

@@ -319 +319 @@
 For starters, the most basic structure would be a diverting module(work on one at a time, the default dispatcher behavior)  
 
-==== (11/8) ====
+[[BR]]      
+End of week8 :[#iv Back to Logs.]
+==== (11/8) ==== #w9
 The current state of the implementation is as follows:
  * central configuration file for the advertisements sent by the controller 
@@ -326 +328 @@
 
 Vendor message contents may be classified into initialization messages and service messages. The former are messages exchanged during an initial handshake between controllers, and the latter are messages used during normal operation e.g. for event messaging and returning processed results. In the interest of time, the controller-specific event contexts will probably be used for this purpose, as it can be used to directly manipulate the behavior of various modules. In the ideal case, a more general messaging format should work. 
+
+==== (11/15) ====
+More work on integrating the connection registration system for the remote dispatcher module:
+ * The dispatch queue holds all registered connections, sorted by event category, and then events. This allows for lookup using the event category fired by the controller, so we don't need to do extra work to begin pulling up a list of potential event recipients. 
+ * The dispatch queue is manipulated by the remote dispatch module, but is globally accessible through the controller class.
+ * The client-side connections may not always connect to the remote controller in one shot - therefore we add a crude wait-and-retry mechanism to the client handler. 
+ * The client connections are dispatched from the remote dispatch module. This prevents some timing issues by guaranteeing that the dispatch module has started up before clients attempt to register with it.  
+
+[[BR]]      
+End of week9 :[#iv Back to Logs.]
+==== (11/16) ==== #w10
+The framework is probably developed to the point where it is good to test multiple instances against each other. There are several ways to do this, but, when working on a single machine, we need to have each instance read in a separate configuration file. A preliminary test setup involves a directory of configuration files, and a script to launch controller instances using the appropriate configuration files.   
+
 ----
 [#home Home.]