著录项信息
专利名称 | 一种通过套接字连接进行通信的方法、系统及设备 |
申请号 | CN201010297631.6 | 申请日期 | 2010-09-27 |
法律状态 | 授权 | 申报国家 | 中国 |
公开/公告日 | 2012-04-18 | 公开/公告号 | CN102420805A |
优先权 | 暂无 | 优先权号 | 暂无 |
主分类号 | H04L29/06 | IPC分类号 | H;0;4;L;2;9;/;0;6;;;H;0;4;L;2;9;/;0;8查看分类表>
|
申请人 | 阿里巴巴集团控股有限公司 | 申请人地址 | 英属开曼群岛大开曼岛资本大厦一座四层847号邮箱
变更
专利地址、主体等相关变化,请及时变更,防止失效 |
权利人 | 阿里巴巴集团控股有限公司 | 当前权利人 | 阿里巴巴集团控股有限公司 |
发明人 | 禹扬帆 |
代理机构 | 北京同达信恒知识产权代理有限公司 | 代理人 | 郭润湘 |
摘要
本申请公开了一种通过套接字连接进行通信的方法、系统及设备,主要内容包括:在终端各浏览器内建立浏览器之间都能够访问的数据库,使未与服务器建立Socket连接的从浏览器将需要发送给服务器的消息写入数据库中,由与服务器建立Socket连接的主浏览器将该消息接发送至服务器,同时将服务器返回的消息也写入数据库中,由从浏览器读取服务器返回的消息,实现了多个浏览器之间共享Socket连接,且该通信过程不需要在浏览器内额外安装插件,避免了由于终端能力不足以支持插件而无法实现共享Socket连接的问题,同时由于不需要安装插件,也消除了额外安装插件所带来的安全隐患。
1.一种通过套接字Socket连接进行通信的方法,其特征在于,所述方法包括:
浏览器确定自身为主浏览器时,建立与服务器之间的Socket连接,以及,在确定数据库内有已启动的从浏览器写入的待发送消息时,将所述待发送的消息通过Socket连接发送给服务器,并将服务器返回的消息写入所述数据库;
浏览器确定自身为从浏览器时,将自身待发送给服务器的消息写入数据库中,并读取数据库中存储的服务器返回的消息;
其中,浏览器通过超文本传输协议HTTP连接从服务器内下载客户端脚本语言JavaScript脚本,并通过该JavaScript脚本将自身为主浏览器或从浏览器的信息注册在数据库中。
2.如权利要求1所述的方法,其特征在于,所述浏览器是支持HTML5规范的浏览器,所述数据库是依照HTML5规范中的WebSQL子规范,在首次启动浏览器时建立的。
3.如权利要求1所述的方法,其特征在于,所述方法还包括:
主浏览器将自身待发送给服务器的消息通过Socket连接直接发送给服务器,并直接接收服务器返回给该主浏览器的消息;或者
主浏览器将自身待发送给服务器的消息写入数据库中,由当前处于运行状态的一个主浏览器将该消息发送给服务器,并读取数据库中存储的服务器返回给自身的消息。
4.如权利要求1所述的方法,其特征在于,浏览器通过以下方式确定自身为主浏览器或从浏览器:
浏览器在启动时,从数据库中已启动的其他浏览器的注册信息,判断已在数据库中注册的处于运行状态的主浏览器数量是否小于设定门限值;若是,则确定自身为主浏览器;
否则,确定自身为从浏览器,所述设定的门限值为正整数。
5.如权利要求4所述的方法,其特征在于,所述方法还包括:
从浏览器在运行过程中,检测自身待发送的消息是否在第一时长内发送,若未在第一时长内发送,则重新确定已在数据库中注册的处于运行状态的主浏览器数量;
若重新确定的主浏览器数量小于设定门限值,则将自身的状态由从浏览器改变为主浏览器,并重新在数据库中注册;
否则,检测所述待发送的消息是否在第二时长内发送,若未在第二时长内发送,则将自身的状态由从浏览器改变为主浏览器,并重新在数据库中注册;
所述第二时长大于第一时长。
6.如权利要求4所述的方法,其特征在于,在所述设定门限值大于1时,从浏览器将自身待发送给服务器的消息写入数据库中,具体包括:
从浏览器将待发送消息的消息体、该从浏览器的标识、待发送消息的状态、发送该消息的业务标识以及从浏览器选择的用于发送该消息的主浏览器的标识写入数据库中。
7.如权利要求6所述的方法,其特征在于,主浏览器将待发送的消息通过Socket连接发送给服务器,具体包括:
主浏览器确定待发送消息的状态为第一状态时,将待发送消息的消息体通过Socket连接发送给服务器,并将待发送消息的状态更新为第二状态;
主浏览器将服务器返回的消息写入数据库中,具体包括:
主浏览器将服务器返回的消息的业务标识、所属浏览器的标识和消息体写入数据库中;
从浏览器读取数据库中存储的服务器返回的消息,具体包括:
从浏览器读取数据库中存储的服务器返回的消息中,所属浏览器的标识为自身标识的消息。
8.一种通过套接字Socket连接进行通信的装置,其特征在于,所述装置包括:
第一模块,用于浏览器在确定自身为主浏览器时,建立与服务器之间的Socket连接,并在确定终端内运行的数据库内有已启动的各浏览器写入的待发送消息时,将所述待发送的消息通过Socket连接发送给服务器,并将服务器返回的消息写入所述数据库;
第二模块,用于浏览器在确定自身为从浏览器时,将自身待发送给服务器的消息写入数据库中,并读取数据库中存储的服务器返回的消息;
其中,浏览器通过超文本传输协议HTTP连接从服务器内下载客户端脚本语言JavaScript脚本,并通过该JavaScript脚本将自身为主浏览器或从浏览器的信息注册在数据库中。
9.如权利要求8所述的装置,其特征在于,
所述第一模块,还用于主浏览器将自身待发送给服务器的消息通过Socket连接直接发送给服务器,并直接接收服务器返回给该主浏览器的消息,或者,主浏览器将自身待发送给服务器的消息写入数据库中,由当前处于运行状态的一个主浏览器将该消息发送给服务器,并读取数据库中存储的服务器返回给自身的消息。
一种通过套接字连接进行通信的方法、系统及设备\n技术领域\n[0001] 本申请涉及通信领域,尤其涉及一种通过套接字(Socket)连接进行通信的方法、系统及设备。\n背景技术\n[0002] 随着因特网技术的发展,越来越多的用户利用安装在终端内的浏览器浏览网站服务器推送的数据。目前,常规的浏览网站页面使用的是超文本传输协议(HTTP)请求方式,即当访问用户登录网站后,在浏览器中嵌入的面向对象的动态类型的区分大小写的客户端脚本语言(JavaScript)生成的脚本模块(后续称之为JavaScript脚本)触发浏览器向网站服务器发送HTTP请求。\n[0003] 由于发送的HTTP请求是数据传输通道之间的短连接,在请求达到网站服务器后,HTTP请求建立的通道就断开,因此,只能是在每次有需求时不断发起HTTP请求,导致在有大量用户访问网站时,网站服务器的业务压力很大。\n[0004] 为了解决常规的HTTP协议的短连接给网站服务器造成压力过大的问题,在浏览器浏览网页的过程中,提出了利用Socket通信方式替代常规的HTTP轮询请求方式。当访问用户登录网站时,浏览器从网站服务器中下载JavaScript脚本,且建立与网站服务器之间的Socket长连接。由于Socket长连接不会在数据传输后马上断开,使得网站服务器可以实时通过Socket连接通道向浏览器推送数据,在浏览网页的过程中网站服务器不再需要承受大量的HTTP请求,降低了网站服务器的工作压力,提升了网站服务器的响应速度。\n[0005] 通过Socket长连接在一定程度上降低了网站服务器的工作压力,但是,如果在一个终端上同时启动多个浏览器,每个浏览器都产生一个与网站服务器的Socket长连接,则网站服务器将为该终端启动的多个浏览器维护多条Socket长连接。如果有大量的终端使用该网站服务器提供的数据资源,而每个终端上都启动多个浏览器,则网站服务器需要维护Socket长连接数量也非常巨大,占用了网站服务器的大量资源。例如:有10000台终端,每台终端启动4个浏览器登录网站,则网站服务器需要维持40000条Socket长连接。\n[0006] 为了解决上述网站服务器维护大量的Socket长连接导致网站服务器的资源占用量大的问题,目前提出了通过安装基于浏览器的插件,如Flash、ActivieX、Applet等的方式来共享Socket长连接的技术方案。以安装Flash插件为例,该技术方案的主要内容是:\n[0007] 在浏览器内安装Flash插件,在每次启动浏览器时也同时启动Flash插件,由于Flash插件具有服务(Service)功能,多个Flash插件之间可以相互调用。终端内首次启动的浏览器与网站服务器建立Socket长连接,后启动的浏览器不与网站服务器之间建立Socket长连接。将该首次启动的浏览器称之为主浏览器,主浏览器中的Flash插件定义为主插件,后启动的浏览器称之为从浏览器,从浏览器中的Flash插件定义为从插件。\n[0008] 当从浏览器需要与网站服务器之间进行数据传输操作时,该从浏览器内的从Flash插件调用主Flash插件,将从浏览器需要发送的消息通过调用插件的方式传输给主浏览器,由主浏览器通过Socket长连接将该消息转发给网站服务器;当网站服务器通过Socket长连接返回发送给从浏览器的消息时,主Flash插件调用该从Flash插件,将网站服务器返回的消息发送给从浏览器。此时,从浏览器通过主浏览器间接实现与网站服务器之间的Socket长连接。\n[0009] 通过上述安装特定插件的方式,由插件之间相互调用实现浏览器之间的通信,进而实现从浏览器与网站服务器之间间接的Socket长连接,使得在终端内启动多个浏览器的情况下,可以大大减少与网站服务器之间的Socket长连接数量,克服了网站服务器为维护大量的Socket长连接导致资源占用量大的问题。但是,该方案需要额外安装插件,对终端能力有一定要求,如果终端能力不支持安装的插件,则需要安装特定的客户端(如Flash Player)来运行插件,否则将无法实现上述方案。若终端能力不支持特定的客户端,则无法实现上述方案。另外,即使终端支持安装的特定插件或是特定的客户端,但是,额外安装的插件和客户端的安全性无法验证,威胁终端的安全性。\n发明内容\n[0010] 本申请实施例提供一种通过Socket连接进行通信的方法、系统及设备,用以解决现有技术中存在额外安装插件导致终端不支持以及降低终端安全性的问题。\n[0011] 一种通过Socket连接进行通信的方法,所述方法包括:\n[0012] 浏览器确定自身为主浏览器时,建立与服务器之间的Socket连接,以及,在确定数据库内有已启动的各浏览器写入的待发送消息时,将所述待发送的消息通过Socket连接发送给服务器,并将服务器返回的消息写入所述数据库;\n[0013] 浏览器确定自身为从浏览器时,将自身待发送给服务器的消息写入数据库中,并读取数据库中存储的服务器返回的消息。\n[0014] 一种通过Socket连接进行通信的系统,所述系统包括服务器以及在终端内运行的浏览器和浏览器内嵌的数据库,其中:\n[0015] 所述浏览器,用于在确定自身为主浏览器时,建立与服务器之间的Socket连接,并在确定数据库内有已启动的在终端内运行的各浏览器写入的待发送消息时,将所述待发送的消息通过Socket连接发送给服务器,并将服务器返回的消息写入所述数据库;在确定自身为从浏览器时,将自身待发送给服务器的消息写入数据库中,并读取数据库中存储的服务器返回的消息;\n[0016] 所述服务器,用于与浏览器建立Socket连接,并接收浏览器通过Socket连接发送的消息,以及,通过Socket连接向浏览器返回消息。\n[0017] 一种浏览器,应用于终端内,所述浏览器包括:\n[0018] 第一执行模块,用于在确定所述浏览器为主浏览器时,建立与服务器之间的Socket连接,并在确定终端内运行的数据库内有已启动的各浏览器写入的待发送消息时,将所述待发送的消息通过Socket连接发送给服务器,并将服务器返回的消息写入所述数据库;\n[0019] 第二执行模块,用于在确定所述浏览器为从浏览器时,将自身待发送给服务器的消息写入数据库中,并读取数据库中存储的服务器返回的消息。\n[0020] 本申请有益效果如下:\n[0021] 本申请实施例在终端内建立各浏览器都能够访问的数据库,以便于在终端内启动多个浏览器时,未与服务器建立Socket连接的从浏览器将发送给服务器的消息写入数据库中,由与服务器建立Socket连接的主浏览器将该消息通过自身建立的Socket连接发送至服务器,同时将服务器返回的消息也写入数据库中,由从浏览器读取服务器返回的消息,使得从浏览器可以间接地通过主浏览器的Socket连接与网站服务器之间的通信,实现了多个浏览器之间共享Socket连接,且该通信过程不需要在浏览器内额外安装插件,避免了由于终端能力不足以支持插件而无法实现共享Socket连接的问题,同时由于不需要安装插件,也消除了额外安装插件所带来的安全隐患。\n附图说明\n[0022] 图1为本申请实施例方案所应用的场景示意图;\n[0023] 图2为本申请实施例一中通过Socket连接进行通信的方法示意图;\n[0024] 图3为本申请实施例三中通过Socket连接进行通信的系统结构示意图;\n[0025] 图4为本申请实施例四中浏览器结构示意图。\n具体实施方式\n[0026] 为了实现本申请目的,本申请实施例提出通过调用超文本标记语言5(HTML5)中的基于浏览器数据接口的技术(WebSQL API),在终端建立各浏览器都能够访问的数据库,以便于在终端内启动多个浏览器时,未与网站服务器建立Socket连接的从浏览器将发送给网站服务器的消息写入数据库中,由与网站服务器建立Socket连接的主浏览器不断扫描数据库,当发现有需要发送给网站服务器的消息时,将该消息通过自身建立的Socket连接发送至网站服务器,同时将网站服务器返回的消息也写入数据库中,由从浏览器读取网站服务器返回的消息,因此从浏览器可以间接地通过主浏览器的Socket连接与网站服务器之间通信,实现了多个浏览器之间共享Socket连接,且该通信过程不需要在浏览器内额外安装插件,避免了由于终端能力不足以支持插件而无法实现共享Socket连接的问题,同时由于不需要安装插件,也消除了额外安装插件所带来的安全隐患。\n[0027] 所述WebSQL是HTML5规范中的子规范,用于描述如何建立终端内的用来保存离线信息的数据库,还描述了如何使用Javascript对该数据库进行写入、读出、修改、查找、建库、建数据库内数据表的操作。\n[0028] 需要说明的是,本申请实施例中的数据库可以通过调用HTML5中的WebSQL API来建立,但也不限于通过其他方式建立数据库,使得建立的数据库能够被所有的浏览器进行读写操作。\n[0029] 本申请实施例方案可以应用在用户操作终端内的浏览器与网站服务器之间进行消息传输的场景,如图1所示,为本申请实施例方案所应用的场景示意图,在终端内启动并运行多个浏览器,且在终端的一段存储空间内开辟建立数据库,各浏览器可以对该数据库进行读写操作;同时,主浏览器与网站服务器之间建立Socket连接,从浏览器未与网站服务器之间建立Socket连接。从浏览器将希望发送给网站服务器的消息写入数据库,由主浏览器扫描到写入新消息的事件后,将该消息读出并转发给网站服务器,并将网站服务器返回的消息写入数据库中,由从浏览器主动读取网站服务器返回的消息。从图1的结构中可以看出,由于浏览器内没有安装特定插件,主从浏览器之间并没有直接通信,而是通过共同读写的数据库进行消息传输,再由主浏览器为从浏览器与网站服务器之间进行Socket传输,主从浏览器之间共享主浏览器与网站服务器之间的Socket连接。\n[0030] 下面对图1中的各部件以及部件之间的连接关系进行说明。\n[0031] 根据数据库建立的方式不同,本申请各实施例中涉及的浏览器是能够支持建立数据库的规范的浏览器。例如:若是通过调用HTML5中的WebSQL API在终端内建立数据库,则本申请各实施例中涉及的浏览器是能够支持HTML5规范的浏览器。\n[0032] 本申请各实施例中涉及的数据库可以是在终端的磁盘空间内开辟的存储区域,该数据库可以是静态建立的数据库或动态建立的数据库,所述静态建立是指:在有浏览器启动(即需要使用该数据库)时,通过浏览器的Javascript连接该数据库,在所有的浏览器都退出(即不需要使用该数据库)时,通过浏览器的Javascript去断开与该数据库的连接,通过调用HTML5中的WebSQLAPI在终端内建立的数据库的资源不因去激活而释放。所述动态建立是指:在有浏览器启动时,通过浏览器的Javascript调用HTML5中的WebSQLAPI在终端内建立的数据库,在所有的浏览器都退出时,释放建立的数据库资源。\n[0033] 本申请各实施例中涉及的Socket连接可以是根据HTML5规范中的WebSocket子规范的描述,通过Javascript建立了浏览器与服务器之间的Socket长连接,用于实现浏览器与服务器之间的通信。\n[0034] 本申请各实施例中的主浏览器和从浏览器可以是根据HTML5规范中的Workers子规范的描述,通过Javascript产生和控制在数据库中读写的线程。\n[0035] 本申请各实施例中涉及的终端可以具有网络通信能力且安装有浏览器的设备,如电脑、手机等。\n[0036] 下面结合说明书附图对本申请各实施例进行详细描述。\n[0037] 实施例一:\n[0038] 如图2所示,为本申请实施例一中通过Socket连接进行通信的方法,所述方法包括以下步骤:\n[0039] 步骤101:浏览器检测自身的状态,确定自身为主浏览器或从浏览器,若为主浏览器,则执行步骤102;否则,执行步骤106。\n[0040] 当终端首次启动浏览器时(即该浏览器启动时,不存在其他处于运行状态的浏览器),该浏览器通过HTTP连接,从服务器下载Javascript脚本,并通过该Javascript脚本调用HTML5中的WebSQL API来建立数据库。若建立的数据库是静态建立的数据库,则通过该Javascript激活数据库,若建立的数据库是动态建立的数据库,则通过该Javascript请求为数据库分配资源,建立数据库。\n[0041] 当终端的某一浏览器启动时,已有其他浏览器启动并处于运行状态时,则该浏览器通过HTTP连接,从服务器下载Javascript脚本,并通过该Javascript脚本向数据库写入或读出数据。\n[0042] 针对某一浏览器A,确定自身为主浏览器或从浏览器的具体方式为:\n[0043] 浏览器A在启动时,读取数据库中维护的注册表,该注册表中记录了已启动的其他各浏览器自身为主浏览器或从浏览器的注册信息。当前启动的浏览器A判断注册表中已在数据库中注册的处于运行状态的主浏览器的数量是否小于设定门限值,若是,则确定浏览器A为主浏览器;否则,确定浏览器A为从浏览器。\n[0044] 在本实施例一的方案中,用于判断浏览器是否为主浏览器的所述门限值为正整数,即终端内已启动的浏览器中可以只有一个主浏览器,也可以有多个主浏览器,该门限值的实际取值可以根据服务器的Socket连接的维护能力和启动的浏览器数量确定,这是因为:\n[0045] 一方面,由于主浏览器要与服务器之间建立Socket连接,若主浏览器的数量过多,则服务器需要维护的Socket连接数量也较多,可能造成服务器负担过大的问题;另一方面,主浏览器建立的Socket连接要共享给从浏览器,若主浏览器的数量过少,而启动的浏览器数量较多(即从浏览器的数量较多),则主浏览器可能无法及时响应从浏览器与服务器之间的消息传输,导致需要传输的消息延迟的问题。因此,需要综合考虑服务器的Socket连接的维护能力和启动的浏览器数量来确定主浏览器的数量,如设定主浏览器和从浏览器的数量之比为1∶1~1∶3。\n[0046] 浏览器在确定自身为主浏览器或从浏览器后,通过该JavaScript脚本将自身为主浏览器或从浏览器的信息写入注册表中,同时写入的还有自身的标识。浏览器将自身的信息写入注册表的过程可以看作是浏览器在数据库中注册的过程。\n[0047] 需要说明的是,浏览器自身的标识是用于唯一表示该浏览器的标识,可以通过Javascript脚本来生成,具体使用的算法包括但不限于Javascript脚本可用的各种标识生成算法。\n[0048] 通过步骤101的方案,终端内每次启动的浏览器确定自身是主浏览器或是从浏览器,并在数据库中注册,后续,浏览器可以根据自身的状态进行相应的操作。\n[0049] 步骤102:浏览器确定自身为主浏览器时,建立与网站服务器之间的Socket连接。\n[0050] 步骤103:主浏览器实时扫描数据库内是否有待发送的消息,若有,则执行步骤\n104;否则,继续扫描。\n[0051] 在本实施例一的方案中,数据库中除了维护有注册表外,还维护任务队列表,该任务队列表中的每一条信息记录一项任务的相关信息,包括:发起该任务的浏览器的标识、该浏览器为本次任务分配的业务标识、本次任务的执行状态、本次任务待发送消息的消息体以及任务创建时间等。\n[0052] 主浏览器通过HTML5规范中的Workers子规范实现后台Javascript脚本轮询查看任务队列表,判断是否有待发送的消息。\n[0053] 若终端内存在多个主浏览器,由于每一主浏览器都实时扫描任务队列表中的信息,可能出现同一消息被多个主浏览器发送的情形。为了克服该问题,本实施例中将任务队列表进行扩展,要求执行任务的浏览器除了要在任务队列表中记录一项任务的上述相关信息,还记录从浏览器选择的用于发送该消息的主浏览器的标识,由该主浏览器的标识对应的主浏览器发送该消息。\n[0054] 从浏览器选择用于发送消息的主浏览器可以有多种方式,包括但不限于:从浏览器随机从多个主浏览器中选择一个用于发送消息的主浏览器;或者,从浏览器按照任务均衡的原则,查看每一主浏览器被几个从浏览器选择用于发送消息,选择需要承载的从浏览器的任务较少的主浏览器,使得各主浏览器发送消息的任务相对均衡。\n[0055] 终端内只有一个主浏览器的情况可以看作是多主浏览器的特例,在只有一个主浏览器的情况下,任一从浏览器选择该唯一的主浏览器用于发送消息。\n[0056] 若终端内当前只有一个主浏览器,但存在多个任务(即多个待发送的消息),则主浏览器根据任务创建时间的先后顺序,依次发送所述待发送的消息。\n[0057] 步骤104:主浏览器将所述待发送的消息通过Socket连接发送给服务器,并跳转至步骤103。\n[0058] 当主浏览器向服务器发送消息之后,可以不必等待服务器返回的消息,而是返回步骤103,继续扫描是否有待发送的消息。\n[0059] 步骤105:当主浏览器接收到服务器返回的消息时,将该消息写入数据库中,并跳转至步骤103。\n[0060] 主浏览器可以在步骤102之后的任意时刻接收到服务器返回的消息,执行本步骤,将服务器返回的消息写入数据库中。\n[0061] 数据库中可以维护回应接收队列表,主浏览器可以将每次接收到服务器返回的消息写入回应接收队列表中,该回应接收队列表中的每一条信息记录一条服务器返回消息的相关信息,包括:返回的消息所属浏览器的标识、所属浏览器为本次接收消息的任务分配的业务标识以及消息的消息体等。\n[0062] 需要说明的是,针对步骤103中任务队列表中的一项任务,该任务的相关信息记录了待发送消息的消息体、所属浏览器的标识以及浏览器为本次任务分配的业务标识,因此,当服务器返回针对该项任务的消息后,服务器返回的消息中也同样有所属浏览器的标识、所属浏览器为本次接收消息的任务分配的业务标识以及消息的消息体等。\n[0063] 针对同一任务向服务器发送消息和接收服务器返回消息的主浏览器可以是同一主浏览器,也可以是不同的两个主浏览器分别执行的。\n[0064] 步骤106:从浏览器将自身待发送给网站服务器的消息写入数据库中。\n[0065] 从浏览器向任务队列表中写入一项任务的相关信息,该相关信息包括:自身的标识、为本次任务分配的业务标识、本次任务的执行状态、本次任务待发送消息的消息体以及任务创建时间等,进一步地,还可以包括从浏览器选择的用于发送消息的主浏览器的标识。\n[0066] 针对从浏览器待发送的消息,由从浏览器在任务队列表记录一项任务的相关信息后,再由主浏览器发送。\n[0067] 针对主浏览器待发送的消息,可以有以下两种发送方式:\n[0068] 第一种方式:主浏览器待发送给服务器的消息不需要写入数据库的任务队列表中,由主浏览器自身通过Socket连接直接发送给服务器,且服务器返回给该主浏览器的消息也不需要写入数据库中,而是由该主浏览器直接接收。\n[0069] 第二种方式:主浏览器待发送的消息不是直接通过Socket连接发送给服务器,而是先将待发送的消息写入数据库的任务队列表中,作为任务队列表中的一项任务。例如:主浏览器A将自身待发送的消息写入任务队列表,由终端内的任一主浏览器(可以是主浏览器A或是其他主浏览器)扫描任务队列表后,将主浏览器A写入的所述待发送的消息发送给服务器,例如:由主浏览器B将主浏览器A写入任务队列表的消息通过Socket连接发送给服务器。服务器返回给主浏览器A的消息也由终端内的任一主浏览器(如主浏览器B)接收后写入数据库中,主浏览器A实时扫描出服务器返回给自身的消息。\n[0070] 本步骤是在从浏览器和主浏览器需要向服务器发送消息时执行。\n[0071] 步骤107:从浏览器读取数据库中存储的网站服务器返回的消息。\n[0072] 在本步骤中,从浏览器实时扫描回应接收队列表,查看回应接收队列表是否有服务器返回给自身的消息,若有,则读取该消息;否则,继续扫描。\n[0073] 本步骤可以是在主浏览器和从浏览器运行过程中实时执行,避免漏收服务器返回的消息。\n[0074] 上述步骤101~步骤107的方案是针对某一浏览器是主浏览器或从浏览器的情况下需要执行的操作,在实际共享Socket连接的通信过程中,同时存在主浏览器和从浏览器,主从浏览器根据上述步骤的内容各自运行,在运行过程中,步骤103~步骤107的顺序根据实际情况而不限定为本实施例一中的顺序。\n[0075] 在上述实施例一的方案中,每一浏览器在启动后都需要确定自身为主浏览器或是从浏览器,并根据自身的状态执行相应的操作。但从浏览器的状态是可以变化的,具体的变化过程根据主浏览器是否正常退出的不同而不同,下面具体加以说明。\n[0076] 假设当前终端内有至少一个主浏览器以及至少一个从浏览器,且主浏览器的数量已达到步骤101中涉及的门限值。针对主浏览器是否正常退出的情况,从浏览器的状态是否改变的情况如下:\n[0077] 1、有一个主浏览器正常退出,该主浏览器将自身退出的信息写入注册表后退出。\n[0078] 若此时有新的浏览器启动,则由于有主浏览器退出,当前处于运行状态的主浏览器的数量未达到门限值,则新启动的浏览器将作为主浏览器。\n[0079] 若此时没有新的浏览器启动,且也没有从浏览器有发送消息的业务,则从浏览器的状态不改变。\n[0080] 若此时没有新的浏览器启动,而从浏览器有发送消息的任务,则该从浏览器从任务创建时间开始启动定时器,检测消息是否在第一时长内发送出去;如果消息在第一时长内发送,表示当前运行的主浏览器的数量虽然未达到门限值,但已能够满足共享Socket连接的需求,则从浏览器的状态不改变。如果消息在第一时长内未发送,表示当前运行的主浏览器不能够满足共享Socket连接的需求,从浏览器查看注册表中当前处于运行状态的主浏览器的数量,发现主浏览器的数量小于所述门限值,则将自身的状态改为主浏览器,同时将自身的状态由从浏览器转变为主浏览器的信息写入注册表中。\n[0081] 2、有一个主浏览器非正常退出,该主浏览器在退出时没有在注册表写明退出的信息。\n[0082] 若此时有新的浏览器启动,则由于当前注册表中记录的主浏览器的数量仍不小于门限值,则新启动的浏览器将作为从浏览器。\n[0083] 若此时没有新的浏览器启动,且也没有从浏览器有发送消息的业务,则从浏览器的状态不改变。\n[0084] 若此时没有新的浏览器启动,而从浏览器有发送消息的任务,则该从浏览器检测消息是否在第一时长内发送;如果消息在第一时长内发送,表示当前运行的主浏览器能够满足共享Socket连接的需求,从浏览器的状态不改变。如果消息在第一时长内未发送,表示当前运行的主浏览器不能够满足共享Socket连接的需求,从浏览器查看注册表中主浏览器的数量。由于已退出的主浏览器是非正常退出的,注册表中没有该主浏览器的退出信息,则注册表中显示的处于运行状态的主浏览器数量不小于门限值。从浏览器则进一步判断消息是否在第二时长(第二时长大于第一时长,该第二时长可认为是从浏览器待发送的消息所能容忍的最大时延)内发送,若是,则从浏览器的状态不改变,否则,表示主浏览器的门限值设置过少,从浏览器将自身的状态改为主浏览器,同时将自身的状态由从浏览器转变为主浏览器的信息写入注册表中。\n[0085] 通过上述步骤101~步骤107的方案,在主从浏览器共享Socket连接减少Socket的连接数量,减少服务器维护Socket连接压力的情况下,无需在终端内安装插件或是运行插件的特定客户端,降低了对终端的能力要求,使得能力较低的终端也能够通过本申请方案实现减少服务器维护Socket连接压力的目的;且由于不需要安装插件,也消除了额外安装插件所带来的安全隐患。\n[0086] 实施例二:\n[0087] 本申请实施例二通过一个具体的实例来说明实施例一的方案。\n[0088] 假设本申请实施例二中主浏览器的数量为1,不论主从浏览器,待发送的消息和服务器返回的消息都存储在数据库中。\n[0089] 实施例二的方案包括以下步骤:\n[0090] 第一步:启动浏览器1,浏览器1通过HTTP连接从服务器下载页面和Javascript脚本。\n[0091] 第二步:浏览器1确定当前不存在其他已启动的浏览器,则通过Javascript脚本调用HTML5规范中的WebSQLAPI在终端内建立数据库。\n[0092] 第三步:浏览器1确定自身为主浏览器,并在数据库中的注册表中进行注册。\n[0093] 所述注册表如表1所示,注册表中的每一条信息为一个浏览器的注册内容,包括:\n浏览器的标识(IE_ID)以及表示该浏览器是主浏览器或从浏览器的令牌(IS_HOST),令牌值为0,表示该浏览器为主浏览器,令牌值为1,表示该浏览器为从浏览器。从表1中可以看出,浏览器1的标识为0001,令牌值为0。\n[0094] \n[0095] 表1\n[0096] 第四步:当有浏览器2、浏览器3启动时,也通过HTTP连接从服务器下载页面和Javascript脚本。\n[0097] 第五步:浏览器2通过Javascript脚本读取注册表,发现其中标识为0001的浏览器令牌值为0,是主浏览器。由于终端内主浏览器的最大数量为1,则浏览器2确定自身为从浏览器;浏览器3执行与浏览器2的相同操作。\n[0098] 第六步:浏览器2、浏览器3在注册表中注册。\n[0099] 在浏览器2、浏览器3注册后,表1中的注册表改为表2所示。\n[0100] \n[0101] 表2\n[0102] 第七步:浏览器2需要向服务器发送消息时,在任务队列表中插入一项新任务。\n[0103] 任务队列表的结构如表3所示。\n[0104] \n[0105] 表3\n[0106] 任务队列表用于存储各个浏览器请求的任务。特殊地,如果是服务器主动发起的任务,也可以看作是任务队列表中的一项任务。\n[0107] 浏览器2发起的一项任务的信息包括:浏览器2的标识(IE_ID)0002,浏览器2为本次任务分配的业务标识(JOB_ID)0002_1,本次任务待发送消息的消息体(REQ_MSG),任务创建时间(GMT_CREATE),任务的执行状态(PROCESS_STATUS)。由于终端内只有一个主浏览器,因此,从浏览器可以不选择用于发送消息的主浏览器,默认使用唯一的主浏览器。\n[0108] 考虑到业务在执行过程中可能出现的多种情况,如消息发送超时、消息发送失败等特殊情况,本实施例二在任务的执行状态中定义了消息的多种状态,包括:新请求(状态\n0)、处理中(状态1)、已发送(状态2)、发送失败(状态3)、等待回应(状态4)、已收到回应(状态5)、已超时(状态6)。具体地,可以将上述7种状态划分为两种,其中:第一状态定义为消息未发送时的状态,包括状态0和状态1,第二状态定义为消息已发送的状态,包括状态2~状态6。\n[0109] 浏览器2在任务队列表中写入新任务时,同时写入该任务的状态为状态0。\n[0110] 第八步:浏览器1通过HTML5规范下的Workers子规范查询任务队列表,发现其中有一项新任务时,读取该消息,并将所述任务的状态更新为状态1。\n[0111] 第九步:浏览器1通过WebSocket子规范将该新任务中的消息发送至服务器,并将所述任务的状态更新为状态2。\n[0112] 第九步:浏览器1在发送消息后,若接收到发送失败响应消息,则将该任务的状态更新为状态3;否则,将该任务的状态更新为状态4,并对计时检测等待回应的时长是否超时,若超时,则将该任务的状态更新为状态6。\n[0113] 第十步:浏览器1接收到服务器返回的消息后,将该消息写入回应接收队列表,并检测该返回的消息所针对的任务,并将该任务的状态更新为状态5。\n[0114] 回应接收队列表的结构如表4所示,\n[0115] \n[0116] 表4\n[0117] 若表4所示的回应接收队列表所针对的任务是表3中浏览器2发出的任务,则返回消息的相关信息包括:浏览器2的标识(IE_ID)0002,浏览器2为本次任务分配的业务标识(JOB_ID)0002_1,服务器返回消息的消息体(MSG)。\n[0118] 第十一步:浏览器2实时扫描任务队列表中自身请求任务的状态,当状态为状态5时,表示当前已接收到服务器返回的消息,则从回应接收队列表中读取服务器返回的消息。\n[0119] 需要说明的是,浏览器2可以通过实时扫描回应接收队列表,根据回应接收队列表中各项消息所属浏览器以及业务标识确定服务器返回给自身的消息。\n[0120] 此时,任务队列表中浏览器2发起的任务已完成且回应接收队列表中服务器返回给浏览器2的消息也已达到浏览器2,因此,浏览器1可以清理任务队列表和回应接收队列表,删除任务队列表和回应接收队列表中已完成的任务的相关信息,或是将该任务标记为已完成。\n[0121] 实施例三:\n[0122] 本申请实施例三提供一种通过Socket连接进行通信的系统,如图3所示,所述系统包括服务器11以及在终端内运行的浏览器12和浏览器内嵌的数据库13,其中:所述浏览器12用于检测自身为主浏览器或从浏览器,若为主浏览器,则建立与服务器11之间的Socket连接,并在确定数据库13内有已启动的在终端内运行的各浏览器写入的待发送消息时,将所述待发送的消息通过Socket连接发送给服务器11,并将服务器11返回的消息写入所述数据库13;若为从浏览器时,将自身待发送给服务器11的消息写入数据库13中,并读取数据库13中存储的服务器11返回的消息;所述服务器11用于与浏览器12建立Socket连接,并接收浏览器12通过Socket连接发送的消息,以及,通过Socket连接向浏览器12返回消息。\n[0123] 本实施例中的浏览器12可能是主浏览器12或是从浏览器12。\n[0124] 所述浏览器12还用于在为主浏览器时,将自身待发送给服务器的消息通过Socket连接直接发送给服务器,并直接接收服务器返回给该主浏览器的消息,或者,将自身待发送给服务器的消息写入数据库中,由当前处于运行状态的一个主浏览器将该消息发送给服务器,并读取数据库中存储的服务器返回给自身的消息。\n[0125] 本实施例三中的服务器11、浏览器12和数据库13还能够实现实施例一和实施例二中涉及的各步骤的功能。\n[0126] 实施例四:\n[0127] 如图4所示,为本申请实施例四中提供的一种应用在终端内的浏览器,所述浏览器包括检测模块21、第一执行模块22和第二执行模块23,其中:检测模块21用于检测自身为主浏览器或从浏览器;第一执行模块22用于在检测结果为主浏览器时,建立与服务器之间的Socket连接,并在确定终端内运行的数据库内有已启动的各浏览器写入的待发送消息时,将所述待发送的消息通过Socket连接发送给服务器,并将服务器返回的消息写入所述数据库;第二执行模块23用于在检测结果为从浏览器时,将自身待发送给服务器的消息写入数据库中,并读取数据库中存储的服务器返回的消息。\n[0128] 本实施例方案中也可以不设置检测模块21,由第一执行模块22和第二执行模块\n23各自确定浏览器为主浏览器或从浏览器。\n[0129] 所述第一执行模块22还用于通过Socket连接直接发送给服务器,并直接接收服务器返回给该主浏览器的消息,或者,将自身待发送给服务器的消息写入数据库中,由当前处于运行状态的一个主浏览器将该消息发送给服务器,并读取数据库中存储的服务器返回给自身的消息。\n[0130] 本实施例四中的检测模块21能够实现实施例一和实施例二中确定浏览器为主浏览器或从浏览器的功能;第一执行模块22能够实现实施例一和实施例二中主浏览器的各项功能;第二执行模块23能够实现实施例一和实施例二中从浏览器的各项功能。\n[0131] 通过本申请实施例提供的方法、系统及设备,在主从浏览器共享Socket连接减少Socket的连接数量,减少服务器维护Socket连接压力的情况下,无需在终端内安装插件或是运行插件的特定客户端,降低了对终端的能力要求,使得能力较低的终端也能够通过本申请方案实现减少服务器维护Socket连接压力的目的;且由于不需要安装插件,也消除了额外安装插件所带来的安全隐患。且本申请所使用的是HTML5规范,这也是未来浏览器发展的方向,具有很好的前向兼容性。\n[0132] 本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。\n[0133] 本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。\n[0134] 这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。\n[0135] 这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。\n[0136] 尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例做出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。\n[0137] 显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。
法律信息
- 2014-07-23
- 2012-05-30
实质审查的生效
IPC(主分类): H04L 29/06
专利申请号: 201010297631.6
申请日: 2010.09.27
- 2012-04-18
引用专利(该专利引用了哪些专利)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 |
1
| |
2010-06-09
|
2009-12-14
| | |
2
| |
2009-10-07
|
2009-05-19
| | |
被引用专利(该专利被哪些专利引用)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有被任何外部专利所引用! |