这是openfire消（xiāo）息接收、处理流（liú）程图下载，Apache MINA 是一个网络应用框架（jià），有助（zhù）于（yú）用户非常方便地（dì）开发（fā）高性（xìng）能、高伸缩（suō）性的网络应（yīng）用。它通过Java NIO提供了一个（gè）抽象的、事件驱（qū）动（dòng）的、异（yì）步的位于（yú）各（gè）种传输（shū）协议（如TCP/IP和UDP/IP）之上的API，Apache MINA 通常可被称之（zhī）为。
openfire消息接收（shōu）、处理流程图首先boot()调用（yòng）of_01.launch()向core中注（zhù）册了一（yī）个OpenFlow_01_Task的类的组件，并且把这个组件明（míng）明为"of_01"。
openfire消息接收、处理流程图在这个类中有一（yī）个run方法会轮询所有socket，包括（kuò）用来监听连接请求的listener和维持与OVS连接的socket，每一个和（hé）OpenFlow交换（huàn）机的连接都会（huì）生成一个（gè）Connection类的（de）实例，当收到（dào）OpenFlow消息之后，会（huì）调用Connection类（lèi）中定义的read()方法来（lái）检查这个OpenFlow消（xiāo）息（xī）的头（tóu）部是不是符合规范（fàn），包头部（bù）中的length是不是和（hé）包本身的长度相符，是何种类（lèi）型的OpenFlow消息等，最终交给相应的handle函数（shù）来进行处理。
在（zài）read()方法中，会（huì）根据（jù）解（jiě）析（xī）出的OpenFlow类型调用（yòng）unpackers函（hán）数，实际上是调用了libopenflow_01.py中定（dìng）义（yì）的每种OpenFlow消息（xī）的类中的unpack方法，生成一（yī）个赋过（guò）值的该类的实例。
值得注意（yì）的是可（kě）能会出现几个OpenFlow消息在一（yī）个TCP包中的情况，这（zhè）里采用顺序解析的方式，每（měi）解（jiě）析（xī）完一个OpenFlow消息（xī），就会得到（dào）一（yī）个新的offset，从而解析下一个OpenFlow消息（xī）。
1. 由（yóu）于每个用（yòng）户都有1到多个好友，服务器的处理量被放（fàng）大。
2. 分布式处（chù）理的复杂度（dù），你（nǐ）的好友可能同（tóng）时分布在（zài）n个服务器上，而且同时上（shàng）线的好友没（méi）有规律。
3. 请求（qiú）量不均（jun1）衡，可能（néng）瞬（shùn）时（shí）非常大。比如你（nǐ）服务器刚重启所有的客户几乎同时自动重连过来。比（bǐ）如（rú）Twitter宕机（jī）都是在一（yī）些热点（diǎn）事件时，大家活（huó）跃度突（tū）然（rán）同（tóng）时（shí）增大。所以（yǐ）系统必须（xū）按峰值的处理量设（shè）计。
4. 缓存（cún）cache设计（jì）困难。每个用户（hù）的在线好友都不同，而且随时在变。
5. 隐（yǐn）身同黑名单的业务（wù）逻辑很难高效（xiào）处理。
