mina编码器详解.pdf

mina 编码器详解 本指南尝试解释为什么和怎样使用 ProtocolCodecFilter。 为什么要使用 ProtocolCodecFilter 呢？ . TCP 保证包传输的正确有序。但并不保证发送端的一个写操作触发接收端一个 读事件。 参考 /wiki/IPv4#Fragmentation_and_reassembly 和 /wiki/Nagle%27s_algorithm MINA 术语：若没有 ProtocolCodecFilter，发送端调用 IoSession.write(Object message)可能触发接收端多个messageReceived(IoSession session, Object message) 事件的发生；多次调用 IoSession.write(Object message)也可能仅仅触发一个 messageReceived(IoSession session, Object message)事件。当客户端和服务端运行 在同一台主机上(或一个本地网络)时可能遇不到这种现象，除非应用程序能够应 付这种现象。 . 大多数网络应用程序需要一种方法去找出当前消息的结尾和下一条消息的开 始在哪里。 . 可以在 IoHandler 中实现所有这些逻辑，但添加 ProtocolCodecFilter 可以使代码 更清晰，更容易维护。 这样做可以分离协议逻辑和事务逻辑(IoHandler)。 怎样使用 ProtocolCodecFilter 呢？ 应用程序基本上就是接收一串字节并且将这串字节转化为消息(较高级别的对象)。 有三种常用方法可以将字节流分离成消息： . 使用固定长度的消息。 . 使用固定长度的标头指出消息内容主体的长度。 . 使用分隔符；例如很多基于文本的消息在消息的后面追加换行(或者 CR LF 组合) (/rfcs/rfc977.html) 在本指南中，使用的是第一种和第二种方法，因为它们肯定更容易实现。之后我 们将着眼于使用分隔符。 案例 我们将开发一个图形字符发生器服务(好看但没什么用)用来阐明如何实现自己的 协议代码转换(ProtocolEncoder, ProtocolDecoder, and ProtocolCodecFactory)。 这个协议真的很简单，下面是一个请求消息的布局： ------------------------------- 4 bytes 4 bytes 4 bytes --------- --------- ----------- width height numchars ------------------------------- width: 请求图片的宽度(网络字节顺序中的整数) height: 请求图片的高度(网络字节顺序中的整数) numchars: 要产生的字符数(网络字节顺序中的整数) 服务端响应两张请求尺寸且上面画有请求字符数的图片。下面是一个响应消息的 布局： ------------------------------------------------------------------------ 4 bytes variable length body 4 bytes variable length body --------- -------------------------- --------- -------------------------- length1 image1 length2 image2 ------------------------------------------------------------------------ length1: image1 占用的字节数 image1: 一张 PNG 格式的图片 length2: image2 占用的字节数 image2: 一张 PNG 格式的图片 概述一下我们需要的编解码请求和响应类： . ImageRequest：一个简单 POJO，表示向服务端的请求。 . ImageRequestEncoder：将请求对象编码成特定协议的数据(客