Mina框架研究

Apache MINA(Multipurpose Infrastructure for Network Applications) 是 Apache 组织一个较新的项目，它为开发高性能和高可用性的网络应用程序提供了非常便利的框架。

这个框架的优点：

– 异步 
– 无阻塞 
– 事件驱动 
– 支持TCP, UDP, APR, 串口… 
– 通过 过滤器（Filters）实现扩展性 
– 同时提供协议框架

 

总体框架

之前的一个项目用到了MINA，最近想再系统的整理一下，主要参考MINA 2.0 User Guide

基于MINA框架的应用程序架构应该是这样的：

底层是基于JAVA的NIO 1.0实现的；

其核心部分架构是这样的：

 

内部可以分为3 个层次：

I/O Service - 执行实际的I / O，可以选择现成的Services如 (*Acceptor)，也可以自己写。

I/O Filter Chain - 这是一个由多个过滤器组成的过滤器链，在这个环节将字节数据转换到特定的数据结构中（Filters/Transforms bytes into desired Data Structures and vice-versa） 
I/O Handler - 实际的业务逻辑部分

 

Server端应用

对socket通信来说，使用比较广泛的是基于Server端的应用，尤其是并发规模达到一定程度后，颇具挑战性。那么我们来看一下，基于MINA框架的Server端应用：

1、IOAcceptor 监听指定的端口，处理新的网络连接；一旦一个新的连接到达后，IOAcceptor 就产生一个session，后续所有从这个IP和端口发送过来的请求就将通过这个Session被处理。

2、Session创建后，后续所有的数据包都被人到过滤器链中，通过过滤器将原始的字节码转变成高层的对象，这个环节PacketEncoder/Decoder就十分有用。

3、最后数据包或对象被传送给Handler做业务逻辑处理；

Main.java:

public class Main {
    private static final int PORT = 9123;
    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) throws IOException {

        IoAcceptor acceptor = new NioSocketAcceptor();
        acceptor.getFilterChain().addLast( "logger", new LoggingFilter() );
        acceptor.getFilterChain().addLast( "codec", new ProtocolCodecFilter( new TextLineCodecFactory( Charset.forName( "UTF-8" ))));

        acceptor.setHandler(  new TimeServerHandler() );

        acceptor.getSessionConfig().setReadBufferSize( 2048 );
        acceptor.getSessionConfig().setIdleTime( IdleStatus.BOTH_IDLE, 10 );
        acceptor.bind(new InetSocketAddress(PORT));

    }

}

1、创建IoAcceptor；

2、加入日志记录和解码的过滤器，其中日志过滤器用SL4J库记录信息，而编码过滤器则解码所有收到的信息。使用 new TextLineCodecFactory() 发送的信息迕行编码，返是MINA自带的，功能有限，只能处理文本戒者String类型。

3、设置ServerHandler，这里是一个自定义的Handler：TimeServerHandler；

4、设置Session的对应的I/O processor 读缓存区大小2048；通常这个参数不需要设置；

5、设置空闲时间，这里的BOTH_IDLE指EADER_IDLE 和 WRITER_IDLE. 都为10秒；

6、绑定监听端口9123；

TimeServerHandler.java:

/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */

package minatest1;

/**
 *
 * @author THINKPAD
 */

import java.util.Date;

import org.apache.mina.core.session.IdleStatus;
import org.apache.mina.core.service.IoHandlerAdapter;
import org.apache.mina.core.session.IoSession;

public class TimeServerHandler extends IoHandlerAdapter
{
    @Override
    public void exceptionCaught( IoSession session, Throwable cause ) throws Exception
    {
        cause.printStackTrace();
    }

    @Override
    public void messageReceived( IoSession session, Object message ) throws Exception
    {
        String str = message.toString();
        if( str.trim().equalsIgnoreCase("quit") ) {
            session.close();
            return;
        }

        Date date = new Date();
        session.write( date.toString() );
        System.out.println("Message written...");
    }

    @Override
    public void sessionIdle( IoSession session, IdleStatus status ) throws Exception
    {
        System.out.println( "IDLE " + session.getIdleCount( status ));
    }
}

这里主要有一下几个主要的方法：

messageReceived(…)，对接收到的消息（已经解码）迕行下一步处理，这里对收到的字符串进行判断，如果是”quit”则断开连接；否则输出当前时间的字符串格式；

exceptionCaught(…)，自定义异常处理， 要不然异常会被“吃掉”；

sessionIdle，当Session处于IDLE状态的时候，输出空闲状态次数；

 

 

测试，输入：telnet 127.0.0.1 9123，随便输入一串字符串，显示当前的时间：

 

IO Service

IoService是一个接口，有两种实现：IoAcceptor和IoConnector；其中IoAcceptor是针对Server端的实现，IoConnector是针对Client端的实现；IoService的职责包括：

1、监听器管理

2、IoHandler

3、IoSession管理

4、FilterChain管理

5、Statistics管理

 

IoAcceptor

主要用于创建新的连接。MINA提供了多种实现，所以几乎不需要我们自己再去实现：

NioSocketAcceptor：无阻塞的Socket 传输Acceptor，针对TCP

NioDatagramAcceptor : 无阻塞的Socket 传输Acceptor，针对UDP

AprSocketAcceptor : 阻塞的Socket 传输Acceptor,基于 APR

VmPipeSocketAcceptor : the in-VM Acceptor

 

IoConnector

针对Client端的Socket连接，有多种实现：

NioSocketConnector : 无阻塞的Socket 传输Connector，针对TCP 
NioDatagramConnector : 无阻塞的Socket 传输Connector，针对UDP 
AprSocketConnector : 阻塞的Socket 传输Connector,基于 APR 

ProxyConnector : 一个支持代理服务的 Connector ，通过截取连接的请求，并将终端指向代理设置的地址。

SerialConnector : 针对串口传输的Connector

VmPipeConnector : the in-VM * Connector*

 

Session

任何时候只要有新的连接到来，都会生成一个Session对象，并且一致保存在内存中，只到连接断开；

Session有一系列状态，如下：

Connected : session被创建，并有效 
Idle : session至少在一个空闲周期（见配置）内没有处理过任何请求 
Idle for read : 在一个空闲周期内没有做实际的读操作

Idle for write : 在一个空闲周期内没有做实际的写操作

Idle for both : 在一个空闲周期内没有做实际的读和写操作 
Closing :session正在被关闭

Closed : session已经被关闭

 

IoBuffer

IoBuffer是MINA内部使用的一个byte buffer，MINA并没有直接使用NIO 的ByteBuffer。不过IoBuffer 是对 ByteBuffer 的一个封装。IoBuffer 中的很多方法都是对 ByteBuffer 的直接继承。只是对 ByteBuffer 添加了一些扩展了更加实用的方法。

基本用法

由于IoBuffer是对Nio的ByteBuffer 的封装，所以基本概念还是相同的，下面简单介绍一下：

1、capacity：该属性描述这个缓冲区最多能缓冲多少个元素，也是Buffer最大存储元素数，这个值是在创建Buffer的时候指定的，且不能修改。

2、Limit：在从Buffer中向Channel中写数据时，limit变量指示了还剩多少数据可以读取，在从Channel中读取数据到Buffer中时，limit变量指示了还剩多少空间可供存放数据。position正常情况下小于或者等于limit。

3、Position：Buffer实际上也就是个array。当你从Channel中读数据时，你把从Channel中读出来的数据放进底层array，position变量用来跟踪截止目前为止已经写了多少数据。更精确的讲，它指示如果下次写Buffer时数据应该进入array的哪个位置。因此如果已经从Channel中读出了3个字节，Buffer的position会被置为3，指向array中第四个位置。

4、Mark：一个可以记忆的Position位置的值，在调用reset()方法时会将缓冲区的Position重置为该索引，并非总是需要定义Mark，但是在定义Mark时，不能将其定义为负数，并且不能让它大于Position，如果定义了Mark，则在该Position或Limit调整为小于该Mark值时，该Mark将被丢弃。

下面通过一个例子来说明：

i、初始状态下：

此时position为0，limit和capacity都被设为9；

 

ii、从Channel中读入4个字节数据到Buffer，这时position指向4（第5个）：

 

iii、在做写操作之前，我们必须调用一次flip()方法，这个方法做了两件重要的事情： 
1. 将limit设置到当前的position处。 
2. 设置position为0。

 

iiii、执行写操作后;

iv、执行clear后，position设为0，limit设为capition，mark则丢弃；

 

 

因为IoBuffer是一个抽象类，不能直接实例化，所有使用的时候需要调用allocate方法来进行内存分配；

allocate有两种定义：

   1: // Allocates a new buffer with a specific size, defining its type (direct or heap)

   2: public static IoBuffer allocate(int capacity, boolean direct)

   3:  

   4: // Allocates a new buffer with a specific size

   5: public static IoBuffer allocate(int capacity)

这里：

capacity：buffer的大小；

direct：如果为true，则得到direct buffer，如果为false，则得到heap buffer

direct buffer和heap buffer的区别分析：

Direct Buffer不是分配在堆上的，它不被GC直接管理（但Direct Buffer的JAVA对象是归GC管理的，只要GC回收了它的JAVA对象，操作系统才会释放Direct Buffer所申请的空间），它似乎给人感觉是“内核缓冲区（buffer in kernel）”。Heap Buffer则是分配在堆上的，或者我们可以简单理解为Heap Buffer就是byte[]数组的一种封装形式。当我们把一个Heap Buffer写入Channel的时候，实际上底层实现会先构建一个临时的Direct Buffer，然后把Heap Buffer的内容复制到这个临时的Direct Buffer上，再把这个Direct Buffer写出去。因此把一个Direct Buffer写入一个Channel的速度要比把一个Heap Buffer写入一个Channel的速度要快。但是Direct Buffer创建和销毁的代价很高，所以要用在尽可能重用的地方。

public static IoBuffer allocate(int capacity)的用法：

   1: // 设置Allocates分配的默认类型，这里设为heap buffer.

   2:  IoBuffer.setUseDirectBuffer(false);

   3:  // 返回一个新的heap buffer.

   4:  IoBuffer buf = IoBuffer.allocate(1024);

 

IoBuffer允许生成一个自动扩展的buffer（这也是没有选择使用NIO的ByteBuffer的原因之一）；通过设置AutoExpand属性即可：

   1: IoBuffer buffer = IoBuffer.allocate(8);

   2: buffer.setAutoExpand(true);

   3:  

   4: buffer.putString("12345678", encoder);

   5:        

   6: // Add more to this buffer

   7: buffer.put((byte)10);

Filters

IoFilter 是MINA框架中一个核心的部分，如下图，对间于IoService和IoHandle之间，用于过滤所有的I/O事件和请求，其扮演的角色就像J2EE中的Servlet。

MINA提供不少现成的过滤器：

1、LoggingFilter ：日志过滤器，用于记录所有的事件和请求日志.

2、ProtocolCodecFilter：规约解析过滤器，用来将所有收到的ByteBuffer内容转换为POJO消息（对象),实现往来报文的编码和解码；

3、CompressionFilter：压缩过滤器；

4、SSLFilter

…

 

ProtocolCodecFilter

相对比较常用的是ProtocolCodecFilter，下面主要介绍一下ProtocolCodecFilter的使用：

还是以官方帮助文档中例子来说明(http://mina.apache.org/chapter-11-codec-filter.html)

这是一个图片服务器程序，请求图片的下行报文格式：

 

width: 请求图片的宽度 
height: 请求图片的高度 
numchars: 生成的字节个数

 

服务端返回两张图片：

length1: 图片1的大小 
image1: 图片1（PNG格式） 
length2: 图片2的大小

image2: 图片2（PNG格式）

 

现在如果想通过MINA框架来实现基于这一简单规约的编解码通信功能，应该如何做呢？

   1: public class ImageServer {

   2:     public static final int PORT = 33789;

   3:  

   4:     public static void main(String[] args) throws IOException {

   5:         ImageServerIoHandler handler = new ImageServerIoHandler();

   6:         NioSocketAcceptor acceptor = new NioSocketAcceptor();

   7:         acceptor.getFilterChain().addLast("protocol", new ProtocolCodecFilter(new ImageCodecFactory(false)));

   8:         acceptor.setLocalAddress(new InetSocketAddress(PORT));

   9:         acceptor.setHandler(handler);

  10:         acceptor.bind();

  11:         System.out.println("server is listenig at port " + PORT);

  12:     }

  13: }

这里先来看和Filter有关的部分：

acceptor.getFilterChain().addLast("protocol", new ProtocolCodecFilter(new ImageCodecFactory(false)));

在acceptor的Filter链中加入我们自己的过滤器，一个ProtocolCodecFilter的实现，这里的ImageCodecFactory又是什么呢？

   1: public class ImageCodecFactory implements ProtocolCodecFactory {

   2:     private ProtocolEncoder encoder;

   3:     private ProtocolDecoder decoder;

   4:  

   5:     public ImageCodecFactory(boolean client) {

   6:         if (client) {

   7:             encoder = new ImageRequestEncoder();

   8:             decoder = new ImageResponseDecoder();

   9:         } else {

  10:             encoder = new ImageResponseEncoder();

  11:             decoder = new ImageRequestDecoder();

  12:         }

  13:     }

  14:  

  15:     public ProtocolEncoder getEncoder(IoSession ioSession) throws Exception {

  16:         return encoder;

  17:     }

  18:  

  19:     public ProtocolDecoder getDecoder(IoSession ioSession) throws Exception {

  20:         return decoder;

  21:     }

  22: }

ImageCodecFactory是对接口ProtocolCodecFactory 的实现，是用来构建Filter的。ProtocolCodecFactory 接口只有两个方法：

   1: public interface ProtocolCodecFactory {

   2:  

   3:     public ProtocolEncoder getEncoder(IoSession is) throws Exception;

   4:  

   5:     public ProtocolDecoder getDecoder(IoSession is) throws Exception;

   6: }

   7:  

没错，这个规约编解码工厂需要装配一个编码器（Encoder）和一个解码器（Decoder）：

编码器：

   1: public class ImageRequestEncoder implements ProtocolEncoder {

   2:  

   3:     public void encode(IoSession session, Object message, ProtocolEncoderOutput out) throws Exception {

   4:         ImageRequest request = (ImageRequest) message;

   5:         IoBuffer buffer = IoBuffer.allocate(12, false);

   6:         buffer.putInt(request.getWidth());

   7:         buffer.putInt(request.getHeight());

   8:         buffer.putInt(request.getNumberOfCharacters());

   9:         buffer.flip();

  10:         out.write(buffer);

  11:     }

  12:  

  13:     public void dispose(IoSession session) throws Exception {

  14:         // nothing to dispose

  15:     }

  16: }

解码器：

   1: public class ImageRequestDecoder extends CumulativeProtocolDecoder {

   2:  

   3:     protected boolean doDecode(IoSession session, IoBuffer in, ProtocolDecoderOutput out) throws Exception {

   4:         if (in.remaining() >= 12) {

   5:             int width = in.getInt();

   6:             int height = in.getInt();

   7:             int numberOfCharachters = in.getInt();

   8:             ImageRequest request = new ImageRequest(width, height, numberOfCharachters);

   9:             out.write(request);

  10:             return true;

  11:         } else {

  12:             return false;

  13:         }

  14:     }

  15: }

这里解码器不是直接从ProtocolDecoder继承的，为什么呢？因为实际中接受的一个数据包并不能保证包含完整的一帧报文，就是所谓的断帧的情况，如果用CumulativeProtocolDecoder，就不需要自己处理这种情况了，MINA框架会将未解码的数据保留，等下一包数据到来后继续尝试解码；

这里编码器的encode和解码器的doDecode方法就是实际用来进行应用层规约编解码的；其中ImageResuest是下行请求规约对应POJO.

整个类的协助关系如下图所示：

 

 

Filter过滤器处理完后，就交给Handler，做进一步业务处理；

Response部分的就不多罗嗦了，可以看这里

至此对MINA框架用过的一些东西，从使用指南的角度做了一些总结，还有很多方面还没有用过，先留一个坑，等来日填补吧。MINA框架最吸引我的是这种设计思想，将通信、规约解析、业务处理分离得恰到好处，既不影响性能又方便扩展和替换。下一步希望从源代码的角度，学习一下其内部的实现思想。

解码器进一步介绍

在Mina 中编写解码器，可以实现ProtocolDecoder 接口，其中有decode()、finishDecode()、dispose()三个方法。这里的finishDecode()方法可以用于处理在IoSession 关闭时剩余的未读取数据，一般这个方法并不会被使用到，除非协议中未定义任何标识数据什么时候截止的约定，譬如：Http 响应的Content-Length 未设定，那么在你认为读取完数据后，关闭TCP连接（IoSession 的关闭）后，就可以调用这个方法处理剩余的数据，当然你也可以忽略调剩余的数据。同样的，一般情况下，我们只需要继承适配器ProtocolDecoderAdapter，关注decode()方法即可。但前面说过解码器相对编码器来说，最麻烦的是数据发送过来的规模，以聊天室为例，一个TCP 连接建立之后，那么隔一段时间就会有聊天内容发送过来，也就是decode()方法会被往复调用，这样处理起来就会非常麻烦。那么Mina 中幸好提供了CumulativeProtocolDecoder类，从名字上可以看出累积性的协议解码器，也就是说只要有数据发送过来，这个类就会去读取数据，然后累积到内部的IoBuffer 缓冲区，但是具体的拆包（把累积到缓冲区的数据解码为JAVA 对象）交由子类的doDecode()方法完成，实际上CumulativeProtocolDecoder就是在decode()反复的调用暴漏给子类实现的doDecode()方法。

具体执行过程如下所示：

A. 你的doDecode()方法返回true 时，CumulativeProtocolDecoder 的decode()方法会首先判断你是否在doDecode()方法中从内部的IoBuffer 缓冲区读取了数据，如果没有，则会抛出非法的状态异常，也就是你的doDecode()方法返回true 就表示你已经消费了本次数据（相当于聊天室中一个完整的消息已经读取完毕），进一步说，也就是此时你必须已经消费过内部的IoBuffer 缓冲区的数据（哪怕是消费了一个字节的数据）。如果验证过通过，那么CumulativeProtocolDecoder 会检查缓冲区内是否还有数据未读取，如果有就继续调用doDecode()方法，没有就停止对doDecode()方法的调用，直到有新的数据被缓冲。

B. 当你的doDecode()方法返回false 时，CumulativeProtocolDecoder 会停止对doDecode()方法的调用，但此时如果本次数据还有未读取完的，就将含有剩余数据的IoBuffer 缓冲区保存到IoSession 中，以便下一次数据到来时可以从IoSession 中提取合并。如果发现本次数据全都读取完毕，则清空IoBuffer 缓冲区。简而言之，当你认为读取到的数据已经够解码了，那么就返回true，否则就返回false。这个CumulativeProtocolDecoder 其实最重要的工作就是帮你完成了数据的累积，因为这个工作是很烦琐的。