摘要
浏览器与服务器端的即时通信技术解决了在线聊天等产品中涉及到的复杂网络环境下的问题；采用多tab通信技术来处理现代浏览器的跨页面通信，分析特定疑难问题的技术解决方案。
TAG
即时通信，多tab通信
内容
关键技术
消息推送：通过基于web server的长连接技术实现
前端多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的时候做这个操作。进一步减少这种异常情况发生的机会。
下面是一个窗口打开后，在本地注册的流程
