JAVA 通讯框架

循证架构之QuickServer篇

作者：LeonW

“循证架构”一词虽是新创，但也可算是新瓶装老酒了。Rod用之来循证Spring等轻量级框架之优势、EJB之劣势。

前一段做了个GPRS服务器的系统，也尝试了把“循证架构”的循证思路。竟然要循证，总得先列举下需求：

首先，服务器必须与GPRS发送设备进行通讯， 数据的接收、发送、检查链路状态等基本功能，还需要具体分析包文，组包等业务功能的处理。其次，工期很紧，风险分析中列为第一大风险。再者，服务器的稳定性、可靠性也是一大重点。最后，需要提供对服务器管理的接口。

手头也有些较为成熟的网络通讯的基础代码，拿来复用解决1，3问题也非难事，倒是4需要进行开发。不过早就听闻 Mina、Cindy等大名（下载Mina代码过程中反倒发现本文的主角QuickServer），于是就对这几个框架循证了一遍，寻找合适开发的网络通 讯框架。

从功能上看，Mina、Cindy、QuickServer实现的功能也基本差不多，都是封装基本的网络IO操作，暴露事件接口供二次开发。

Mina需要继承IOHandlerAdapter类或ProtocolHandlerAdapter类，从该类中继承各事件方法实现业务操作。 Cindy也需要继承SessionHandlerAdapter具体类，跟Mina类似。QuickServer则需要实现接口 ClientEventHandler实现业务功能。这些类和接口提供的事件大致雷同：Connected，Closed，Received，Sent， Timeout等等。

Mina和Cindy使用了nio，而QuickServer则同时支持blockingIO和nio，需要进行配置选择（一个遗憾就 是QuickServer的nio模式下竟然不支持Timeout事件）。Mina实现中有一个很好的设计就是剥离IO层和Protocol层，作者的用 意是想在IO层实现对IO的处理，在Protocol实现对业务的处理，很好的一个分层思想。QuickServer则是一个大杂烩，把各种IO处理封装 在 BasicClientHandler中，里面还混杂了blockingIO、NIO等操作。

额外功能上，Mina和Cindy都可以 支持一个进程中开启多个服务端口进行不同处理，而QuickServer则不行。不过QuickServer提供了另外一个非常实用的功能-管理服务端 口，通过其设定的一些指令查询服务器的状态、控制服务器等。此功能成为最后选择的最大优势。其他例如IP过滤的功能在QuickServer中只需要进行 配置即可。

这次没对这三个服务器在性能上进行比较。以后再找机会完成:-)

从代码质量上来看，无疑Mina和Cindy占了 上风，QuickServer的分层实在不咋样。Mina和Cindy有不少相似的地方。而QuickServer的目的与其有所不同，集成许多方便的功 能，甚至还加入数据库连接池的功能（感觉作者有点无聊了）。最后的循证其实还是选了个最实用的工具，的确减少不少的工作量。此后还遇到一些二进制的问题就 不表了。


MINA is a good framwork

作者：fisher

Netty2的作者TrustinLee在为Apache LDAP项目所作的通讯基础框架MINA中显示了在通讯框架方面雄厚的实力，MINA是迄今为止我见过在java领域最好的通讯基础件，看得出，他通过Netty2的经验积累加上对ACE等传统大型框架的理解之后，在制作MINA的一开始就确定了一个近似于完美的架构，同时，我在RoadMap中看到MINA与Spring、JMX和OSGI的结合计划，虽然不知道什么时候能够完成，但光看这个RoadMap已经很让人激动了。

在MINA的服务绑定上，一开始就使用了serviceRegistry类这种中控型的注册绑定方式，看得出他对OSGI有一定研究并已决意向其靠拢。

而借鉴于ACE的Accepter和Connector结构使得Session的使用更加方便，同时分为IO层和Protocol两层的通讯基础件也是使得使用变得很方便。

最后要提一下的是作者使用的FilterChain式结构来加载Filter，使得很多非通讯核心问题得以从基础件中剥离出来，甚至连线程池模式都可以使用Filter来指定，虽然自己制作的线程池要想结合到MINA中需要一些额外的努力，但是仍然极大的增加了框架的灵活性。


MINA vs. QuickServer

作者：fisher

First for all, QuickServer is licensed as LGPL, and MINA as ASL.

从我个人角度而言，去年看过QuickServer的源码，我在项目中采用的每一个框架或类库都会做综合评价，通常不会是一个原因导致我采用或没有采用某个库或框架，具体最后没有采用QuickServer的原因忘记了，但是当时给我的总体感觉是，QuickServer虽然很方便，但不会让我在架构上得到新的好处。而它最大的优点则是，支持JDK1.3（如果没记错的话），另外就是License的问题

下面看一看来自TrusinLee的评论：

Thank for the information about another network application framework. I found a few differences:

Ø QuickServer supports blocking mode. (MINA supports only non-blocking mode, but you can make your operation block at your will.)

Ø QuickServer provides GUI-based admin. (MINA doesn't have one yet, but will have full JMX support soon, which is a standard.)

Ø QuickServer uses java.util.logging. (MINA uses SLF4J, which is a safe replacement of commons-logging.)

Ø QuickServer uses its own XML settings. (MINA provides Spring framework integration instead.)

Ø QuickServer can specify maximum number of clients allowed. (MINA can do this using a filter, but not implemented by default. Of course, this will be implemented as an overload prevention filter.)

Ø QuickServer team has one crew. (MINA has three crews.)

Ø QuickServer project started in 2003. (MINA started in 2005.)

Ø QuickServer has a difference event handler interface from MINA. (You'll have to compare it by yourself. IMHO, MINA has one simple enough handler which covers all QuickServer provides.)

Ø QuickServer doesn't support UDP at all. (MINA does)

Ø QuickServer doesn't support client-side API at all. (MINA does)

Ø QuickServer integrated authentication and text protocol in its core. (MINA didn't and they are considered as a cross-cutting concern that a filter should take care of. IMHO, MINA is more extensible here.)


Cindy2.x比MINA性能好是可以预见的，原因在于MINA提供的ByteBuffer和FilterChain。

Cindy3.x源代码我没有看，所以不好评价。

关于MINA的效率问题，在MINA的maillist中也被提出，似乎有相应的issue正要被加入到它的Issue Tracker中。

Cindy3.x才刚刚开始，我认为多给Crmky一些时间，他一定可以将架构设计的更好。

MINA在设计上也有少许问题，他的IoFilterChain将FilterManager和FilterChain合而为一，在看其代码的时候会觉得很乱。另外，为了保证包的顺序，一个IoSession上的Handler在上一次read调用没有返回前，是不会被再次调用的。我认为MINA的基础架构在1.0和1.1版本之间还会变化，以适应新加入的configuration方式。另外，MINA会产生一些内存垃圾，我用profiler检查过MINA，似乎是SocketIoProcessor中的某个计数器在不停的产生2byte的什么东东（记不太情了），不过似乎Trustin也注意到这个问题了，最近他说会在1.0release之后改善效率和内存的问题。

你可以到Crmky的blog上发帖子，看看他是否愿意提供一个Cindy3.X和MINA的对比。

总体来说，java的通讯框架设计并不特别注重效率，而追求架构上的优雅，当然，这也和java中本来能够进行效率调优的手段就不多有关系，如果真要优化，可能还是需要使用JDK5.0以上提供的高效的内存操作，另外，据说在Linxu2.6内核以后，Mustang的NIO使用了Linux的epoll来实现select()，也许会对目前的IO效率有所帮助。