在Main中先是加载模块，启动REST服务，而后构建一个实现了IFloodlightProviderService接口的实例（即Controller）并运行，进入Controller的run（）方法；
位置：net.floodlightcontroller.core.Main.java ；
功能：初始化IFloodlightModuleContext变量，启动Controller和RESTApi Service位置：net.floodlightcontroller.core.internal.Controller.java
Run()方法启动Controller，监听Switch的请求和将监听事前发送给各个监听模块。
此时所有的环境初始化工作已经完成，构建一个基于netty的TCP server，最重要的是流水线factory OpenflowPipelineFactory 的设置，里面是controller上流，下流处理的handler。
Floodlight 使用的是Netty架构，在Controller.java 入口函数中显示创建ServerBootstrap：
//使用到了JBoss 的Netty框架
//创建Netty的服务端ServerBootstrap
final ServerBootstrap bootstrap = createServerBootStrap();
bootstrap.setOption("reuseAddr", true);
bootstrap.setOption("child.keepAlive", true);
bootstrap.setOption("child.tcpNoDelay", true);
bootstrap.setOption("child.sendBufferSize",Controller.SEND_BUFFER_SIZE);
//创建处理Switch连接的工厂
ChannelPipelineFactory pfact =
new OpenflowPipelineFactory(this, null);
//设置服务端处理连接的工厂
bootstrap.setPipelineFactory(pfact);
InetSocketAddress sa = (openFlowHost == null) ? new InetSocketAddress(openFlowPort)
: new InetSocketAddress(openFlowHost, openFlowPort);
//将服务端加入线程池
final ChannelGroup cg = new DefaultChannelGroup(); cg.add(bootstrap.bind(sa));
log.info("Listening for switch connections on {}", sa);设置套接字选项ChannelPipeline，此时监听套接字就准备好处理来自SW的各种消息；这里最核心的就是 OpenflowPipelineFactory ，会加入各个业务相关的Handler，ChannelPipeline工厂代码如下：
public ChannelPipeline getPipeline() throws Exception {
OFChannelState state = new OFChannelState();
ChannelPipeline pipeline = Channels. pipeline();
pipeline.addLast( "ofmessagedecoder", new OFMessageDecoder());
pipeline.addLast( "ofmessageencoder", new OFMessageEncoder());
pipeline.addLast( "idle", idleHandler );
pipeline.addLast( "timeout", readTimeoutHandler );
pipeline.addLast( "handshaketimeout",
new HandshakeTimeoutHandler(state, timer , 15));
if (pipelineExecutor != null)
pipeline.addLast( "pipelineExecutor",
new ExecutionHandler(pipelineExecutor ));
//OFChannelHandler 是核心
pipeline.addLast( "handler", controller.getChannelHandler(state));
return pipeline;
}当Channel建立，接收到来自OF SW的消息之后就会调用 messageReceived() 方法；根据不同的of msg类型，分发给 processOFMessage 进行具体处理；此外，如果这个消息需要进行对SW的回复，或者有其他监听者感兴趣，就呼叫 handleMessage 进行额外的处理，代码贴出来。
protected void handleMessage(IOFSwitch sw, OFMessage m, FloodlightContext bContext){
Ethernet eth = null;
switch (m.getType()) {
case PACKET_IN:
OFPacketIn pi = (OFPacketIn)m;
// 默认情况下总是true
if (Controller.ALWAYS_DECODE_ETH) {
eth = new Ethernet();
//解析packet_in消息到eth中，所以下面的bcStore可以直接存储
eth.deserialize(pi.getPacketData(), 0, pi.getPacketData().length);
counterStore.updatePacketInCounters(sw, m, eth);
}
// fall through to default case...
default:
List<IOFMessageListener> listeners = null;
if (messageListeners.containsKey(m.getType())) {
listeners = messageListeners.get(m.getType()).getOrderedListeners();
}
FloodlightContext bc = null;
if (listeners != null) {
// Check if floodlight context is passed from the calling
// function, if so use that floodlight context, otherwise
// allocate one
if (bContext == null) {
bc = flcontext_alloc();
} else {
bc = bContext;
}
if (eth != null) {
IFloodlightProviderService.bcStore.put(bc,IFloodlightProviderService.CONTEXT_PI_PAYLOAD, eth);
//缓存到hashmap中，所以当我们添加自己的模块来监听packetin消息的时候，可以从中取出，做自己的业务处理。
}
Command cmd;
for (IOFMessageListener listener : listeners) {
if (listener instanceof IOFSwitchFilter) {
if (!((IOFSwitchFilter)listener).isInterested(sw)) {
continue;
}
}
// 遍历所有对packetin感兴趣的listener，分别执行他们的receive方法；
cmd = listener.receive(sw, m, bc);
if (Command.STOP.equals(cmd)) {
break;
} } }
if ((bContext == null) && (bc != null)) flcontext_free(bc);
} }３. 在循环中随时处理SW的更新消息，开始分发事件给监听者：
// main loop
// 不断处理阻塞队列中SW的更新信息
while (true ) {
try {
IUpdate update = updates.take();
update.dispatch();
} catch (InterruptedException e) {
return;
} catch (StorageException e) {
log.error("Storage exception in controller "
+ "updates loop; terminating process", e);
return;
} catch (Exception e) {
log.error("Exception in controller updates loop", e);
}
}４. 那么Controller中的BlockingQueue中的更新信息是在何时加入的呢？这里只跟踪交换机加入的情况，很容易想到当监听套接字收到一个来自OF SW请求的时候。所以我们看 OFChannelHandler ，可以视为是业务相关的第一个UpstreamHandler，在通道连接的时候会回送一个HELLO消息，这里的重点看处理消息的过程，进入函数 messageReceived 接下来的处理流程（如下），在收到 GET_CONFIG_REPLY 消息之后说明这个SW准备好了（会把握手状态改为 HandshakeState.READY），而后会把这个SW加入到activeSwitches 和 updates中。
Floodlight controller和OF SW交互流程图：
更新阻塞队列的代码是：
updateActiveSwitchInfo(sw);
SwitchUpdate update = new SwitchUpdate(sw, true);
try {
// 把update加到BlockingQueue里,如果BlockQueue没有空间,则调用此方法的线程被阻断
// 直到BlockingQueue里面有空间再继续.
this.updates .put(update);
} catch (InterruptedException e) {
log.error("Failure adding update to queue" , e);
}通过上面的分析，相当于有了一个生产消费者模型，生产者就是交换机的加入或者移除消息，消费者就是Controller的处理过程，取出消息进行计算，为拓扑更新服务。具体过程仍然是一个监听者模式，把SW的更新信息分发到各个订阅者中进行处理（看SwitchUpdate类），代码如下：
public void dispatch() {
if (log .isDebugEnabled()) {
log.debug("Dispatching switch update {} {}", sw, added);
}
// 遍历这些listeners，处理加入或移除事件
if (switchListeners != null) {
for (IOFSwitchListener listener : switchListeners) {
if (added )
listener.addedSwitch( sw);
else
listener.removedSwitch( sw);
}
}
}那么订阅 SwitchUpdate 消息的类是谁呢？LinkDiscoveryManager！交换机的加入或者移除活动肯定会带来链路信息的改变，当加入一个新SW的时候，就会通过发送 LLDP frame 来发现拓扑结构（参见 Floodlight Controller 路由原理 ）。代码如下
public void addedSwitch(IOFSwitch sw) {
//这里的设计需要优化
// 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
evHistTopoSwitch(sw, EvAction. SWITCH_CONNECTED, "None");
}５.当一个packet到达openflow交换机，会进行流表的匹配，如果没有找到相应的流表项，就会发送一个packet_in消息到达SDN controller端，控制器根据一定的路由算法决策后，会向该路径上的所有交换机下发流表（也就是发送FLOW_MOD消息，里面有对应的action）。这里要知道的是在SDN的环境下，控制器具有全局拓扑信息，每当有链路状态改变时就会跟新拓扑，而路由的计算是需要下发转发规则的时候进行。下面对这个流程进行详细分析。
链路发现模块会关注两种消息 PACKET_IN 和 PORT_STATUS ，从而分析链路的变更。这里看对于PACKET_IN ，LinkDiscoveryManager的处理过程：
LinkDiscoveryManager完成的工作是增加或更新链路状态，加入到一个LDUpdates队列中，接下来看拓扑管理模块TopologyManager，它在启动的时候会新起一个线程 NewInstanceWorker ：首先根据消息类型来增删该链路的状态，然后创建一个计算拓扑的实例TopologyInstance来计算出拓扑并存储，具体过程如下：
当完成拓扑计算后，当来了一个packet_in，就会根据源目SW得到路径。
接下来防火墙，负载均衡模块会发挥作用（这里先略过）。
最后路由模块会完成最终的下发流表操作，这里看Forwarding模块中的processPacketInMessage（）。
会从packet中得到相应的源目设备实例IDevice，而后判断是否在同一个openflow island上，如果不在的话就
doFlood(sw, pi, cntx)，这里主要看二者在同一个island的情况。然后得到每个设备的AttachmentPoints，
然后找到二者能够连通的粘合点，接下来得到路劲，最后构造flow_mod消息，写入通道，下发给SW。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
