博观约取

原创 Linux内核hlist数据结构分析

在内核编程中哈希链表hlist使用非常多，比如在openvswitch中流表的存储中就使用了（见[1]）。hlist的表头仅有一个指向首节点的指针，而没有指向尾节点的指针，这样在有很多个buckets的HASH表中存储的表头就能减少一半的空间消耗。     和hlist相关的数据结构如下，桶中存储的 hlist_head 是具有相同hash值的entry构成的链表，每个entry包含一个 hl

原创 斐波那契数列

《编程之美》#include #include #include //1.按照斐波那契的定义容易用递归实现int fibonacci( int n){    if(n  //看具体数学说负数也有对应的 Fibonacci值        return 0;    } else if (n == 1){        return 1;  

原创 OVS流表查询过程分析

OVS中流表操作的理解关键在于这里哈希表的实现，引入的 flex_array方便了内存的管理，通过 hash&（桶数-1）可以随机的将一个元素定位到某一个桶中。 接下来是代码细节。一. 核心数据结构//流表struct flow_table{      struct flex_array * buckets; //具体的流表项      unsigned

原创 哈希表的简单实现

下面这个散列表的实现来自K&R，很经典。在其他场景中遇到的实现更复杂，基本原理不变，只是在hash算法，或者在快速查询上做了优化。#include #include //具有相同hash值构成的链表struct nlist{    struct nlist * next;    char * name;  //key-定义的名字    char 

原创 Head First装饰模式（Decorator）

装饰者模式是动态的将责任附加到另一个对象上，由这个对象负责；这个装饰与被装饰的组件接口一致，因此对使用该组件的客户透明；其中的关键点是装饰者可以在所委托被装饰者的行为之前和之后，加上自己的行为，已达到特点的目的。代码如下：-------------Component//装饰者模式一般使用抽象类public abstract class Beverage {

原创 Floodlight中 处理packetin消息的顺序（2）

前面通过阅读代码知道了如何判断各个模块处理某个消息的先后顺序，那么内部是如何实现的呢？     每当一个模块表示对一个消息感兴趣的时候，就会调用IFloodlightProviderService（具体有Controller类实现）的addOFMessageListener方法进行注册订阅，核心工作是由 ListenerDispatcher类来完成：1）每次增加一个观察者的时候都会判断其是否是

原创 Head First观察者模式（Observer）

观察者模式定义对象之间的一对多的依赖，当那一个对象（主题）状态改变时，所有的依赖者（观察者）都会收到通知并作出相应的动作。观察者模式的使用非常广泛。代码实现：-------------------主题接口public interface Subject {      public void registerObserver(Observer o);      p

原创 Floodlight中 处理packetin消息的顺序（1）

当Controller和SW建立连接之后，就可以处理来自SW的各种OF msg。当接收到 packetin 消息之后，会将其分发给各个监听了这个OFMessage的listeners，所以如果我们要设计自己的控制器模块，只需要实现相应的接口方法，约定执行顺序即可。接口IListener 主要抽象了监听器模块的名字，执行顺序，接口IOFMessageListener则抽象了我们的Controller

原创 Floodlight controller和OF SW交互流程图

原创 ChannelHandler原理

1.创建ChannelPipeline的方法是实现接口 ChannelPipelineFactory 中的那个 getPipeline() 方法，然后根据自己的业务需要加入相应的 ChannelHandler。 2. 接口 ChannelHandlerContext 提供的功能是统一管理这些ChannelHandler，使其能够和这个ChannelPipelin

原创 Floodlight 中 ChannelPipeline 结构图

1. IdleStateHandler 当Channel上没有执行相应的读写操作一定时间的时候出发一个 IdleStateEvent 事件；2. ReadTimeoutHandler 读超时处理；3. HandshakeTimeoutHandler 设置一个定时器检查连接的状态，握手阶段 ；4 . OFChannelHandler 核心，处理所有的业务。

原创 OFMessageDecoder 分析

OFMessageDecoder 继承了抽象类 FrameDecoder。FrameDecoder 会将接收到的ChannelBuffers 转换成有意义的 frame 对象，在基于流的传输过程中，通常会发生分片和重组的情况，所以就需要一个解码器，根据特定协议的约束，将收到的包理解为相应的，易于应用逻辑层处理的对象。这里调用的是 BasicFactory 的 parseMe

原创 Floodlight之 FloodlightContextStore 数据结构

FloodlightContextStore 代表的是一种缓存模型（利用的是ConcurrentHashMap），里面存储的是上下文相关的对象，能够根据相应的key得到具体的 Object，存在的意义是Floodlight中注册监听某个事件的listener可以在被调用的时候直接从中取出上下文信息（context information）。下面是重要的代码片段.基本数据结构：pub

原创 Floodlight 启动流程分析

1. 在Main中先是加载模块，启动REST服务，而后构建一个实现了IFloodlightProviderService接口的实例（即Controller）并运行；2. 接下来进入Controller的run（）方法，此时所有的环境初始化工作已经完成，构建一个基于netty的TCP server，最重要的是流水线factory OpenflowPipelineFactory 的设置，里面是co

原创 Netty实现时间服务示例

相关知识点：[1] ChannelGroup是一个容纳打开的通道实例的线程安全的集合，方便我们统一施加操作。所以在使用的过程中可以将一些相关的Channel归类为一个有意义的集合，关闭的通道会自动从集合中移除，而且一个Channel可以属于多个ChannelGroup。常见的应用场景是 向一组通道广播消息；简化一组通道的关闭流程。[2] 因为在Channel中流通的是Channel

原创 Netty入门实例及分析

1.客户端细节分析ChannelFactory是创建一个通道（和一次具体的通信实体关联如网络套接字）的主要接口，比如NioServerSocketChannelFactory 会创建一个Channel，有基于NIO的服务套接字作为底层的通信实体。一旦一个新的通道创建，那么对应的ChannelPipeline就会开始处理相关的ChannelEvents。 NioC

原创 Floodlight下发流表过程分析

转载请注明出处：当一个packet到达openflow交换机，会进行流表的匹配，如果没有找到相应的流表项，就会发送一个packet_in消息到达SDN controller端，控制器根据一定的路由算法决策后，会向该路径上的所有交换机下发流表（也就是发送FLOW_MOD消息，里面有对应的action）。这里要知道的是在SDN的环境下，控制器具有全局拓扑信息，每当有链路状态改变时就会跟

原创 结构体内存对齐规则

结构体的内存布局记住两个规则即可，这是编译器的优化措施。规则1：结构体中第一个成员的偏移量是0，以后每个成员的位置是x的倍数；           x = min(#pragma pack(), 该成员自身的长度)规则2：成员对齐后，结构体自身也要对齐，按照y的倍数进行；          y = min(#pragma pack(), 最大成员尺寸)。其中#pragma pa

原创 C语言0长度数组（柔性数组）

C语言0长度数组（柔性数组）                                                                               0长度数组，又称为柔性数组（flexible array），通常用来实现变长数组，常见于TLV（type-length-value）的数据结构中。在标准 C 和 C++ 中，不允许用 0 长度数组，但在

原创 向Java枚举类型中添加新方法

除了不能继承enum之外，可将其看做一个常规类。甚至可以有main方法。注意：必须先定义enum实例，实例的最后有一个分号。下面是一个例子：返回对实例自身的描述，而非默认的toString返回枚举实例的名字。public enum Color { RED("红色", 1), GREEN("绿色", 2), BLANK("白色", 3), YELLO("黄色", 4);

原创 文件分块上传客户端实现

首先对文件按内容分块（有块大小的约束），然后对于每个chunk构造单独的一个UDP 数据报进行传输，在应用层的开始是自定义的包头，有块号，块长度，块指纹等元数据信息，这些信息便于接收端能够按序正确接收。/*--vonzhou ---this project is to upload file after chunking using rabin fingerprint, h

原创 从PACKET_IN消息中得到packet data

在Floodlight模块中如果想得到packet in消息，就对相应的消息类型进行监听即可，然后在receive方法中就可以操纵这个上传上来的packet_in。     关键代码：  Ethernet eth = IFloodlightProviderService.bcStore.get(cntx,

原创 Nginx 的安装入门

1.首先需要安装必须的库，PCRE，zlibsudo apt-get install libpcre3 libpcre3-dev如果找不到文件的话就下载源文件进行安装。2.解压下载的nginx源码，进入目录： sudo ./configure 得到的输出如下：Configuration summary  + using system PCRE library  +

原创 Bloom filter的实现以及常用的hash函数

Bloom filter的实现以及常用的hash函数bloom filter利用时间换空间的思想，利用多个哈希函数，将一个元素的存在状态映射到多个bit中，特别是在网络环境中，BF具有广泛的用途，关键问题就是要减少false positive rate（可以设置参数来调节），扩展有 counting BF。这里选用的hash函数是表现较好的 BKDRHash , SDBMHash, D

原创 使用 jackson 解析 json 示例

首先需要下载3个包，下载地址在Github ，这三个核心模块分别是：Streaming ("jackson-core") defines low-level streaming API, and includes JSON-specific implementationsAnnotations ("jackson-annotations") contains standard Jack

转载 Open vSwitch datapath developer documentation

Open vSwitch datapath developer documentation=============================================The Open vSwitch kernel module allows flexible userspace control over flow-level packet processing on selec

原创 OVS响应OFPT_FLOW_MOD过程分析

整理处理流程图：1. 通过对of msg进行解码，可以得到具体的flow_mod以及对应的actions，（这里看增加流表的情况），接下来add_flow函数就会根据flow_mod制定的流来构建特定的规则分类器，增加到oftable中。具体过程是：选择一个合适的表；构建一个分类规则（关键代码如下）；插入。这样此次通信的任务就完成了，当再有packet因为在datapa

原创 OVS处理upcall过程分析

处理upcall的整体框架是：1.由函数handle_upcalls（）批量处理（in batches）的是由内核传上来的dpif_upcalls，会解析出upcall的类型。这里主要看在内核中匹配流表失败的MISS_UPCALL。处理完成后会得到多个flow_miss。结构体dpif_upcall代表的是由内核传到用户空间的一个包，包括上传原因，pac

原创 ovs处理openflow消息的流程

ovs处理openflow消息的流程

原创 对openflow 1.0协议的扩展

通过这几天对openvswitch代码的分析，以及项目的需要，需要对openflow 1.0进行一定的扩展，发现网上没有这方面的教程，虽然在搞懂ovs代码架构，floodlight controller中利用的事件驱动模型之后，会觉得并不是难事，但是对于刚入门SDN的同学来说，需要一番折腾，这里简单记录一下，希望帮助到其他人。 环境配置：2host + 1 OVS + floodlight