Dear Murphy:
Thanks. Now I add some extra events and named it
as Fail_server_invoke.py like below:
from pox.core import core
import pox.openflow.libopenflow_01 as of
from pox.lib.revent.revent import EventMixin
log = core.getLogger()
class define_event(EventMixin):
_eventMixin_events = set([raise_fail])
class Fail_server_invoke(object):
def __init__(self, intervals):
self.connections = set()# Attribute
self.interval = intervals
define_event.addListeners(self) #Add Listener
log.debug(" --------------------------------- ")
log.debug(" Fail_server_invoke_class wait for raise_fail event ")
log.debug(" --------------------------------- ")
def _handle_raise_fail (self, event):
log.debug("Server failed")
But I got some problems when I use another component to add following lines
in launch function.
core.registerNew( Fail_server_invoke, interval)
define_event.raiseEvent(raise_fail("Generic"))
And I also import the module Fail_server_invoke like below:
from Fail_server_invoke import *
The error message is 'NameError: name 'raise_fail' is not defined', but I
already define 'raise_fail' in Fail_server_invoke.py
Thanks for helping.
Best Regards,
Sophia
2013/3/30 Murphy McCauley <[email protected]>
> On Mar 29, 2013, at 11:40 PM, chenli wrote:
>
> > 1. The meaning for registering
> > Is core.registerNew(Mycomponent) the function to register to core
> object, and we can use the methods in core which defined in
> /pox/pox/core.py ?
> >
> > If I register the Mycomponent to core, the other components can
> communicate with Mycomponent by core object?
>
> I think the answer here is yes. One of the purposes of the core object is
> to provide a rendezvous point for component instances. This allows a
> number of things, not all of which are really used extensively at this
> point:
> 1) It means you often just need to import core instead of a whole bunch of
> modules.
> 2) Multiple components that all implement the same interface can register
> under the same name and other components can find the active one.
> 3) It's not always clear where long-lived objects should be. One option
> is as a global variable of some module. core is a (possibly) more
> structured alternative which (among other things) hopefully encourages
> components to be capable of being instantiated more than once. (In
> practice, this is rarely true so far.)
>
> > 2. The code section for raising ConnectionUp event
> > And the second problem , I want to know where is the raiseEvent which
> raise ConnectionUp event happened. In other words, maybe it looks like
> core.openflow.raiseEvent(ConnectionUp).
>
>
> I'm not sure why it's helpful to know exactly where this event is raised,
> but it's in openflow.of_01 along with the rest of the stuff specific to
> communicating with OpenFlow 1.0 switches (not counting the stuff related to
> the OpenFlow protocol itself which is in libopenflow_01).
>
> It's slightly more complicated than just raising it on core.openflow.
> Connection objects are "owned" by an OpenFlowNexus. core.openflow is the
> default nexus, but there can be others. So the actual ConnectionUp event
> is raised on whichever nexus the Connection belongs to.
>
> -- Murphy
