實在無聊,考慮把當前應(yīng)用的通訊模式由http移植為socket, 服務(wù)器這塊因為對NIO并不熟悉,所以考慮使用現(xiàn)成的網(wǎng)絡(luò)通訊框架進行移植,花了點時間測試比較流行的mina和xsocket。
== 相同點 ==
1. 都對nio進行了有效屏蔽, 可以簡化開發(fā)過程, 對于文本流模式的應(yīng)用,兩者都非常簡單,實現(xiàn)一個基本的handle就可以
2. 提供了一些常見的輔助功能,比如日志等, mina支持更全面一些
3. 可以通過綁定各種附加屬性實現(xiàn)基于會話的工作方式,會話控制都提供了完整的支持
4. 理論上都可以提供lowerlevel數(shù)據(jù)的處理支持, 不過實際操作, mina比較復(fù)雜,文檔也缺失。
5. 都提供了客戶端使用包,簡化客戶端開發(fā)
6. 都提供了jmx的集成支持,可以通過第三方工具來監(jiān)控使用狀況
== 差異 ==
兩者設(shè)計的出發(fā)點不同, xsocket是一個輕量級的解決方案,核心思想是屏蔽,簡化nio方式的的開發(fā),并不需要過多的學習。 Mina的目的在我看來更多的是提供一個服務(wù)器開發(fā)的基礎(chǔ)平臺,相對來說提供的支持要全面,也復(fù)雜的多, 如果缺少對java nio框架的深入理解, 對mina的一些特性就難以利用。 對數(shù)據(jù)的處理,xsocket的出發(fā)點是通過提供對基本類型的支持來做到簡單靈活的操作, 而mina則希望在更高的層面上即通過自定義的協(xié)議擴展來屏蔽掉應(yīng)用對數(shù)據(jù)的處理操作,把核心放置到業(yè)務(wù)處理邏輯上。
做一個簡單比較如下
- 自定義協(xié)議
* mina通過 encoder 和decoder模式來支持自定義的協(xié)議,目的是屏蔽底層數(shù)據(jù)的操作,對于客戶端和服務(wù)器都是java的應(yīng)用,處理比較簡單。缺省提供了對文本, java對象的處理。但是對于客戶端是j2me或者其他語言的,這種模式就比較難以使用了。比如我當前的協(xié)議是以byte[]為基礎(chǔ)的,mina就不能很好的處理。
* xsocket并不關(guān)注這點, 關(guān)注的是對nio的屏蔽。
- 對filter模式的支持
* mina利用filter模式提供對數(shù)據(jù)流操作的封裝和擴展,是核心模式。 另外也提供了一些缺省的有用filter,比如compress等
* xsocket不關(guān)注這個問題, 所以說mina更象應(yīng)用服務(wù)器平臺, xscoket是一個通訊模塊 - 缺省對文本操作的支持
文本流模式是比較常見的網(wǎng)絡(luò)應(yīng)用模式,比如http , smtp服務(wù),聊天應(yīng)用等
* mina 通過增加一個!TextLineCodecFactory filter來提供對文本操作的支持, 傳入的數(shù)據(jù)會被自動整理成文本信息。 但是并未提供額外的處理支持
















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





- 對流的操作
* mina提供一個streamiohandler的類, 可以使用基于流的方式進行處理操作,實際使用有點復(fù)雜,需要在一個獨立的線程中工作,會增加服務(wù)器負擔。
* xsocket 沒仔細研究, 但是因為提供了對基本類型操作的支持,所以可以自行包裝流來解決,比較簡單。 - 對lowerlevel方式數(shù)據(jù)的處理
* mina需要熟悉nio框架部分的bytebuffer的操作
* xsocket可以直接支持以基本類型的模式進行操作, 也支持使用bytebuffer的方式,更加簡單靈活 - 對fragment的處理 tcp網(wǎng)絡(luò)的特性,即一次數(shù)據(jù)可能分為多個包發(fā)送, 也就是fragment
* mina對分包會直接報錯, 需要使用會話控制的方式來對包進行組裝處理,比較復(fù)雜。 另外從服務(wù)器向客戶端寫大包的時候, 1.1和2.0處理不同,2.0不做控制會直接報一個bytebuffer溢出的錯誤。
* xscoket缺省會吞掉這個錯誤,自動采用重試的方式嘗試讀取數(shù)據(jù),對開發(fā)來說比較簡單,另外也可以提供類似mina那樣的安全處理模式,代碼比mina要簡單。 - 文檔支持
* mina 比較多,但是語焉不詳,問題要靠自己啃代碼和上論壇
* xsocket 只有一篇文檔, 但是比較詳盡的介紹了所有需要的知識。另外,視乎, xsocket的代碼質(zhì)量要更好一些, mina更向是不斷學習過程中不斷完善改進的作品。 - 學習曲線
*mina 要較好的使用需要對nio有深入的了解, 一般使用學習難度不大
* xsocket 基本不用學習
== 結(jié)論 ==
我的應(yīng)用是手機和服務(wù)器端通過自定義的二進制協(xié)議進行通訊,我需要的是一個輕量級的解決方案。
使用mina的自定義協(xié)議方式處理需要額外的工作量, 而mina對直接操作基本數(shù)據(jù)類型的支持并不好,或者說需要我深入的學習nio部分內(nèi)容。 最終因為fragment和對lowerlevel數(shù)據(jù)的更簡單的支持讓我選擇了xsocket,很輕松的完成了移植工作。
如果一開始設(shè)計通訊部分就接觸mina的話,我可能會堅持使用mina的自定義協(xié)議方式來處理,但是就目前來說,他太復(fù)雜了,將來有時間,可以做為應(yīng)用模式的學習對mina進行深入解剖。
== 其他 ==
其他常見的java的通訊協(xié)議框架
qickeserver : 以文本流為模式的通訊框架
netty: mina的前身
cindy: 國人在接觸netty之后開發(fā)的, 我接觸時已經(jīng)停止開發(fā)一年了,所以基本不予考慮。
== 補充 ==
下午無聊又玩了一下quick server。
1. quickserver 1.4.7 現(xiàn)在有提供對binary模式的支持,可以使用一個ClientBinaryHandle處理二進制流,不過處理稍顯復(fù)雜,還要多開一個線程。對當前的應(yīng)用來說xsocket已經(jīng)足夠了。
2. quickserver 在易用性和復(fù)雜程度方面在xsocket和mina之間, 架構(gòu)上更傾向于解決較復(fù)雜的問題,和mina有很多相似處。
較復(fù)雜的數(shù)據(jù)處理也需要引入流和bytebuffer的概念。
3. quick的文檔和例子都不錯, 要明顯比mina好, 有點不爽的是配置文件有點婆媽,考慮到我的一般應(yīng)用都是要集成到服務(wù)器中使用的,覺得有點煩,不過基本可以放棄研究mina了。
4. quick 架構(gòu)上handle的使用可以配置,產(chǎn)生類似mina那種filter的效果,還是蠻有意思的。
5. 另外還自己實現(xiàn)了一些婆婆媽媽的管理界面,有空看看完。
最后許可證協(xié)議只要使用binary的包,商用就沒問題。
其實這3個框架都是以回調(diào)和組裝為中心的設(shè)計,關(guān)注點有所不同而已。自己比較懶還是喜歡那種越簡單越好的,看mina有點頭疼。
請問這句話是什么意思?直接用handler.sendClientBinary(new byte[]{});不行嗎?
example代碼里有,pipeserver, 你自己翻翻看
另外有個文檔也有講。
我現(xiàn)在用mina,但是總是不行。
您能幫我提一個大概的思路嗎?謝謝。
可以話,給我回復(fù)郵件mavlarn@163.com.
謝謝。
請教原因。謝謝!
個人觀點:
mina 默認協(xié)議就是基于byte的,只不過在polling Processer中 轉(zhuǎn)換成 IoBuffer(Iobuffer是對bytebuffer進行了個擴展式的封裝) 傳遞 到 iohandler 中,所以基于byte的mina也能很好的處理! xsocket 我沒用過,不好發(fā)表評論,對于作者對socket通信模塊的比較感覺比較佩服,多向你學習,呵呵!
email:william@fiinet.cn
qq:526054692