Floodlight 处理交换机增加/移除过程

Floodlight 使用的是Netty架构，在Controller.java 入口函数中显示创建ServerBootstrap，设置套接字选项，ChannelPipeline，此时监听套接字就准备优点理来自SW的各种消息；这里最核心的就是 OpenflowPipelineFactory ，会增加各个业务相关的Handler，代码例如以下：

public ChannelPipeline
getPipeline() throws Exception {
[align=left] OFChannelState state = new OFChannelState();[/align]
[align=left] [/align]
[align=left] ChannelPipeline pipeline = Channels. pipeline();[/align]
[align=left] pipeline.addLast( "ofmessagedecoder", new OFMessageDecoder());[/align]
[align=left] pipeline.addLast( "ofmessageencoder", new OFMessageEncoder());[/align]
[align=left] pipeline.addLast( "idle", idleHandler );[/align]
[align=left] pipeline.addLast( "timeout", readTimeoutHandler );[/align]
[align=left] pipeline.addLast( "handshaketimeout",[/align]
new HandshakeTimeoutHandler(state, timer ,
15));
[align=left] if (pipelineExecutor != null)[/align]
[align=left] pipeline.addLast( "pipelineExecutor",[/align]
[align=left] new ExecutionHandler(pipelineExecutor ));[/align]
//OFChannelHandler
是核心
[align=left] pipeline.addLast( "handler", controller.getChannelHandler(state));[/align]
[align=left] return pipeline;[/align]
[align=left] }[/align]

[align=left]接下来的main loop就是处理交换机或者Controller角色变化等消息，这是我们关注的地方，代码例如以下：[/align]

[align=left] // main loop[/align]
[align=left] // 不断处理堵塞队列中SW的更新信息[/align]
while (true )
{
[align=left] try {[/align]
[align=left] IUpdate update = updates.take();[/align]
[align=left] update.dispatch();[/align]
} catch (InterruptedException
e) {
[align=left] return;[/align]
} catch (StorageException
e) {
log.error("Storage
exception in controller "
+ "updates loop; terminating
process", e);
[align=left] return;[/align]
} catch (Exception
e) {
log.error("Exception
in controller updates loop", e);
[align=left] }[/align]
[align=left] }[/align]

那么Controller中的BlockingQueue中的更新信息是在何时增加的呢？这里仅仅跟踪交换机增加的情况，非常easy想到当监听套接字收到一个来自OF SW请求的时候。所以我们看 OFChannelHandler ，能够视为是业务相关的第一个UpstreamHandler，在通道连接的时候会回送一个HELLO消息，这里的重点看处理消息的过程，进入函数 messageReceived
接下来的处理流程（例如以下），在收到 GET_CONFIG_REPLY 消息之后说明这个SW准备好了（会把握手状态改为 HandshakeState.READY），而后会把这个SW增加到activeSwitches 和 updates中：





更新堵塞队列的代码是：
[align=left] updateActiveSwitchInfo(sw);[/align]
[align=left] SwitchUpdate update = new SwitchUpdate(sw, true);[/align]
[align=left] try {[/align]
//
把update加到BlockingQueue里,假设BlockQueue没有空间,则调用此方法的线程被阻断
//
直到BlockingQueue里面有空间再继续.
[align=left] this.updates .put(update);[/align]
} catch (InterruptedException
e) {
log.error("Failure
adding update to queue" , e);
[align=left] }[/align]

通过上面的分析，相当于有了一个生产消费者模型，生产者就是交换机的增加或者移除消息，消费者就是Controller的处理过程，取出消息进行计算，为拓扑更新服务。详细过程仍然是一个监听者模式，把SW的更新信息分发到各个订阅者中进行处理（看SwitchUpdate类），代码例如以下：
public void dispatch()
{
if (log .isDebugEnabled())
{
log.debug("Dispatching
switch update {} {}", sw, added);
[align=left] }[/align]
//
遍历这些listeners，处理增加或移除事件
if (switchListeners != null)
{
for (IOFSwitchListener
listener : switchListeners) {
[align=left] if (added )[/align]
[align=left] listener.addedSwitch( sw);[/align]
[align=left] else[/align]
[align=left] listener.removedSwitch( sw);[/align]
[align=left] }[/align]
[align=left] }[/align]
[align=left] }[/align]

那么订阅 SwitchUpdate 消息的类是谁呢？LinkDiscoveryManager！交换机的增加或者移除活动肯定会带来链路信息的改变，当增加一个新SW的时候，就会通过发送 LLDP frame 来发现拓扑结构（參见 Floodlight Controller 路由原理 ）。代码例如以下
public void addedSwitch(IOFSwitch
sw) {
[align=left] //这里的设计须要优化[/align]
//
It's probably overkill to send LLDP from all switches, but we don't
//
know which switches might be connected to the new switch.
//
Need to optimize when supporting a large number of switches.
sendLLDPTask.reschedule(2000,
TimeUnit.MILLISECONDS );
//
Update event history
[align=left] evHistTopoSwitch(sw, EvAction. SWITCH_CONNECTED, "None");[/align]
[align=left] }[/align]

转载注明出处：/article/1559002.html