Apache MINA学习(三)

使用 ProtocolCodecFilter

ProtocolCodecFilter 用来在字节流和消息对象之间互相转换。当该过滤器接收到字节流的时候，需要首先判断消息的边界，然后把表示一条消息的字节提取出来，通过一定的逻辑转换成消息对象，再把消息对象往后传递，交给 I/O 处理器来执行业务逻辑。这个过程称为“解码”。与“解码”对应的是“编码”过程。在“编码”的时候，过滤器接收到的是消息对象，通过与“解码”相反的逻辑，把消息对象转换成字节，并反向传递，交给 I/O 服务来执行 I/O 操作。

在“编码”和“解码”中的一个重要问题是如何在字节流中判断消息的边界。通常来说，有三种办法解决这个问题：

使用固定长度的消息。这种方式实现起来比较简单，只需要每次读取特定数量的字节即可。
使用固定长度的消息头来指明消息主体的长度。比如每个消息开始的 4 个字节的值表示了后面紧跟的消息主体的长度。只需要首先读取该长度，再读取指定数量的字节即可。
使用分隔符。消息之间通过特定模式的分隔符来分隔。每次只要遇到该模式的字节，就表示到了一个消息的末尾。
具体到示例应用来说，客户端和服务器之间的通信协议比较复杂，有不同种类的消息。每种消息的格式都不相同，同类消息的内容也不尽相同。因此，使用固定长度的消息头来指明消息主体的长度就成了最好的选择。

示例应用中的每种消息主体由两部分组成，第一部分是固定长度的消息类别名称，第二部分是每种消息的主体内容。图 4 中给出了示例应用中一条完整的消息的结构。


图 4. 示例应用中消息的结构

AbstractTetrisCommand用来描述联机游戏示例应用中的消息。它是一个抽象类，是所有具体消息的基类。其具体实现如 清单 5 所示。


清单 5. 联机游戏示例应用中的消息 AbstractTetrisCommand
public abstract class AbstractTetrisCommand implements TetrisCommand {
public abstract String getName();

public abstract byte[] bodyToBytes() throws Exception;

public abstract void bodyFromBytes(byte[] bytes) throws Exception;

public byte[] toBytes() throws Exception {
byte[] body = bodyToBytes();
int commandNameLength = Constants.COMMAND_NAME_LENGTH;
int len = commandNameLength + body.length;
byte[] bytes = new byte[len];
String name = StringUtils.rightPad(getName(), commandNameLength,
Constants.COMMAND_NAME_PAD_CHAR);
name = name.substring(0, commandNameLength);
System.arraycopy(name.getBytes(), 0, bytes, 0, commandNameLength);
System.arraycopy(body, 0, bytes, commandNameLength, body.length);
return bytes;
}
}

如 清单 5 所示，AbstractTetrisCommand 中定义了 3 个抽象方法：getName、bodyToBytes 和 bodyFromBytes，分别用来获取消息的名称、把消息的主体转换成字节数组和从字节数组中构建消息。bodyToBytes对应于前面提到的“编码”过程，而 bodyFromBytes对应于“解码”过程。每种具体的消息都应该实现这 3 个方法。AbstractTetrisCommand 中的方法 toBytes 封装了把消息的主体转换成字节数组的逻辑，在字节数组中，首先是长度固定为 Constants.COMMAND_NAME_LENGTH的消息类别名称，紧接着是每种消息特定的主体内容，由 bodyToBytes 方法来生成。

在介绍完示例应用中的消息格式之后，下面将讨论具体的“编码”和“解码”过程。“编码”过程由编码器来完成，编码器需要实现 org.apache.mina.filter.codec.ProtocolEncoder 接口，一般来说继承自 org.apache.mina.filter.codec.ProtocolEncoderAdapter 并覆写所需的方法即可。清单 6 中给出了示例应用中消息编码器 CommandEncoder 的实现。


清单 6. 联机游戏示例应用中消息编码器 CommandEncoder
public class CommandEncoder extends ProtocolEncoderAdapter {

public void encode(IoSession session, Object message,
ProtocolEncoderOutput out) throws Exception {
AbstractTetrisCommand command = (AbstractTetrisCommand) message;
byte[] bytes = command.toBytes();
IoBuffer buf = IoBuffer.allocate(bytes.length, false);

buf.setAutoExpand(true);
buf.putInt(bytes.length);
buf.put(bytes);

buf.flip();
out.write(buf);
}
}

在 清单 6 中，encode 方法封装了编码的逻辑。由于 AbstractTetrisCommand的 toBytes已经完成了到字节数组的转换，encode 方法直接使用即可。首先写入消息主体字节数组的长度，再是字节数组本身，就完成了编码的过程。

与编码过程相比，解码过程要相对复杂一些。具体的实现如 清单 7 所示。


清单 7. 联机游戏示例应用中消息解码器 CommandDecoder
public class CommandDecoder extends CumulativeProtocolDecoder {

protected boolean doDecode(IoSession session, IoBuffer in,
ProtocolDecoderOutput out) throws Exception {
if (in.prefixedDataAvailable(4, Constants.MAX_COMMAND_LENGTH)) {
int length = in.getInt();
byte[] bytes = new byte[length];
in.get(bytes);
int commandNameLength = Constants.COMMAND_NAME_LENGTH;
byte[] cmdNameBytes = new byte[commandNameLength];
System.arraycopy(bytes, 0, cmdNameBytes, 0, commandNameLength);
String cmdName = StringUtils.trim(new String(cmdNameBytes));
AbstractTetrisCommand command = TetrisCommandFactory
.newCommand(cmdName);
if (command != null) {
byte[] cmdBodyBytes = new byte[length - commandNameLength];
System.arraycopy(bytes, commandNameLength, cmdBodyBytes, 0,
length - commandNameLength);
command.bodyFromBytes(cmdBodyBytes);
out.write(command);
}
return true;
} else {
return false;
}
}
}

在 清单 7 中可以看到，解码器 CommandDecoder 继承自 CumulativeProtocolDecoder。这是 Apache MINA 提供的一个帮助类，它会自动缓存所有已经接收到的数据，直到编码器认为可以开始进行编码。这样在实现自己的编码器的时候，就只需要考虑如何判断消息的边界即可。如果一条消息的后续数据还没有接收到，CumulativeProtocolDecoder会自动进行缓存。在之前提到过，解码过程的一个重要问题是判断消息的边界。对于固定长度的消息来说，只需要使用 Apache MINA 的 IoBuffer的 remaining方法来判断当前缓存中的字节数目，如果大于消息长度的话，就进行解码；对于使用固定长度消息头来指明消息主体的长度的情况，IoBuffer提供了 prefixedDataAvailable方法来满足这一需求。prefixedDataAvailable会检查当前缓存中是否有固定长度的消息头，并且由此消息头指定长度的消息主体是否已经全部在缓存中。如果这两个条件都满足的话，说明一条完整的消息已经接收到，可以进行解码了。解码的过程本身并不复杂，首先读取消息的类别名称，然后通过 TetrisCommandFactory.newCommand方法来生成一个该类消息的实例，接着通过该实例的 bodyFromBytes方法就可以从字节数组中恢复消息的内容，得到一个完整的消息对象。每次成功解码一个消息对象，需要调用 ProtocolDecoderOutput的 write把此消息对象往后传递。消息对象会通过过滤器链，最终达到 I/O 处理器，在 IoHandler.messageReceived中接收到此消息对象。如果当前缓存的数据不足以用来解码一条消息的话，doDecode只需要返回 false即可。接收到新的数据之后，doDecode会被再次调用。

过滤器链

过滤器只有在添加到过滤器链中的时候才起作用。过滤器链是过滤器的容器。过滤器链与 I/O 会话是一一对应的关系。org.apache.mina.core.filterchain.IoFilterChain是 Apache MINA 中过滤器链的接口，其中提供了一系列方法对其中包含的过滤器进行操作，包括查询、添加、删除和替换等。如 表 5 所示。


表 5. IoFilterChain 接口的方法
方法 说明
addFirst(String name, IoFilter filter) 将指定名称的过滤器添加到过滤器链的开头。
addLast(String name, IoFilter filter) 将指定名称的过滤器添加到过滤器链的末尾。
contains(String name) 判断过滤器链中是否包含指定名称的过滤器。
get(String name) 从过滤器链中获取指定名称的过滤器。
remove(String name) 从过滤器链中删除指定名称的过滤器。
replace(String name, IoFilter newFilter) 用过滤器 newFilter替换掉过滤器链中名为 name的过滤器。
getSession() 获取与过滤器链一一对应的 I/O 会话。
在介绍完 I/O 过滤器和过滤器链之后，下面介绍 I/O 处理器。


回页首

I/O 处理器

I/O 事件通过过滤器链之后会到达 I/O 处理器。I/O 处理器中与 I/O 事件对应的方法会被调用。Apache MINA 中 org.apache.mina.core.service.IoHandler是 I/O 处理器要实现的接口，一般情况下，只需要继承自 org.apache.mina.core.service.IoHandlerAdapter并覆写所需方法即可。IoHandler接口的方法如 表 6 所示。


表 6. IoHandler 接口的方法
方法 说明
sessionCreated(IoSession session) 当有新的连接建立的时候，该方法被调用。
sessionOpened(IoSession session) 当有新的连接打开的时候，该方法被调用。该方法在 sessionCreated之后被调用。
sessionClosed(IoSession session) 当连接被关闭的时候，此方法被调用。
sessionIdle(IoSession session, IdleStatus status) 当连接变成闲置状态的时候，此方法被调用。
exceptionCaught(IoSession session, Throwable cause) 当 I/O 处理器的实现或是 Apache MINA 中有异常抛出的时候，此方法被调用。
messageReceived(IoSession session, Object message) 当接收到新的消息的时候，此方法被调用。
messageSent(IoSession session, Object message) 当消息被成功发送出去的时候，此方法被调用。
对于 表 6 中的方法，有几个需要重点的说明一下。首先是 sessionCreated 和 sessionOpened 的区别。sessionCreated方法是由 I/O 处理线程来调用的，而 sessionOpened 是由其它线程来调用的。因此从性能方面考虑，不要在 sessionCreated 方法中执行过多的操作。对于 sessionIdle，默认情况下，闲置时间设置是禁用的，也就是说 sessionIdle 并不会被调用。可以通过 IoSessionConfig.setIdleTime(IdleStatus, int) 来进行设置。

Apache MINA 中的基本概念已经介绍完了，下面介绍状态机的使用。