关于floodLight监听器

Flow Cache（API only）
Flow Cache（API only）
考虑到在网络中需要处理某个范围内不同的事件，就定义了流缓存API，哪些事件需要处理、怎么处理取决于基于flo
odlight的SDN程序，例如对交换机/链路故障中流的处理是大多数应用程序都需要的。
floodlight定义了流缓存API和一系列骨架方法，应用程序开发人员可以使用这个通用框架针对他们应用的需求来实现
解决方案
我们正在努力整理出该API的书面记录，稍后就会发布到Floodlight网站上，同时你可以在流缓存源码中找到调用API
的简洁说明。
交换机/链路关闭事件的例子：
为了对流缓存的目的做一个宽泛的说明，我们跟随交换机/链路关闭事件处理的过程来看看各个模块的调用：
①当LinkDiscoveryManager发现一个线路或者端口关闭时，TopologyManager中的“NewInstanceWorker”线程将会处理这
个事件，在这个线程的结尾会调用informListeners，informListeners是一个留在这个事件中的钩子，以便让所有对此事
件刚兴趣的模块处理该事件。
②这是你的模块就会启动，这个模块必须实现ITopologyListener接口的topologyChanged方法，并且通过TopologyMana
ger.addListener方法将这个模块添加到监听者列表中。
③在你的模块中，可以通过Topology.getLastLinkUpdates方法获取以前所有拓扑的变化，并且可以通过排序找出所需
要的事件，可以在相邻交换机中链路的关闭中找出故障交换机，因此你需要要找出ILinkDiscover.updateOperation.LIN
K_REMOVED事件（每个相关的交换机都有一个事件），根据找到的条目你就可以得到相关的交换机端口。
④下一步是所有受影响的交换机中和相关端口有关系的流，查询是一个OFStatisticsRequest消息，可以用过sw.sendStat
sQuery方法将此消息发送给交换机sw。
⑤查询发出去后不久你就会收到一个响应，为了能够接受这个openflow数据包的响应，你的模块就要实现IOFMessage
Listener接口，并且处理OFType.STATS_REPLY消息。获取到响应后你就可以看到里边所有的流，现在你就可以决定
是否创建一个flowmods的删除消息清理到那些流。

/*

这里不用手动调用，listner的一个XXXchange方法？

floodlightProvider.addOFMessageListener(OFType.PACKET_IN, this); this就是实现了监听器接口的类的对象。

也就是添加监听器告诉给了floodlightProvider,通过初始化时context得到，floodlightProvider = context.getServiceImpl(IFloodlightProviderService.class);（例见VirtualNetworkFilter一个控制器应用）

而上边，实现了ITopologyListner接口，就必须通过TopologyManager.addListener方法将这个模块添加到监听者列表中。

等价于floodlightProvider可以加OfMessageListener,OFSwitchListener,和HAListener，而TopologyManager可以加TopologyListener.

TopologyManager 实现了ITopologyService等接口，而floodlightProvider是实现了IFloodlightProviderService的一个对象，FloodlightProvider和TopologyService都是控制器模块

*/

看起来问题已经解决了，但是我们还没有使用流缓存以及相关的服务接口。
流缓存的理念是让控制器持有所有有效流的记录。当事件被一个控制器的不同模块监听或者随时查询交换机时，流缓
存就会更新，这就让不同模块对流的更新和检索整合到了一个地方。
流缓存的数据结构留给实现者决定，在API中已经展示了查询和响应的格式（对于流缓存的格式），也可以为每一个
查询指定自己的处理器。
流协商（reconcile）类用来清理流缓存和交换机中的流，你可以使用多个模块监听不同的事件，它们都要实现IFlowRe
concileListener接口和reconcileFlows方法。该方法可以立即产生结果，也可以通过OFMatchReconcile对象把事件传递给
其它模块，同时还定义了一些接口用于跟踪正在等待的查询。