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

文章目錄

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

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