即時通訊與瀏覽器多TAB通訊

摘要

瀏覽器與服務器端的即時通訊技術解決了在線聊天等產品中涉及到的複雜網絡環境下的問題；採用多tab通訊技術來處理現代瀏覽器的跨頁面通訊，分析特定疑難問題的技術解決方案。

TAG

即時通訊，多tab通訊

內容

 

關鍵技術

 

1. 消息推送：經過基於web server的長鏈接技術實現
2. 前端多Tab數據交互：藉助Flash的Local Connection和ShareObject技術實現

Client-Server交互模型

分層設計

多Tab通訊技術

• 主要功能：

1．多Tab中始終維持一個特立獨行的Tab

2．多Tab間互相通訊：支持廣播、組播、單播

3．跨瀏覽器數據存儲

4．跨域發送Http請求

利用flash的LocalConnection的惟一性保證客戶端多個瀏覽器多個tab之間，有且只有一個頁面與服務端交互，稱之爲server tab。

只有server tab會與Lightthy通訊

當server tab接收到lightthy的消息後，從本地存儲SharedObject中獲取其餘tab的id，而後經過LocalConnection傳遞給他們。

遇到的問題和解決方案

問題：

 

• 通訊時間過長的問題。LocalConnection構造的本地鏈接都是以串行的形式進行，每一次鏈接到用戶的電腦上，機器狀態正常的狀況下，在IE的傳輸時間大概是40-100ms；下一次鏈接必須等待上一次鏈接返回成功之後才進行。那麼若是咱們進行廣播，一次廣播20個窗口。那麼最後一個窗口收到消息的時候大概是2s左右，若是中間再出現某此失敗或者阻塞的狀況，時間會更長。
• 單純以廣播形式進行，那麼不管是什麼消息，都將全部接收端叫醒一次，由接收端本身判斷是否處理收到的消息。這樣浪費了不少資源。因此能夠考慮使用組播方式，來減小這種消耗。組內單播針對一些特殊具體應用的效率更高。

解決方案：

 

• 存儲接收端列表，以組劃分。
• 在本地協議上實現以組劃分。

問題：

 

• 多頁面併發頻繁對SharedObject進行寫操做，容易致使SharedObject崩潰（文件被無端刪除，而且再次建立失敗）。
• 考慮到一臺計算機不可能只登錄一個用戶，而SharedObject存儲容量有限，若是有效的刪除無用的數據是關鍵問題。

解決方案：

 

• 機制上用寫隊列+文件鎖來避免併發寫操做。
• 爲了不客戶端異常狀況，好比強殺瀏覽器進程，形成的文件鎖不能解鎖的狀況，須要處理超時自動解鎖的問題。
• 對於很是頻繁的特殊的寫操做，採用從reclist中刪除無用的接收者id，作緩衝時間，批量操做等策略。
• 對於存儲空間限制問題，咱們的措施是分用戶存儲，只保留最近進行操做的10個用戶的列表數據。

問題：

 

爲了減小服務端壓力，設計的初衷就是前端要在多個瀏覽器窗口中挑出一個獨特的窗口來發起listen。Server Tab的概念保證了前端能生成一個惟一的獨特窗口，用於發起listen。實現原理是利用LocalConnection的connect name惟一性，並用輪詢connect來保證只要原來發起listen的窗口一旦斷掉，即能自動從新挑選一個窗口來做爲Server Tab，併發起listen。可是咱們仍然遇到了外殼瀏覽器下面一些詭異的問題，窗口被緩存成假死狀態。致使這個機制不能很好的運行下去。

解決方案：

 

• 將Server Tab的ID作成非永久的，而是與時間相關的。也就是說給Server Tab加上一個生命週期。能解決一些外殼瀏覽器下的窗口假死形成的問題。
• 在主流瀏覽器(IE、Firefox…)下，window.unload的時候關閉本頁面的server及輪詢，在其餘非主流瀏覽器下，window.beforeunload的時候作這個操做。進一步減小這種異常狀況發生的機會。

下面是一個窗口打開後，在本地註冊的流程

 

【本文首發於： 搜索研發部官方博客】 http://stblog.baidu-tech.com/?p=835

【 關注百度技術沙龍】