Pox的框架及启动过程分析

    Pox作为OpenFlow的一种控制器, 具有能将交换机送上来的协议包交给指定软件模块的功能. 使用过Pox的都知道, 组件和事件是Pox的两个重要概念, 它们两个共同撑起了Pox的大部分功能. Pox的事件和组件的协调工作机制可以参见伟辰同学的POX事件系统分析. 而这篇文章主要讲的是Pox的大体结构并简要介绍Pox是如何启动的.

    从上图可以看出, Pox主要由Core和组件组成, 其中Core中比较重要的模块是of_01和openflow. 

    of_01主要是在运行一个线程, 该线程不停地循环监听与交换机的TCP连接(该功能的实现用的就是Pox的recoco方法, 部分详情见Pox中recoco代码阅读笔记, 当某交换机送上来一个协议消息时, of_01会触发该消息所对应的事件. 如果看了伟辰的文章就应该知道, 事件是需要Source 和 Sink的. Source的功能是给组件提供可被监听的事件, 并提供接口(即raise函数)去触发事件给监听它的组件们. 而Sink就是监听Source的组件. of_01在此处共触发了两个Source的事件, 一是该交换机的Connection(在交换机连到Pox时会被创建), 二是openflow模块. 也就是说, 任意交换机传上来的消息都会触发openflow的事件, 设计自己的组件时, 如果不需要监听特定的交换机的话, 监听openflow准没错.

    openflow是个事件Source的存在, 它能被任何交换机的任意消息触发事件. 其他的上面说过了, 就不说了.

    由此看Pox,的框架还是不复杂的. 数据的基本流程就是当of_01监听到交换机传上来的消息后, 除了握手的消息不触发给组件而是自己处理外, 其他的都会触发事件. 监听该交换机或者openflow的组件就会被触发相应的函数来处理该事件.

    下面是附有部分函数的Pox启动过程:

    1.Core实体化, 并在初始化时建立一个scheduler
    2.Dolauch()
        2.1.分析系统选项
        2.2.Pre_start()
            2.1.1.处理系统选项(–no-cli等)
            2.1.2.实体化一个OpenFlowConnectionArbitor类, 用做以后建立连接.以后将连接监听”openflow”的组件
            2.1.3.实体化一个OpenflowNexus类, 名为openflow, 加入core中. 作为控制与所有交换机的中介, 也就是说, 所有交换机都要和openflow相连, 而控制器可以通过openflow控制所有交换机.
        2.3.启动用户想启动的组件(l2_learning等), 也就是执行组件的lauch函数, 监听该组件建一个该组件的实体并将组件的_handle_函数加入到对应的event的处理队列中
    3. post_start()
        3.1. 实体化一个openflow_01_task组件, 名为of_01, 加入core中.
    4.Core.goUp()
        4.1.Raise一个GoingUpEvent事件, 该事件会运行of_01的_handle_GoingUpEvent函数
             4.1.1._handle_GoingUpEvent将of_01作为task加入到core.scheduler的任务队列中
    5.Core.Scheduler线程的动作
        5.1.第一次连接, 会创建一个socket并实体化一个connection类
             5.1.1.Connection初始化的时候会发送hello包到socket的端口
        5.2.收到features_reply包通过read()函数将连接的nexus变量赋为”openflow”, 实现了交换机与”openflow”的连接, 并把openflow的connection列表中加入该交换机.
        5.3.之后来的包都通过read()处理, 其调用包中的事件类型所对应的handle_()函数
             5.3.1.Handle_()一般会raise两次该事件,一次由”Openflow”raise, 一次由该连接自己raise.