CN106534052A - 一种通信处理方法及电子设备 - Google Patents

Abstract

本发明公开了一种通信处理方法及电子设备，所述方法包括：检测自身支持的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式为全双工通信模式，所述第二通信模式为非全双工通信模式；基于自身支持的通信模式生成通信请求；发送所述通信请求至第二电子设备，以使得所述第二电子设备基于所述通信请求，确定与所述第一电子设备建立通信连接采用的通信模式；基于所述通信模式，与所述第一电子设备建立通信连接；基于所述通信连接，通过网络应用与所述第二电子设备进行数据交互。

Description

一种通信处理方法及电子设备

技术领域

本发明涉及无线通信领域的网络管理技术，尤其涉及一种通信处理方法及电子设备。

背景技术

多个电子设备通过Web应用进行交互，比如在智能电视以及智能手机之间基于Web应用进行交互，通常会采用基于HTTP Polling的方式进行通信交互。但是，上述交互方法，由于不是全双工实时交互通信，所以实时性较差；另外，最后，各类web应用间的通信，需要根据特定需要通信方式，开发语言等实现相应的通信框架，该框架不具有普适性，不可复用，在一定程度上增加了开发者的开发成本。

发明内容

有鉴于此，本发明的目的在于提供一种通信处理方法及电子设备，能至少解决现有技术中存在的上述问题。

为达到上述目的，本发明的技术方案是这样实现的：

本发明实施例提供了一种通信处理方法，应用与第一电子设备，所述方法包括：

检测自身支持的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式为全双工通信模式，所述第二通信模式为非全双工通信模式；

基于自身支持的通信模式生成通信请求；

发送所述通信请求至第二电子设备，以使得所述第二电子设备基于所述通信请求，确定与所述第一电子设备建立通信连接采用的通信模式；基于所述通信模式，与所述第一电子设备建立通信连接；

基于所述通信连接，通过网络应用与所述第二电子设备进行数据交互。

本发明实施例提供了一种通信处理方法，应用于第二电子设备，所述方法包括：

接收到第一电子设备发来的通信请求；

基于所述通信请求，确定与所述第一电子设备建立通信连接采用的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式为全双工通信模式，所述第二通信模式为非全双工通信模式；

基于所述通信模式，与所述第一电子设备建立通信连接；

基于建立的所述通信连接与所述第一电子设备进行数据交互。

本发明实施例提供了一种电子设备，包括：

检测单元，用于检测自身支持的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式为全双工通信模式，所述第二通信模式为非全双工通信模式；

信息处理单元，用于基于自身支持的通信模式生成通信请求；

通信单元，用于发送所述通信请求至第二电子设备，基于所述通信连接，通过网络应用与所述第二电子设备进行数据交互。

本发明实施例提供了一种电子设备，包括：

第二通信单元，用于接收到第一电子设备发来的通信请求；基于所述通信模式，与所述第一电子设备建立通信连接；基于建立的所述通信连接与所述第一电子设备进行数据交互；

处理单元，用于基于所述通信请求，确定与所述第一电子设备建立通信连接采用的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式为全双工通信模式，所述第二通信模式为非全双工通信模式。

本发明所提供的通信处理方法及电子设备，基于确定的通信类型与第二电子设备建立通信连接，在第一电子设备端支持自适应通信，优先选择最佳的高实时全双工通信，在不支持全双工通信的情况下，选择另一种通信模式进行处理。如此，能够结合第一电子设备的情况，尽可能的保证两个电子设备之间通信数据的实时性；另外，由于使用javascript脚本进行通信处理，因此能够提供给应用开发者使用javascript脚本快速接入框架，提升了复用性，并且降低了web实时应用开发者的准入门槛。

附图说明

图1为本发明实施例通信处理方法流程示意图一；

图2为本发明实施例确定通信模式的流程示意图；

图3为本发明实施例通信处理方法流程示意图二；

图4为本发明实施例建立第一通信模式的连接流程示意图；

图5为本发明实施例系统架构示意图；

图6为本发明实施例第二电子设备侧组成示意图；

图7为本发明实施例通信组件处理交互的整体流程；

图8为本发明实施例通信组件模块初始化流程；

图9为本发明实施例通信组件接收请求处理流程；

图10为本发明实施例接收websocket数据流程；

图11为本发明实施例通信组件处理http polling请求的流程；

图12为本发明实施例电子设备组成结构示意图一；

图13为本发明实施例电子设备组成结构示意图二。

具体实施方式

下面结合附图及具体实施例对本发明再作进一步详细的说明。

实施例一、

本发明实施例提供了一种通信处理方法，应用与第一电子设备，如图1所示，所述方法包括：

步骤11：检测自身支持的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式为全双工通信模式，所述第二通信模式为非全双工通信模式；

步骤12：基于自身支持的通信模式生成通信请求；

步骤13：发送所述通信请求至第二电子设备，以使得所述第二电子设备基于所述通信请求，确定与所述第一电子设备建立通信连接采用的通信模式；基于所述通信模式，与所述第一电子设备建立通信连接；

步骤14：基于所述通信连接，通过网络应用与所述第二电子设备进行数据交互。

这里，所述第一电子设备可以为安装有网页浏览器的设备，比如，可以为智能手机、平板电脑、笔记本电脑等。

上述步骤11中所述检测自身支持的通信模式，包括：基于自身使用的网页浏览器，确定自身支持第一通信模式或第二通信模式；其中，所述第一通信模式至少包括基于WebSocket通信协议的通信模式，所述第二通信模式为基于HTTP协议的通信模式。

其中，所述Websocket通信协议为一种全新的双向通信解决方案，是HTML5的一种新协议。它是一种“推”技术，满足浏览器与服务器全双工通信的需求。基于websocket通信的会在在浏览器和服务器之间创建一个单一的Socket，来完成双向“推”与“拉”消息的功能。这种通讯方式是持续性的、有状态的，用户很容易就可以弄明白整个通信流程。websocket可以满足高实时性的要求。鉴于websocket具备的高速全双工的通信特点，它完全满足高实时应用的需求。从通信流程中我们很容易的总结出WebSocket通信的优势：它经过一次握手即建立连接，此后互相通信不在需要传输携带冗余数据的数据头，提高了效率并且节省了网络资源；另一点是它能保证客户端与服务器是全双工异步通信，从而大大的提高了通信的实时性。

所述基于自身支持的通信模式生成通信请求，可以包括：若支持第一通信模式，则基于预设的JavaScript脚本生成包含有第一关键字的通信请求；若仅支持第二通信模式，则基于预设的JavaScript脚本生成包括有第二关键字的通信请求。

其中，所述JavaScript脚本可以表征用于提供统一的对外接口、以及智能检测通信方式的脚本；比如，可以通过JavaScript脚本建立通信连接用于发送数据、接收数据或者关闭通信连接，或者，还可以通过JavaScript脚本提供心跳机制。所述JavaScript脚本，可以如下所示：

<scriptsrc＝"sockets.js"></script>

<script>

var socket＝io('http://服务器IP地址:端口/命名空间')；

socket.on('connect',function(){})；//与服务器建立连接

socket.emit('msg',{some:'data'})；//给服务器发送数据

socket.on('disconnect',function(){})；//与服务器断开连接

</script>。

需要注意的是，只要第一电子设备安装的浏览器能够支持第一通信模式就会优选采用第一通信模式进行后续的通信流程处理；只有当第一电子设备仅支持第二通信模式的时候，才会基于第二通信模式完成后续的处理。如此，就能够在第一电子设备端支持自适应通信，优先选择最佳的高实时全双工通信，在不支持全双工通信的情况下，选择另一种通信模式进行处理，从而能够结合第一电子设备的实际情况尽可能的保证通信数据的实时性与安全性。

下面，结合图2对本实施例提供的第一电子设备开启客户端web应用，使用集成javascript脚本与第二电子设备建立连接的，以及基于所述通信连接，通过网络应用与所述第二电子设备进行数据交互的操作，进行说明：

开启第一电子设备之后，通过脚本检查浏览器是否支持第一通信模式即websocket协议，如果支持websocket协议，与安装有框架服务器的第二电子设备建立websocket连接；建立websocket连接后，通过javascript脚本的心跳机制进行连接探测，当心跳探测到异常连接，则启动websocket重连；在保证连接正常的情况下客户端应用即可与所述第二电子设备的框架服务器进行数据传输；

如果脚本检测到浏览器不支持websocket协议，则建立基于第二通信模式连接通信，本解决方案中支持XHR-Polling与Jsonp-Polling两种HTTP轮询协议。客户端web应用与框架服务器建立HTTP Polling连接后，脚本可以动态调整轮询的时间，尽可能的提高消息交互的实时性。

上述简单的示例展示了web应用与框架服务器建立连接，发送消息，断开连接整个过程。由脚本自行检测浏览器支持的最佳通信方式，websocket通信方式优先选择。

可见，通过采用上述方案，基于确定的通信类型与第二电子设备建立通信连接，在第一电子设备端支持自适应通信，优先选择最佳的高实时全双工通信，在不支持全双工通信的情况下，选择另一种通信模式进行处理。如此，能够结合第一电子设备的情况，尽可能的保证两个电子设备之间通信数据的实时性；另外，由于使用javascript脚本进行通信处理，因此能够提供给应用开发者使用javascript脚本快速接入框架，提升了复用性，并且降低了web实时应用开发者的准入门槛。

实施例二、

本发明实施例提供了一种通信处理方法，应用于第二电子设备，如图3所示，所述方法包括：

步骤31：接收到第一电子设备发来的通信请求；

步骤32：基于所述通信请求，确定与所述第一电子设备建立通信连接采用的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式为全双工通信模式，所述第二通信模式为非全双工通信模式；

步骤33：基于所述通信模式，与所述第一电子设备建立通信连接；

步骤34：基于建立的所述通信连接与所述第一电子设备进行数据交互。

这里，所述第一电子设备可以为安装有网页浏览器的设备，比如，可以为智能手机、平板电脑、笔记本电脑等。第二电子设备则可以为智能电视。

所述基于所述通信请求，确定与所述第一电子设备建立通信连接采用的通信模式，包括：基于预设的JavaScript脚本，对接收到的通信请求进行解析；若解析得到的通信请求为包含有第一关键字的通信请求，则确定通信模式为第一通信模式；否则，确定通信模式为第二通信模式；其中，所述第一通信模式至少包括基于WebSocket通信协议的通信模式，所述第二通信模式为基于HTTP协议的通信模式。

所述Websocket通信协议为一种全新的双向通信解决方案，是HTML5的一种新协议。它是一种“推”技术，满足浏览器与服务器全双工通信的需求。基于websocket通信的会在在浏览器和服务器之间创建一个单一的Socket，来完成双向“推”与“拉”消息的功能。这种通讯方式是持续性的、有状态的，用户很容易就可以弄明白整个通信流程。websocket可以满足高实时性的要求。鉴于websocket具备的高速全双工的通信特点，它完全满足高实时应用的需求。从通信流程中我们很容易的总结出WebSocket通信的优势：它经过一次握手即建立连接，此后互相通信不在需要传输携带冗余数据的数据头，提高了效率并且节省了网络资源；另一点是它能保证客户端与服务器是全双工异步通信，从而大大的提高了通信的实时性。

所述基于自身支持的通信模式生成通信请求，可以包括：若支持第一通信模式，则基于预设的JavaScript脚本生成包含有第一关键字的通信请求；若仅支持第二通信模式，则基于预设的JavaScript脚本生成包括有第二关键字的通信请求。

上述第一通信模式中全双工通信模式，比如websocket方式的交互模式可以如图4所示：客户端通过添加有第一关键字的通信请求至服务器侧；所述服务器侧根据接收到的具备第一关键字的通信请求确定接收到了进行Websocket通信的请求，若同意，则向客户端返回同意建立Websocket通信的响应信息；服务器以及客户端双方基于建立的通信连接进行数据传输。其中，所述第一关键字可以为在所述通信请求的包头中包含的upgrade等信息。另外，所述第二关键字可以为xhrPolling、jsonPolling等。

本实施例中对第一电子设备的个数不做限定，比如，图5所示提供的应用场景，所述第二电子设备52安装有具备通信框架的通信单元。框架部署在智能电视端，服务器端的应用也部署在智能电视上。通过无线网络及有线网络使电视与智能手机511、平板电脑512、便携电脑513等第一电子设备处于同一网络中。

优选地，本实施例还包括：所述第二电子设备在自身的服务框架侧进行注册，生成应用信息列表；与所述第一电子设备建立通信连接后，将所述应用信息列表发送给所述第一电子设备，以使得所述第一电子设备基于所述应用信息列表进行应用选择并进行绑定，并基于绑定的应用进行后续数据交互。具体可以包括：

第二电子设备开启后，框架会随之启动，初始化服务框架上的Web服务器，启动循环监听程序，等待第一电子设备的连接；

第二电子设备的应用也随之启动，默认状况需要其自动向Web服务器发送连接请求，并将应用的信息注册在Web服务器；

当第一电子设备中安装的应用通过网络向智能电视发送连接请求后，服务框架将已注册的应用信息列表发送给第一电子设备；第一电子设备选择需要绑定的应用，向第二电子设备提交绑定请求；

第二电子设备的框架服务器识别绑定请求将第二电子设备的应用与第一电子设备端的应用进行绑定，之后双方就可以在任意时间异步的发送消息通信。

本实施例中默认状况设置服务器端应用是一对多通信，即一个服务器端应用可以绑定多个客户端应用，意味着框架必须提供广播机制。

总体功能框图如图6所示，框架的通信组件使用C++语言进行开发，C++语言接近汇编语言，高效。编译生成的目标代码质量高，程序执行效率高。记录应用相关信息的数据表存储在系统内存中，减少使用外置数据所产生的交互及系统资源的占用。以上特性保证框架可在嵌入式环境中部署且保证跨平台的移植性。框架的前端javascript脚本(图6中JS脚本)支持web应用快速接入框架服务器。

通信组件主要需要满足的需求是：从网络中获取原始套接字请求；提供Web服务器供应用连接；提供对WebSocket通信协议解析的模块；提供最终消息解析分发的功能。

Javascript脚本满足需求：是客户端应用通过简单接口与通信组件连接，并且能自行选择最佳通信方式保证客户端应用于通信组件交互的实时性与准确性。

(1)底层I/O处理模块：框架利用它提供的内置HTTP包装器很方便的实现了框架底层的HTTP服务器，用来监听处理原始网络套接字。为通信过程中各个流程注册事件，事件没有触发前，该模块一直处于循环监听状态。当该模块监听的事件发生时，事件注册的回调函数就会被调用，处理相应的事务。本模块I/O处理基于epoll机制，它为处理大量用户的并发请求提供了保障。

(2)底层轻量级web服务器：为应用程序指定相应的连接端口，为socket对象提供以下的事件：connect、data、end、timeout、drain、error、close等。本模块对这些事件设置了特定的回调函数来处理特定的业务流程。这些回调函数都是异步执行的，当函数注册完成后，都是各自等待相应事件去触发，相互间并无影响。其提供非堵塞的I/O模型，使我们开发的框架伸缩性更好。

(3)中间层通信模块：封装了一套统一的且方便使用的API接口供客户端Web应用调用，它可以保证客户端开发者不需要关心底层的传输协议，仅仅使用javascript脚本通过简单的API就可以实现与框架服务器的连接及异步的发送和接收消息；它可以帮助客户端开发人员实现跨浏览器、跨平台的实时应用。重点支持WebSocket的通信方式，所以本模块能保证Web应用与框架服务器可以高速全双工的通信，它完全可以满足高实时应用的需求。

(4)上层消息解析器：解析由网络发送过来的数据请求。本层定义了一套Web API，以满足特定应用的通信要求。服务器端应用及客户端应用通过本层可以互相绑定，发送消息，由消息解析器解析后处理转发，以达到相互通信目的。

框架通信组件实现整个web应用间交互的通信流程如图7所示：

首先是启动web服务器；设置相应的监听端口，启动Web服务器监听，这是服务器的网络入口地址；区别应用是服务器端应用还是远程客户端应用，比如，可以通过使用命名空间定义应用类型。接着中间通信处理模块进行模块的初始化工作，这点非常重要，因为在这个过程中框架需要大量的注册各种事件，通过回调函数达到异步实时通信的目的，它还要在这个过程中启动我们的轻量级Web服务器，等待用户连接。

此后用户通过网络连接服务器，服务器为用户分配标识ID，保存设备名称，设置最大连接数等。最大连接数实质应用希望最多绑定的应用数，超过了这个绑定数，框架需要保证新的绑定请求失败；服务器端应用与客户端应用进行绑定；

其次框架在与应用连接后，通过协议解析模块进行网络协议解析。此后框架底层将接收的消息递交给消息解析器，由消息解析器经过推送应用信息、绑定服务器端应用与远程客户端应用进行消息处理与转发，即达到了应用间的相互连接通信。

最后，框架还将处理应用关闭的情况。当用户主动递交关闭消息请求关闭时，框架会将其关闭消息通知给与其连接应用，然后断开连接，清除连接信息。当用户因为意外情况(网络终端)或者强制关闭时，框架将启用心跳，超时重连等机制，以保证在设定的时间内用户重新连接即可保持连接，超时后即当作用户关闭，断开连接，清除连接信息，然后关闭服务器。

本通信服务框架在嵌入式系统中运行时是以一种插件的形式运行在第二电子设备的系统上，所以当第二电子设备启动时，框架组件也随之启动。为了保证框架正常运行，此时需要很多的初始化工作，通信组件的初始化序列如图8所示：

步骤801：框架会创建管理器(Manager)的实例，用于统筹处理所有来自应用的请求信息。

步骤802：Manager负责为不同的类型的应用创建命名空间，应用的类型需要事先定义好，如果不使用任何自定义的命名空间，框架选择创建默认命名空间，此时所有发送请求的应用都被视作是同一类型的应用。

步骤803：然后框架需要创建并启动一个Web服务器，这一点至关重要，服务器端应用或者移动客户端应用都需要通过网络来连接这个服务器，才能达到最终应用间互联通信的目的。此服务器在系统运行期间一直处于工作状态，当无信息交互时，它时刻处在监听状态(监听固定的端口号，根据需求自主设定)。

步骤804：框架使用的是采用事件驱动模型和非阻塞I/0模型。服务器启动时会监听“error”、“request”、“upgrade”及“close”事件，这些事件与客户端封装的javascript脚本所使用一致，服务器为这些事件注册了回调函数，当有事件发生时才会执行某些特定的操作，并且这些回调函数都是异步执行的。如此设计不但会提高资源的利用率，而且也改善了性能。

应用监听到connect事件成功响应后，表示该应用与服务框架连接成功。

应用于框架连接成功后即可通过emit方法向框架发送特定的事件和数据。

应用监听到disconnect事件的响应后，标识该应用于服务框架断开连接。

通信组件接收请求的处理流程如图9所示：

互连通信模块初始化时，服务框架已经注册了各类事件，当有相应的请求从客户端应用发来时，服务框架的Manager类提供一个统一的消息处理接口handleRequest，基于websocket协议的请求是由此接口进入。

如果检测出请求是基于websocket协议的合法请求，框架会创建websocket类的实例，并且创建Websocket库的对象，与客户端应用握手建立连接，之后保持该会话连接，之后服务器端与客户端即可正常通信，此时的互相发送的数据并不包含HTTP协议头等冗余信息，是纯数据。

服务器端与客户端应用发送的数据由框架中的原生Socket实例接收，Socket实例注册监听接收数据的事件，当接收到数据时，回调函数作出响应，可将数据进一步递交至上层消息解析模块。

如果是自定义类型的应用发来的请求，会产生不同类型的Socket实例，承担相应不同类型应用的数据传输任务。

在websocket协议上，数据是通过一系列的帧来传输的。出于安全的考虑，为了避免使网络中间设施(如拦截代理)出现混乱等原因，客户端必须标记所有发往服务器的数据帧。

通信组件处理websocket数据的整体流程如图10所示：

当服务器接收到一个没有标记的数据帧时，服务器会认为本次通话是非法的，它会立即关闭连接，并向客户端反馈一个含有状态码1002(协议错误)的关闭帧信息。

服务器则不能不标记它发给客户端的任何帧。如果客户端检测收到标记了的帧，则必须关闭连接并可能发送1002状态码(协议错误)的关闭帧。

在上述握手连接成功后，在客户端没有收到关闭数据帧之前，客户端或服务器可以在任何时间向对方发送数据帧。当互联通信模块接收到基于websocket协议的数据时，将会根据具体的帧协议对收到的数据帧做解析处理。

原生Socket从网络中获得原始数据帧，将其交给websocket数据解析类处理。

首先解析数据帧中Opcode比特位，它定义了数据帧的类型，包括：后续帧，文本帧，二进制帧，控制帧以及关闭连接帧等等，如果接收到未知的操作码，则接收端必须关闭websocket连接。不同的帧类型，解析其携带的Payload数据方式也不一样的，如收到的数据帧为文本帧，它的有效载荷数据是UTF-8编码的文本数据，则将其交予Parse类处理。

其次要检测数据帧中Mask比特位是否被标记为1，以此来确保这个数据帧是从客户端发往框架的Web服务器的。

将数据帧解析后封装为上层可使用的数据结构，然后通过websocket实例注册的消息监听回调函数，通知并将封装好的数据传递给websocket实例。

websocket实例通过Manager确认该数据是由哪种应用发送的，然后根据不同类型的Socket实例交给上层消息解析模块处理。其中，所述确定数据由哪种应用发送可以为：判断所述数据是由客户端应用或者是由服务器端应用发送的数据。

框架通信组件处理HTTP Polling的流程如图11所示：

Manager管理器接受HTTP Poling请求，通过XHRPOlling对象获取完整的请求报文。

解析请求报文，分别获取请求报文头和消息内容。

根据报文头和消息内容发送一个响应给客户端应用，告知客户端应用是服务器接受请求是否正常。

将获取的消息体交给Parse类解析，将解析封装好的消息体交给Transport类进一步处理。

Transport类中onMessage()方法进一步处理消息，检查消息类型是否有效及根据具体消息类型(心跳，关闭，确认及数据请求等)进入不同的处理逻辑。

模块更深入详细的实现机制在这里不做赘述，从上述模块初始化完成的工作，及web应用端如何使用javascript脚本快速接入服务框架可是得出以下结论：

首先，框架提供给应用开发者使用javascript脚本快速接入框架，一定程度上降低了web实时应用开发者的准入门槛。

其次，框架实现了基于websocket协议的通信方式，意味着开发者可以使用目前很火的html5技术快速研发更多优质的web应用，在提高用户体验的同时促进了交互式应用的发展。另一方面也保证了在浏览器不支持websocket协议的情况下，前端JS脚本能自行选择http polling方式保证消息通信的准确性，且通过动态调节轮询时间提高应用交互的实时性。

可见，通过采用上述方案，就基于确定的通信类型与第二电子设备建立通信连接，在第一电子设备端支持自适应通信，优先选择最佳的高实时全双工通信，在不支持全双工通信的情况下，选择另一种通信模式进行处理。如此，能够结合第一电子设备的情况，尽可能的保证两个电子设备之间通信数据的实时性；另外，由于使用javascript脚本进行通信处理，因此能够提供给应用开发者使用javascript脚本快速接入框架，提升了复用性，并且降低了web实时应用开发者的准入门槛。

实施例三、

本发明实施例提供了一种电子设备，如图12所示，包括：

检测单元1201，用于检测自身支持的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式为全双工通信模式，所述第二通信模式为非全双工通信模式；

信息处理单元1202，用于基于自身支持的通信模式生成通信请求；

通信单元1203，用于发送所述通信请求至第二电子设备，基于所述通信连接，通过网络应用与所述第二电子设备进行数据交互。

上述检测单元1201，用于基于自身使用的网页浏览器，确定自身支持第一通信模式或第二通信模式；其中，所述第一通信模式至少包括基于WebSocket通信协议的通信模式，所述第二通信模式为基于HTTP协议的通信模式。

其中，所述Websocket通信协议为一种全新的双向通信解决方案，是HTML5的一种新协议。它是一种“推”技术，满足浏览器与服务器全双工通信的需求。基于websocket通信的会在在浏览器和服务器之间创建一个单一的Socket，来完成双向“推”与“拉”消息的功能。这种通讯方式是持续性的、有状态的，用户很容易就可以弄明白整个通信流程。websocket可以满足高实时性的要求。鉴于websocket具备的高速全双工的通信特点，它完全满足高实时应用的需求。从通信流程中我们很容易的总结出WebSocket通信的优势：它经过一次握手即建立连接，此后互相通信不在需要传输携带冗余数据的数据头，提高了效率并且节省了网络资源；另一点是它能保证客户端与服务器是全双工异步通信，从而大大的提高了通信的实时性。

所述信息处理单元1202，用于若支持第一通信模式，则基于预设的JavaScript脚本生成包含有第一关键字的通信请求；若仅支持第二通信模式，则基于预设的JavaScript脚本生成包括有第二关键字的通信请求。

需要注意的是，只要第一电子设备安装的浏览器能够支持第一通信模式就会优选采用第一通信模式进行后续的通信流程处理；只有当第一电子设备仅支持第二通信模式的时候，才会基于第二通信模式完成后续的处理。如此，就能够在第一电子设备端支持自适应通信，优先选择最佳的高实时全双工通信，在不支持全双工通信的情况下，选择另一种通信模式进行处理，从而能够结合第一电子设备的实际情况尽可能的保证通信数据的实时性与安全性。

可见，通过采用上述方案，就基于确定的通信类型与第二电子设备建立通信连接，在第一电子设备端支持自适应通信，优先选择最佳的高实时全双工通信，在不支持全双工通信的情况下，选择另一种通信模式进行处理。如此，能够结合第一电子设备的情况，尽可能的保证两个电子设备之间通信数据的实时性；另外，由于使用javascript脚本进行通信处理，因此能够提供给应用开发者使用javascript脚本快速接入框架，提升了复用性，并且降低了web实时应用开发者的准入门槛。

实施例四、

本发明实施例提供了一种电子设备，如图13所示，包括：

第二通信单元1301，用于接收到第一电子设备发来的通信请求；基于所述通信模式，与所述第一电子设备建立通信连接；基于建立的所述通信连接与所述第一电子设备进行数据交互；

处理单元1302，用于基于所述通信请求，确定与所述第一电子设备建立通信连接采用的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式为全双工通信模式，所述第二通信模式为非全双工通信模式。

这里，所述第一电子设备可以为安装有网页浏览器的设备，比如，可以为智能手机、平板电脑、笔记本电脑等。第二电子设备则可以为智能电视。

所述处理单元1302，用于基于预设的JavaScript脚本，对接收到的通信请求进行解析；若解析得到的通信请求为包含有第一关键字的通信请求，则确定通信模式为第一通信模式；否则，确定通信模式为第二通信模式；其中，所述第一通信模式至少包括基于WebSocket通信协议的通信模式，所述第二通信模式为基于HTTP协议的通信模式。

上述第一通信模式中全双工通信模式，比如websocket方式的交互模式可以如图4所示：客户端通过添加有第一关键字的通信请求至服务器侧；所述服务器侧根据接收到的具备第一关键字的通信请求确定接收到了进行Websocket通信的请求，若同意，则向客户端返回同意建立Websocket通信的响应信息；服务器以及客户端双方基于建立的通信连接进行数据传输。

本实施例中对第一电子设备的个数不做限定，比如，图5所示提供的应用场景，所述第二电子设备52安装有具备通信框架的通信单元。框架部署在智能电视端，服务器端的应用也部署在智能电视上。通过无线网络及有线网络使电视与智能手机511、平板电脑512、便携电脑513等第一电子设备处于同一网络中。

优选地，所述处理单元1302，还用于在自身的服务框架侧进行注册，生成应用信息列表；与所述第一电子设备建立通信连接后，通过第二通信单元1301将所述应用信息列表发送给所述第一电子设备，基于绑定的应用进行后续数据交互。

具体可以包括：

第二电子设备开启后，框架会随之启动，初始化服务框架上的Web服务器，启动循环监听程序，等待第一电子设备的连接；

第二电子设备的应用也随之启动，默认状况需要其自动向Web服务器发送连接请求，并将应用的信息注册在Web服务器；

当第一电子设备中安装的应用通过网络向智能电视发送连接请求后，服务框架将已注册的应用信息列表发送给第一电子设备；第一电子设备选择需要绑定的应用，向第二电子设备提交绑定请求；

第二电子设备的框架服务器识别绑定请求将第二电子设备的应用与第一电子设备端的应用进行绑定，之后双方就可以在任意时间异步的发送消息通信。

本实施例中默认状况设置服务器端应用是一对多通信，即一个服务器端应用可以绑定多个客户端应用，意味着框架必须提供广播机制。

第二电子设备的处理单元的总体功能框图如图6所示，框架的通信组件使用C++语言进行开发，C++语言接近汇编语言，高效。编译生成的目标代码质量高，程序执行效率高。记录应用相关信息的数据表存储在系统内存中，减少使用外置数据所产生的交互及系统资源的占用。以上特性保证框架可在嵌入式环境中部署且保证跨平台的移植性。处理单元的框架的前端javascript脚本(图6中JS脚本)支持web应用快速接入框架服务器。

通信组件主要需要满足的需求是：从网络中获取原始套接字请求；提供Web服务器供应用连接；提供对WebSocket通信协议解析的模块；提供最终消息解析分发的功能。Javascript脚本满足需求：是客户端应用通过简单接口与通信组件连接，并且能自行选择最佳通信方式保证客户端应用于通信组件交互的实时性与准确性。

处理单元中还包括有通信组件；其中，所述通信组件中包括有：

底层I/O处理模块，基于异步和事件驱动模式的I/O库。用于提供的内置HTTP包装器很方便的实现了框架底层的HTTP服务器，用来监听处理原始网络套接字。为通信过程中各个流程注册事件，事件没有触发前，该模块一直处于循环监听状态。当该模块监听的事件发生时，事件注册的回调函数就会被调用，处理相应的事务。本模块I/O处理基于epoll机制，它为处理大量用户的并发请求提供了保障。

底层轻量级web服务器，用于为应用程序指定相应的连接端口，为socket对象提供以下的事件：connect、data、end、timeout、drain、error、close等。本模块对这些事件设置了特定的回调函数来处理特定的业务流程。这些回调函数都是异步执行的，当函数注册完成后，都是各自等待相应事件去触发，相互间并无影响。其提供非堵塞的I/O模型，使我们开发的框架伸缩性更好。

中间层通信模块，用于封装统一的且方便使用的API接口供第一电子设备侧的客户端Web应用调用。它可以保证客户端开发者不需要关心底层的传输协议，仅仅使用javascript脚本通过简单的API就可以实现与框架服务器的连接及异步的发送和接收消息；它可以帮助客户端开发人员实现跨浏览器、跨平台的实时应用。重点支持WebSocket的通信方式，所以本模块能保证Web应用与框架服务器可以高速全双工的通信，它完全可以满足高实时应用的需求。

上层消息解析器，用于解析由网络发送过来的数据请求。本层定义了一套Web API，以满足特定应用的通信要求。服务器端应用及客户端应用通过本层可以互相绑定，发送消息，由消息解析器解析后处理转发，以达到相互通信目的。

框架通信组件实现整个web应用间交互的通信流程如图7所示：首先是启动web服务器，设置相应的监听端口，这是服务器的网络入口地址。为了框架可以区别应用是服务器端应用还是远程客户端应用使用命名空间定义应用类型。接着中间通信处理模块进行模块的初始化工作，这点非常重要，因为在这个过程中框架需要大量的注册各种事件，通过回调函数达到异步实时通信的目的，它还要在这个过程中启动我们的轻量级Web服务器，等待用户连接。此后用户通过网络连接服务器，服务器为用户分配标识ID，保存设备名称，设置最大连接数等。最大连接数实质应用希望最多绑定的应用数，超过了这个绑定数，框架需要保证新的绑定请求失败。

其次框架在与应用连接后，通过协议解析模块处理消息。此后框架底层将接收的消息递交给消息解析器，由消息解析器经过推送应用信息、绑定服务器端应用与远程客户端应用、消息处理与转发，即达到了应用间的相互连接通信。

最后，框架还将处理应用关闭的情况。当用户主动递交关闭消息请求关闭时，框架会将其关闭消息通知给与其连接应用，然后断开连接，清除连接信息。当用户因为意外情况(网络终端)或者强制关闭时，框架将启用心跳，超时重连等机制，以保证在设定的时间内用户重新连接即可保持连接，超时后即当作用户关闭，断开连接，清除连接信息。

可见，通过采用上述方案，就基于确定的通信类型与第二电子设备建立通信连接，在第一电子设备端支持自适应通信，优先选择最佳的高实时全双工通信，在不支持全双工通信的情况下，选择另一种通信模式进行处理。如此，能够结合第一电子设备的情况，尽可能的保证两个电子设备之间通信数据的实时性；另外，由于使用javascript脚本进行通信处理，因此能够提供给应用开发者使用javascript脚本快速接入框架，提升了复用性，并且降低了web实时应用开发者的准入门槛。

本发明实施例所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本发明实施例不限制于任何特定的硬件和软件结合。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (10)

1.一种通信处理方法，应用与第一电子设备，其特征在于，所述方法包括：

检测自身支持的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式为全双工通信模式，所述第二通信模式为非全双工通信模式；

基于自身支持的通信模式生成通信请求；

发送所述通信请求至第二电子设备，以使得所述第二电子设备基于所述通信请求，确定与所述第一电子设备建立通信连接采用的通信模式；基于所述通信模式，与所述第一电子设备建立通信连接；

基于所述通信连接，通过网络应用与所述第二电子设备进行数据交互。

2.根据权利要求1所述的方法，其特征在于，所述检测自身支持的通信模式，包括：基于自身使用的网页浏览器，确定自身支持第一通信模式或第二通信模式；

其中，所述第一通信模式至少包括基于WebSocket通信协议的通信模式，所述第二通信模式为基于HTTP协议的通信模式。

3.根据权利要求1或2所述的方法，其特征在于，所述基于自身支持的通信模式生成通信请求，包括：

若支持第一通信模式，则基于预设的JavaScript脚本生成包含有第一关键字的通信请求；

若仅支持第二通信模式，则基于预设的JavaScript脚本生成包括有第二关键字的通信请求。

4.一种通信处理方法，应用于第二电子设备，其特征在于，所述方法包括：

接收到第一电子设备发来的通信请求；

基于所述通信请求，确定与所述第一电子设备建立通信连接采用的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式为全双工通信模式，所述第二通信模式为非全双工通信模式；

基于所述通信模式，与所述第一电子设备建立通信连接；

基于建立的所述通信连接与所述第一电子设备进行数据交互。

5.根据权利要求4所述的方法，其特征在于，所述基于所述通信请求，确定与所述第一电子设备建立通信连接采用的通信模式，包括：

基于预设的JavaScript脚本，对接收到的通信请求进行解析；

若解析得到的通信请求为包含有第一关键字的通信请求，则确定通信模式为第一通信模式；否则，确定通信模式为第二通信模式；

其中，所述第一通信模式至少包括基于WebSocket通信协议的通信模式，所述第二通信模式为基于HTTP协议的通信模式。

6.一种电子设备，其特征在于，包括：

检测单元，用于检测自身支持的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式为全双工通信模式，所述第二通信模式为非全双工通信模式；

信息处理单元，用于基于自身支持的通信模式生成通信请求；

通信单元，用于发送所述通信请求至第二电子设备，基于所述通信连接，通过网络应用与所述第二电子设备进行数据交互。

7.根据权利要求6所述的电子设备，其特征在于，所述检测单元，用于基于自身使用的网页浏览器，确定自身支持第一通信模式或第二通信模式；

其中，所述第一通信模式至少包括基于WebSocket通信协议的通信模式，所述第二通信模式为基于HTTP协议的通信模式。

8.根据权利要求6或7所述的电子设备，其特征在于，所述信息处理单元，用于若支持第一通信模式，则基于预设的JavaScript脚本生成包含有第一关键字的通信请求；若仅支持第二通信模式，则基于预设的JavaScript脚本生成包括有第二关键字的通信请求。

9.一种电子设备，其特征在于，包括：

第二通信单元，用于接收到第一电子设备发来的通信请求；基于所述通信模式，与所述第一电子设备建立通信连接；基于建立的所述通信连接与所述第一电子设备进行数据交互；

处理单元，用于基于所述通信请求，确定与所述第一电子设备建立通信连接采用的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式为全双工通信模式，所述第二通信模式为非全双工通信模式。

10.根据权利要求9所述的电子设备，其特征在于，所述处理单元，用于基于预设的JavaScript脚本，对接收到的通信请求进行解析；若解析得到的通信请求为包含有第一关键字的通信请求，则确定通信模式为第一通信模式；否则，确定通信模式为第二通信模式；

其中，所述第一通信模式至少包括基于WebSocket通信协议的通信模式，所述第二通信模式为基于HTTP协议的通信模式。