apache mina 2 .

mancha

　　1 介绍
　　Apache MINA 是一个网络应用程序框架，它对Java中的socket和NIO进行了有效和清晰的封装，方便开发人员开发TCP/UDP程序，从而抛开在使用原始的socket时需要考虑的各种繁杂而又烦人问题（线程、性能、会话等），把更多精力专著在应用中的业务逻辑的开发上。
　　
　　2 模型 原理 http://www.ibm.com/developerworks/cn/java/j-lo-mina2/
　　
　　基于 Apache MINA 的网络应用有三个层次，分别是 I/O 服务、I/O 过滤器和 I/O 处理器：

• I/O 服务：I/O 服务用来执行实际的 I/O 操作。Apache MINA 已经提供了一系列支持不同协议的 I/O 服务，如 TCP/IP、UDP/IP、串口和虚拟机内部的管道等。开发人员也可以实现自己的 I/O 服务。
  
• I/O 过滤器：I/O 服务能够传输的是字节流，而上层应用需要的是特定的对象与数据结构。I/O 过滤器用来完成这两者之间的转换。I/O 过滤器的另外一个重要作用是对输入输出的数据进行处理，满足横切的需求。多个 I/O 过滤器串联起来，形成 I/O 过滤器链。
  
• I/O 处理器：I/O 处理器用来执行具体的业务逻辑。对接收到的消息执行特定的处理。
  

　　I/O 服务用来执行真正的 I/O 操作，以及管理 I/O 会话。根据所使用的数据传输方式的不同，有不同的 I/O 服务的实现。由于 I/O 服务执行的是输入和输出两种操作，实际上有两种具体的子类型。一种称为“I/O 接受器（I/O acceptor）”，用来接受连接，一般用在服务器的实现中；另外一种称为“I/O 连接器（I/O connector）”，用来发起连接，一般用在客户端的实现中。对应在 Apache MINA 中的实现，org.apache.mina.core.service.IoService是I/O 服务的接口，而继承自它的接口 org.apache.mina.core.service.IoAcceptor和 org.apache.mina.core.service.IoConnector 则分别表示 I/O 接受器和 I/O 连接器。
　　
　　I/O 会话表示一个活动的网络连接，与所使用的传输方式无关。I/O 会话可以用来存储用户自定义的与应用相关的属性。这些属性通常用来保存应用的状态信息，还可以用来在 I/O 过滤器和 I/O 处理器之间交换数据。I/O 会话在作用上类似于 Servlet 规范中的 HTTP 会话。
　　Apache MINA 中 I/O 会话实现的接口是org.apache.mina.core.session.IoSession
　　
　　从 I/O 服务发送过来的所有 I/O 事件和请求，在到达 I/O 处理器之前，会先由 I/O 过滤器链中的 I/O 过滤器进行处理。Apache MINA 中的过滤器与 Servlet 规范中的过滤器是类似的。过滤器可以在很多情况下使用，比如记录日志、性能分析、访问控制、负载均衡和消息转换等。Apache MINA 中 I/O 过滤器都实现org.apache.mina.core.filterchain.IoFilter接口。一般来说，不需要完整实现 IOFilter接口，只需要继承 Apache MINA 提供的适配器org.apache.mina.core.filterchain.IoFilterAdapter，并覆写所需的事件过滤方法即可，其它方法的默认实现是不做任何处理，而直接把事件转发到下一个过滤器。
　　
　　I/O 事件通过过滤器链之后会到达 I/O 处理器。I/O 处理器中与 I/O 事件对应的方法会被调用。Apache MINA 中org.apache.mina.core.service.IoHandler是 I/O 处理器要实现的接口，一般情况下，只需要继承自org.apache.mina.core.service.IoHandlerAdapter并覆写所需方法即可。
　　
　　
　　从 I/O 服务发送过来的所有 I/O 事件和请求，在到达 I/O 处理器之前，会先由 I/O 过滤器链中的 I/O 过滤器进行处理。Apache MINA 中的过滤器与 Servlet 规范中的过滤器是类似的。过滤器可以在很多情况下使用，比如记录日志、性能分析、访问控制、负载均衡和消息转换等。过滤器非常适合满足网络应用中各种横切的非功能性需求。在一个基于 Apache MINA 的网络应用中，一般存在多个过滤器。这些过滤器互相串联，形成链条，称为过滤器链。每个过滤器依次对传入的I/O 事件进行处理。当前过滤器完成处理之后，由过滤器链中的下一个过滤器继续处理。当前过滤器也可以不调用下一个过滤器，而提前结束，这样 I/O 事件就不会继续往后传递。比如负责用户认证的过滤器，如果遇到未认证的对等体发出的 I/O 事件，则会直接关闭连接。这可以保证这些事件不会通过此过滤器到达 I/O 处理器。
　　Apache MINA 中 I/O 过滤器都实现 org.apache.mina.core.filterchain.IoFilter接口。一般来说，不需要完整实现IOFilter接口，只需要继承 Apache MINA 提供的适配器 org.apache.mina.core.filterchain.IoFilterAdapter，并覆写所需的事件过滤方法即可，其它方法的默认实现是不做任何处理，而直接把事件转发到下一个过滤器。
　　
　　
　　
　　3异步传输方式 http://littcai.iyunv.com/blog/322442
　　异步 I/O 模型大体上可以分为两种，反应式（ Reactive ）模型和前摄式（ Proactive ）模型：
传统的 select / epoll / kqueue 模型，以及 Java NIO 模型，都是典型的反应式模型，即应用代码对 I/O 描述符进行注册，然后等待 I/O 事件。当某个或某些 I/O 描述符所对应的 I/O 设备上产生 I/O 事件（可读、可写、异常等）时，系统将发出通知，于是应用便有机会进行 I/O 操作并避免阻塞。由于在反应式模型中应用代码需要根据相应的事件类型采取不同的动作，最常见的结构便是嵌套的if {...} else {...} 或 switch ，并常常需要结合状态机来完成复杂的逻辑。
前摄式模型则恰恰相反。在前摄式模型中，应用代码主动地投递异步操作而不管 I/O 设备当前是否可读或可写。投递的异步 I/O 操作被系统接管，应用代码也并不阻塞在该操作上，而是指定一个回调函数并继续自己的应用逻辑。当该异步操作完成时，系统将发起通知并调用应用代码指定的回调函数。在前摄式模型中，程序逻辑由各个回调函数串联起来：异步操作 A 的回调发起异步操作 B ，B 的回调再发起异步操作 C ，以此往复。
　　Reactor 和 Proactor 同为事件驱动 I/O 模型，其本质区别在于事件触发时机： Reactor 在 I/O 设备就绪，即可以立即执行 I/O 调用而无需阻塞时触发，只有这时才可以放心大胆的执行 I/O 调用；而 Proactor 则允许在任意时刻发起 I/O 调用请求，并在 I/O 调用完成时触发事件。
　　Proactor 可以直接利用系统提供的 aio 、 IOCP 等异步 I/O 机制实现。不过鉴于一时之间各种平台上 aio 接口实现的兼容性、功能、性能等方面的表现都还比较不靠谱，常见平台里还是 Win32 IOCP 对 Proactor 的原生支持最好。当系统不提供原生的异步 I/O 机制时，也可以使用 Reactor 模拟实现。相关内容可参见这篇文章。MINA 正是借由 Java NIO 的 Reactor 实现的模拟 Proactor 模型。 Boost.Asio 的 Proactor 内核在非 NT Win32 平台上也是利用select() / kqueue() / epoll 等 Reactor 模拟实现的。
　　Reactor 按照事件触发方式又可分为 level-triggered (LT) 和 edge-triggered (ET) 两种，其区别详见epoll 的 man page 。传统的select() / poll() 都属于 LT Reactor ； kqueue() 则是 ET Reactor ；epoll 是个两面派， LT/ET 语义通吃。
前摄式模型相较于反射式模型往往更加难以编程。然而在具有原生异步 I/O 支持的操作系统中（例如支持 IO Completion Port 的 Win32 系统），采用前摄式模型往往可以取得比反应式模型更佳的效率。在没有原生异步 I/O 支持的系统中，也可以使用传统的反应式 API 对前摄式模型予以模拟。在现代的软硬件系统中，使用 epoll 和 kqueue 的前摄式模型实现同样可以轻松解决C10K 问题。前摄式模型的一个显著优势是在实现复杂逻辑的时候不需要借助于状态机。因为状态机已经隐含在由回调串联起来的异步操作链当中了。如果上述内容难以理解，可以参考Boost.Asio ，这是一个相当优秀的跨平台 C++ 前摄式 I/O 模型实现。

4 相关框架 http://littcai.iyunv.com/blog/267085
Java通讯框架，有时也被称为网络服务器，其实就是封装IO操作，并提供更高级的API接口。目前比较流行的框架就是：MINA、Cindy、QuickServer等。
Mina和Cindy使用了nio，而QuickServer则同时支持blockingIO和nio.
QuickServer doesn't support UDP at all. (MINA does)
QuickServer doesn't support client-side API at all. (MINA does)
Cindy2.x比MINA性能好是可以预见的，原因在于MINA提供的ByteBuffer和FilterChain。