實(shí)在無(wú)聊,考慮把當(dāng)前應(yīng)用的通訊模式由http移植為socket, 服務(wù)器這塊因?yàn)閷?duì)NIO并不熟悉,所以考慮使用現(xiàn)成的網(wǎng)絡(luò)通訊框架進(jìn)行移植,花了點(diǎn)時(shí)間測(cè)試比較流行的mina和xsocket。
== 相同點(diǎn) ==
  1. 都對(duì)nio進(jìn)行了有效屏蔽, 可以簡(jiǎn)化開(kāi)發(fā)過(guò)程, 對(duì)于文本流模式的應(yīng)用,兩者都非常簡(jiǎn)單,實(shí)現(xiàn)一個(gè)基本的handle就可以
  2. 提供了一些常見(jiàn)的輔助功能,比如日志等, mina支持更全面一些
  3. 可以通過(guò)綁定各種附加屬性實(shí)現(xiàn)基于會(huì)話的工作方式,會(huì)話控制都提供了完整的支持
  4. 理論上都可以提供lowerlevel數(shù)據(jù)的處理支持, 不過(guò)實(shí)際操作, mina比較復(fù)雜,文檔也缺失。
  5. 都提供了客戶端使用包,簡(jiǎn)化客戶端開(kāi)發(fā)
  6. 都提供了jmx的集成支持,可以通過(guò)第三方工具來(lái)監(jiān)控使用狀況
== 差異 ==
  兩者設(shè)計(jì)的出發(fā)點(diǎn)不同, xsocket是一個(gè)輕量級(jí)的解決方案,核心思想是屏蔽,簡(jiǎn)化nio方式的的開(kāi)發(fā),并不需要過(guò)多的學(xué)習(xí)。 Mina的目的在我看來(lái)更多的是提供一個(gè)服務(wù)器開(kāi)發(fā)的基礎(chǔ)平臺(tái),相對(duì)來(lái)說(shuō)提供的支持要全面,也復(fù)雜的多, 如果缺少對(duì)java nio框架的深入理解, 對(duì)mina的一些特性就難以利用。 對(duì)數(shù)據(jù)的處理,xsocket的出發(fā)點(diǎn)是通過(guò)提供對(duì)基本類(lèi)型的支持來(lái)做到簡(jiǎn)單靈活的操作, 而mina則希望在更高的層面上即通過(guò)自定義的協(xié)議擴(kuò)展來(lái)屏蔽掉應(yīng)用對(duì)數(shù)據(jù)的處理操作,把核心放置到業(yè)務(wù)處理邏輯上。

  做一個(gè)簡(jiǎn)單比較如下

  •    自定義協(xié)議
            * mina通過(guò) encoder 和decoder模式來(lái)支持自定義的協(xié)議,目的是屏蔽底層數(shù)據(jù)的操作,對(duì)于客戶端和服務(wù)器都是java的應(yīng)用,處理比較簡(jiǎn)單。缺省提供了對(duì)文本, java對(duì)象的處理。但是對(duì)于客戶端是j2me或者其他語(yǔ)言的,這種模式就比較難以使用了。比如我當(dāng)前的協(xié)議是以byte[]為基礎(chǔ)的,mina就不能很好的處理。
            * xsocket并不關(guān)注這點(diǎn), 關(guān)注的是對(duì)nio的屏蔽。
      
  • 對(duì)filter模式的支持
            * mina利用filter模式提供對(duì)數(shù)據(jù)流操作的封裝和擴(kuò)展,是核心模式。 另外也提供了一些缺省的有用filter,比如compress等
            * xsocket不關(guān)注這個(gè)問(wèn)題, 所以說(shuō)mina更象應(yīng)用服務(wù)器平臺(tái), xscoket是一個(gè)通訊模塊
  • 缺省對(duì)文本操作的支持
            文本流模式是比較常見(jiàn)的網(wǎng)絡(luò)應(yīng)用模式,比如http , smtp服務(wù),聊天應(yīng)用等
            * mina 通過(guò)增加一個(gè)!TextLineCodecFactory filter來(lái)提供對(duì)文本操作的支持, 傳入的數(shù)據(jù)會(huì)被自動(dòng)整理成文本信息。 但是并未提供額外的處理支持
  chain.addLast("codec"new ProtocolCodecFilter(
                
new TextLineCodecFactory()));


   
public void messageReceived(IoSession session, Object message) {
        Logger log 
= LoggerFactory.getLogger(ChatProtocolHandler.class);
        log.info(
"received: " + message);
        String theMessage 
= (String) message;
        String[] result 
= theMessage.split(" "2);  //自己分析文本段落
    

        * xscoket把對(duì)文本的支持做為基本屬性,并且提供了Delimiter這樣的支持,相比mina要好用一些。而對(duì)于解析http中mulitpart這樣的文本二進(jìn)制混合的結(jié)構(gòu),顯然要比mina 好使。
 

 String data = nbc.readStringByDelimiter("\r\n""gbk"); //缺省提供delimiter的操作,
      System.out.println(data);  //中文讀取正常
       nbc.write(data + "\r\n");  //回寫(xiě)是亂碼
       nbc.write(data + "\r\n", “gbk”);  //正常

 

  • 對(duì)流的操作
            * mina提供一個(gè)streamiohandler的類(lèi), 可以使用基于流的方式進(jìn)行處理操作,實(shí)際使用有點(diǎn)復(fù)雜,需要在一個(gè)獨(dú)立的線程中工作,會(huì)增加服務(wù)器負(fù)擔(dān)。
            * xsocket 沒(méi)仔細(xì)研究, 但是因?yàn)樘峁┝藢?duì)基本類(lèi)型操作的支持,所以可以自行包裝流來(lái)解決,比較簡(jiǎn)單。
  • 對(duì)lowerlevel方式數(shù)據(jù)的處理
            * mina需要熟悉nio框架部分的bytebuffer的操作
            * xsocket可以直接支持以基本類(lèi)型的模式進(jìn)行操作, 也支持使用bytebuffer的方式,更加簡(jiǎn)單靈活
  • 對(duì)fragment的處理 tcp網(wǎng)絡(luò)的特性,即一次數(shù)據(jù)可能分為多個(gè)包發(fā)送, 也就是fragment
            * mina對(duì)分包會(huì)直接報(bào)錯(cuò), 需要使用會(huì)話控制的方式來(lái)對(duì)包進(jìn)行組裝處理,比較復(fù)雜。 另外從服務(wù)器向客戶端寫(xiě)大包的時(shí)候, 1.1和2.0處理不同,2.0不做控制會(huì)直接報(bào)一個(gè)bytebuffer溢出的錯(cuò)誤。
            * xscoket缺省會(huì)吞掉這個(gè)錯(cuò)誤,自動(dòng)采用重試的方式嘗試讀取數(shù)據(jù),對(duì)開(kāi)發(fā)來(lái)說(shuō)比較簡(jiǎn)單,另外也可以提供類(lèi)似mina那樣的安全處理模式,代碼比mina要簡(jiǎn)單。
  • 文檔支持
           * mina 比較多,但是語(yǔ)焉不詳,問(wèn)題要靠自己啃代碼和上論壇
           * xsocket 只有一篇文檔, 但是比較詳盡的介紹了所有需要的知識(shí)。另外,視乎, xsocket的代碼質(zhì)量要更好一些, mina更向是不斷學(xué)習(xí)過(guò)程中不斷完善改進(jìn)的作品。
  • 學(xué)習(xí)曲線

                *mina 要較好的使用需要對(duì)nio有深入的了解, 一般使用學(xué)習(xí)難度不大
                * xsocket 基本不用學(xué)習(xí) 

== 結(jié)論 ==

   我的應(yīng)用是手機(jī)和服務(wù)器端通過(guò)自定義的二進(jìn)制協(xié)議進(jìn)行通訊,我需要的是一個(gè)輕量級(jí)的解決方案。
   使用mina的自定義協(xié)議方式處理需要額外的工作量, 而mina對(duì)直接操作基本數(shù)據(jù)類(lèi)型的支持并不好,或者說(shuō)需要我深入的學(xué)習(xí)nio部分內(nèi)容。  最終因?yàn)閒ragment和對(duì)lowerlevel數(shù)據(jù)的更簡(jiǎn)單的支持讓我選擇了xsocket,很輕松的完成了移植工作。
   如果一開(kāi)始設(shè)計(jì)通訊部分就接觸mina的話,我可能會(huì)堅(jiān)持使用mina的自定義協(xié)議方式來(lái)處理,但是就目前來(lái)說(shuō),他太復(fù)雜了,將來(lái)有時(shí)間,可以做為應(yīng)用模式的學(xué)習(xí)對(duì)mina進(jìn)行深入解剖。

== 其他 ==
   其他常見(jiàn)的java的通訊協(xié)議框架
   qickeserver : 以文本流為模式的通訊框架
   netty: mina的前身
   cindy: 國(guó)人在接觸netty之后開(kāi)發(fā)的, 我接觸時(shí)已經(jīng)停止開(kāi)發(fā)一年了,所以基本不予考慮。

 == 補(bǔ)充 ==

下午無(wú)聊又玩了一下quick server。
   1. quickserver 1.4.7 現(xiàn)在有提供對(duì)binary模式的支持,可以使用一個(gè)ClientBinaryHandle處理二進(jìn)制流,不過(guò)處理稍顯復(fù)雜,還要多開(kāi)一個(gè)線程。對(duì)當(dāng)前的應(yīng)用來(lái)說(shuō)xsocket已經(jīng)足夠了。
   2. quickserver 在易用性和復(fù)雜程度方面在xsocket和mina之間, 架構(gòu)上更傾向于解決較復(fù)雜的問(wèn)題,和mina有很多相似處。
較復(fù)雜的數(shù)據(jù)處理也需要引入流和bytebuffer的概念。
   3. quick的文檔和例子都不錯(cuò), 要明顯比mina好, 有點(diǎn)不爽的是配置文件有點(diǎn)婆媽?zhuān)紤]到我的一般應(yīng)用都是要集成到服務(wù)器中使用的,覺(jué)得有點(diǎn)煩,不過(guò)基本可以放棄研究mina了。
   4. quick 架構(gòu)上handle的使用可以配置,產(chǎn)生類(lèi)似mina那種filter的效果,還是蠻有意思的。
   5. 另外還自己實(shí)現(xiàn)了一些婆婆媽媽的管理界面,有空看看完。
最后許可證協(xié)議只要使用binary的包,商用就沒(méi)問(wèn)題。

其實(shí)這3個(gè)框架都是以回調(diào)和組裝為中心的設(shè)計(jì),關(guān)注點(diǎn)有所不同而已。自己比較懶還是喜歡那種越簡(jiǎn)單越好的,看mina有點(diǎn)頭疼。