实在无聊,考虑把当前应用的通讯模式由http移植为socket, 服务器这块因为对NIO并不熟悉,所以考虑使用现成的网络通讯框架进行移植,花了点时间测试比较流行的mina和xsocket。 == 相同点 == 1. 都对nio进行了有效屏蔽, 可以简化开发过程, 对于文本流模式的应用,两者都非常简单,实现一个基本的handle就可以 2. 提供了一些常见的辅助功能,比如日志等, mina支持更全面一些 3. 可以通过绑定各种附加属性实现基于会话的工作方式,会话控制都提供了完整的支持 4. 理论上都可以提供lowerlevel数据的处理支持, 不过实际操作, mina比较复杂,文档也缺失。 5. 都提供了客户端使用包,简化客户端开发 6. 都提供了jmx的集成支持,可以通过第三方工具来监控使用状况 == 差异 == 两
者设计的出发点不同, xsocket是一个轻量级的解决方案,核心思想是屏蔽,简化nio方式的的开发,并不需要过多的学习。
Mina的目的在我看来更多的是提供一个服务器开发的基础平台,相对来说提供的支持要全面,也复杂的多, 如果缺少对java nio框架的深入理解,
对mina的一些特性就难以利用。 对数据的处理,xsocket的出发点是通过提供对基本类型的支持来做到简单灵活的操作,
而mina则希望在更高的层面上即通过自定义的协议扩展来屏蔽掉应用对数据的处理操作,把核心放置到业务处理逻辑上。
做一个简单比较如下
- 自定义协议
* mina通过 encoder
和decoder模式来支持自定义的协议,目的是屏蔽底层数据的操作,对于客户端和服务器都是java的应用,处理比较简单。缺省提供了对文本,
java对象的处理。但是对于客户端是j2me或者其他语言的,这种模式就比较难以使用了。比如我当前的协议是以byte[]为基础的,mina就不能很
好的处理。 * xsocket并不关注这点, 关注的是对nio的屏蔽。 - 对filter模式的支持
* mina利用filter模式提供对数据流操作的封装和扩展,是核心模式。 另外也提供了一些缺省的有用filter,比如compress等 * xsocket不关注这个问题, 所以说mina更象应用服务器平台, xscoket是一个通讯模块 - 缺省对文本操作的支持
文本流模式是比较常见的网络应用模式,比如http , smtp服务,聊天应用等 * mina 通过增加一个!TextLineCodecFactory filter来提供对文本操作的支持, 传入的数据会被自动整理成文本信息。 但是并未提供额外的处理支持
String data = nbc.readStringByDelimiter("\r\n", "gbk"); //缺省提供delimiter的操作, System.out.println(data); //中文读取正常 nbc.write(data + "\r\n"); //回写是乱码 nbc.write(data + "\r\n", “gbk”); //正常
- 对流的操作
* mina提供一个streamiohandler的类, 可以使用基于流的方式进行处理操作,实际使用有点复杂,需要在一个独立的线程中工作,会增加服务器负担。 * xsocket 没仔细研究, 但是因为提供了对基本类型操作的支持,所以可以自行包装流来解决,比较简单。 - 对lowerlevel方式数据的处理
* mina需要熟悉nio框架部分的bytebuffer的操作 * xsocket可以直接支持以基本类型的模式进行操作, 也支持使用bytebuffer的方式,更加简单灵活 - 对fragment的处理 tcp网络的特性,即一次数据可能分为多个包发送, 也就是fragment
* mina对分包会直接报错, 需要使用会话控制的方式来对包进行组装处理,比较复杂。 另外从服务器向客户端写大包的时候, 1.1和2.0处理不同,2.0不做控制会直接报一个bytebuffer溢出的错误。 * xscoket缺省会吞掉这个错误,自动采用重试的方式尝试读取数据,对开发来说比较简单,另外也可以提供类似mina那样的安全处理模式,代码比mina要简单。 - 文档支持
* mina 比较多,但是语焉不详,问题要靠自己啃代码和上论坛 * xsocket 只有一篇文档, 但是比较详尽的介绍了所有需要的知识。另外,视乎, xsocket的代码质量要更好一些, mina更向是不断学习过程中不断完善改进的作品。 - 学习曲线
*mina 要较好的使用需要对nio有深入的了解, 一般使用学习难度不大 * xsocket 基本不用学习
== 结论 ==
我的应用是手机和服务器端通过自定义的二进制协议进行通讯,我需要的是一个轻量级的解决方案。
使用mina的自定义协议方式处理需要额外的工作量, 而mina对直接操作基本数据类型的支持并不好,或者说需要我深入的学习nio部分内容。
最终因为fragment和对lowerlevel数据的更简单的支持让我选择了xsocket,很轻松的完成了移植工作。 如果一开始设计通讯部分就接触mina的话,我可能会坚持使用mina的自定义协议方式来处理,但是就目前来说,他太复杂了,将来有时间,可以做为应用模式的学习对mina进行深入解剖。
== 其他 == 其他常见的java的通讯协议框架 qickeserver : 以文本流为模式的通讯框架 netty: mina的前身 cindy: 国人在接触netty之后开发的, 我接触时已经停止开发一年了,所以基本不予考虑。
== 补充 ==
下午无聊又玩了一下quick server。 1. quickserver 1.4.7 现在有提供对binary模式的支持,可以使用一个ClientBinaryHandle处理二进制流,不过处理稍显复杂,还要多开一个线程。对当前的应用来说xsocket已经足够了。 2. quickserver 在易用性和复杂程度方面在xsocket和mina之间, 架构上更倾向于解决较复杂的问题,和mina有很多相似处。 较复杂的数据处理也需要引入流和bytebuffer的概念。 3. quick的文档和例子都不错, 要明显比mina好, 有点不爽的是配置文件有点婆妈,考虑到我的一般应用都是要集成到服务器中使用的,觉得有点烦,不过基本可以放弃研究mina了。 4. quick 架构上handle的使用可以配置,产生类似mina那种filter的效果,还是蛮有意思的。 5. 另外还自己实现了一些婆婆妈妈的管理界面,有空看看完。 最后许可证协议只要使用binary的包,商用就没问题。
其实这3个框架都是以回调和组装为中心的设计,关注点有所不同而已。自己比较懒还是喜欢那种越简单越好的,看mina有点头疼。
(###)
|