即时通讯与浏览器多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

【 关注百度技术沙龙】