即時通信與浏覽器多TAB通信

摘要

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

TAG

即時通信，多tab通信

内容

關鍵技術

消息推送：通過基于web server的長連接配接技術實作

前端多Tab資料互動：借助Flash的Local Connection和ShareObject技術實作

Client-Server互動模型

分層設計

主要功能：

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的時候做這個操作。進一步減少這種異常情況發生的機會。

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

本文轉自百度技術51CTO部落格，原文連結：http://blog.51cto.com/baidutech/743735，如需轉載請自行聯系原作者