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效率有所帮助。