<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    BlazeDS中channel和Endpoint的相關概念

    1.Channel和Endpoint的定義
    Channels are client-side objects that encapsulate the connection behavior between Flex components and the BlazeDS server. Channels communicate with corresponding endpoints on the BlazeDS server. You configure the properties of a channel and its corresponding endpoint in the services-config.xml file.

    2.從數據格式上分,Channels分為AMF Channel和HTTP Channel,區(qū)別在于
    The difference between AMF and HTTP channels is that AMF channels transport data in the binary AMF format and HTTP channels transport data in AMFX, the text-based XML representation of AMF.

    3.從客戶端與服務端的交互方式上分,Channels主要分為:
      Simple channels and endpoints 包括:
       (1) Non-polling channels
       (2) Polling channels
       (3) Long polling channels
     
      Streaming channels
       (1) Streaming channels

    3.關于 Non-polling,Polling,Long polling和steaming的一些解釋
    http://www.qgy18.com/2008/08/webim-design-transport/
    http://newteevee.com/2009/10/04/adobe-to-finally-support-http-streaming/

    1.短輪詢(polling):核心思想是客戶端定時去服務器取消息。為了實現即時效果,輪詢的間隔必須設計得足夠短,另外為了操作的流暢,需要使用Ajax來發(fā)送請求。本人的QGYWebIM就是采用的此方案。這種方案的優(yōu)點是:后端程序編寫比較容易,發(fā)送完響應信息馬上斷開連接,不會占用太多服務器資源。缺點是一般情況下,頻繁的請求中有大半是無用,這些冗余請求無形中浪費了帶寬和服務器資源。我們可以通過判斷用戶的活躍程度來決策請求服務器的間隔,我在51的一個帖子提到過這種方法,但是間隔一旦長了,消息的傳送就有延時,違背了即時聊天的初衷了。

    2.長輪詢(long-polling):基本原理是客戶端向服務器發(fā)送請求,服務器接到請求后hold住連接,直到有新消息才返回響應信息并關閉連接,連接被斷開期間用戶的新信息會被服務器緩存起來。客戶端處理完響應信息后再向服務器發(fā)送新的請求。這種做法的優(yōu)勢是如果用戶一直沒新消息,客戶端不會頻繁的輪詢去服務器取消息,節(jié)省了流量,但是服務器維持長連接是很消耗資源的。具體實現起來,前端這邊基本不需要什么改動,依然是用Ajax輪詢取信息,后端需要在沒有新消息時處理一下。

    3.長連接(streaming):其實很早以前就有人使用這種技術來實現聊天室的通訊,HTTP1.1開始支持。以前在頁面中嵌入一個iframe,iframe里放一個使用長連接頁面,服務器有新消息就會及時的在iframe里反映出來,再依靠客戶端的腳本解析出來就OK了。這樣做一個比較嚴重的問題是:使用 iframe請求長連接時,無論是IE還是firefox都會認為頁面沒有加載完而顯示進度條,很難看。不過這個問題是可以解決的。firefox支持了Streaming Ajax,在readyState為3的時候就能接受數據,所以問題不大;IE則只能在readyState為4,即連接斷開時才能得到返回值。但是偉大的Google工程師使用了一個hack成功的解決了這個問題:使用一個被稱為“htmlfile”的ActiveX,把iframe放在這個ActiveX里就OK了。

    無疑,使用長連接對于用戶來說是最好的方案,用戶體驗最好(消息能及時的到達)、占用用戶帶寬最少(不會發(fā)送無用的請求),但是會增加服務器的開銷;長輪詢是折中方案,Facebook IM 就是采用這種方案,不過做了一點改動:客戶端發(fā)起的每個連接服務器都hold10S,這10S中新消息會源源不斷的返回給客戶端,10s后連接關閉,客戶端發(fā)起下一個連接。這樣做是因為Facebook的用戶會不斷的打開、關閉新頁面,如果每個頁面都建立一個永久的長連接,會阻塞瀏覽器其他請求,服務器也會吃不消的;短輪詢因為實現起來簡單,適用于小型應用。

    posted on 2010-03-01 17:16 想飛就飛 閱讀(1040) 評論(0)  編輯  收藏 所屬分類: Flex

    公告


    導航

    <2010年3月>
    28123456
    78910111213
    14151617181920
    21222324252627
    28293031123
    45678910

    統(tǒng)計

    常用鏈接

    留言簿(13)

    我參與的團隊

    隨筆分類(69)

    隨筆檔案(68)

    最新隨筆

    搜索

    積分與排名

    最新評論

    閱讀排行榜

    評論排行榜

    主站蜘蛛池模板: 久久亚洲精品成人AV| 亚洲日韩中文在线精品第一| 久久综合亚洲鲁鲁五月天| 可以免费观看的国产视频| 国产AV无码专区亚洲AV漫画| 一级毛片在线完整免费观看| 亚洲一区二区三区免费| 亚洲免费日韩无码系列| 亚洲人成亚洲人成在线观看 | 暖暖免费高清日本中文| 亚洲AV无码专区在线观看成人| 日韩免费观看的一级毛片| 亚洲av日韩综合一区久热| 久久精品国产精品亚洲| 成人自慰女黄网站免费大全| 亚洲va久久久噜噜噜久久天堂| 99爱在线观看免费完整版| 亚洲午夜精品在线| 免费看美女被靠到爽| 猫咪免费人成在线网站| 亚洲午夜久久久久久久久久| 你懂的网址免费国产| 亚洲精品mv在线观看| 日韩免费无砖专区2020狼| 人妻仑刮八A级毛片免费看| 国产AⅤ无码专区亚洲AV| 亚洲视频免费在线看| 亚洲av午夜国产精品无码中文字| 亚洲国产天堂久久综合| 久久久久国色av免费看| 亚洲AV无码成人专区| 男人的天堂亚洲一区二区三区 | 丁香花在线观看免费观看图片| 亚洲AV日韩AV永久无码久久 | 亚洲一区二区视频在线观看 | 日本亚洲欧洲免费天堂午夜看片女人员| 91大神亚洲影视在线| 国产一精品一aⅴ一免费| 久热免费在线视频| 色天使亚洲综合一区二区| 亚洲AV无码专区国产乱码4SE|