CN104580106A - 一种通信方法以及通信装置 - Google Patents

Abstract

本申请公开了一种通信方法以及通信装置，所述方法包括：服务器经由通信信道接收客户端发送的握手请求，其中，所述通信信道具体是支持所述服务器和所述客户端双向进行数据交互的信道；所述服务器基于所述握手请求，生成所述客户端的通信地址；所述服务器经由所述通信信道，将所述服务器的协议版本、所述服务器的连接类型、以及所述客户端的通信地址发送给所述客户端。

Description

一种通信方法以及通信装置

技术领域

本发明涉及通信领域，特别涉及一种通信方法以及通信装置。

背景技术

目前，目前基于BS（Browser/Server，浏览器/服务器模式）结构设计和实现的系统中，服务端和客户端（浏览器）在传输数据时，一般是客户端（浏览器）向服务器端发出请求，而服务端被动响应。因此，若要保证客户端接收数据的实时性，就必须采用客户端定时刷新的方式来保证数据的实时获取。

而采用上述方法的具体原因是http协议的无状态性。一般的Http请求是很短暂的。因此服务端无法实现对客户端的状态监控和识别，进而导致客户端需要采用定时刷新的方式来保证数据的实时获取。

因此，现有技术存在的技术问题是，服务端无法实现对客户端的状态监控和识别，进而导致客户端需要采用定时刷新的方式来保证数据的实时获取的技术问题。

发明内容

本发明提供一种通信方法以及通信装置，用以解决现有技术中存在的服务端无法实现对客户端的状态监控和识别，进而导致客户端需要采用定时刷新的方式来保证数据的实时获取的技术问题。

一方面，本发明通过本申请的一个实施例，提供如下技术方案：

一种通信方法，所述方法包括：服务器经由通信信道接收客户端发送的握手请求，其中，所述通信信道具体是支持所述服务器和所述客户端双向进行数据交互的信道；所述服务器基于所述握手请求，生成所述客户端的通信地址；所述服务器经由所述通信信道，将所述服务器的协议版本、所述服务器的连接类型、以及所述客户端的通信地址发送给所述客户端。

另一方面，本发明通过本申请的另一个实施例提供：

一种通信装置，包括：接收单元，用于经由通信信道接收客户端发送的握手请求，其中，所述通信信道具体是支持所述服务器和所述客户端双向进行数据交互的信道；生成单元，用于基于所述握手请求，生成所述客户端的通信地址；发送单元，用于经由所述通信信道，将所述服务器的协议版本、所述服务器的连接类型、以及所述客户端的通信地址发送给所述客户端。

一方面，本发明通过本申请的一个实施例，提供如下技术方案：

一种通信方法，所述方法包括：客户端经由通信信道发送握手请求给服务器，其中，所述通信信道具体是支持所述服务端和所述客户端双向进行数据交互的信道；所述客户端经由所述通信信道接收所述服务器的协议版本、所述服务器的连接类型、以及所述服务端为所述客户端分配的所述客户端的通信地址。

另一方面，本发明通过本申请的另一个实施例提供：

一种通信装置，包括：发送模块，用于经由通信信道发送握手请求给服务器，其中，所述通信信道具体是支持所述服务端和所述客户端双向进行数据交互的信道；接收模块，用于经由所述通信信道接收所述服务器的协议版本、所述服务器的连接类型、以及所述服务端为所述客户端分配的所述客户端的通信地址。

上述技术方案中的一个或多个技术方案，具有如下技术效果或优点：

在本技术方案中，服务器经由通信信道接收客户端发送的握手请求，其中，通信信道具体是支持服务器和客户端双向进行数据交互的信道。服务器基于握手请求，生成客户端的通信地址。服务器经由通信信道，将服务器的协议版本、服务器的连接类型、以及客户端的通信地址发送给客户端。在两者握手成功之后，服务器可以实时监控客户端的状态，例如，可以基于客户端从不同的通信信道发送的消息判断出客户端的状态，进而解决了有技术中存在的服务端无法实现对客户端的状态监控和识别，进而导致客户端需要采用定时刷新的方式来保证数据的实时获取的技术问题。实现了对和护短的状态监控和识别的技术效果。

附图说明

图1为本申请实施例中通信方法的过程图；

图2为本申请实施例中通信装置的示意图；

图3为本申请实施例中通信方法的另一个过程图；

图4为本申请实施例中通信装置的另一个示意图。

具体实施方式

为了解决现有技术中存在的服务端无法实现对客户端的状态监控和识别，进而导致客户端需要采用定时刷新的方式来保证数据的实时获取的技术问题，本发明实施例提出了一种通信方法以及通信装置，其解决方案总体思路如下：

本发明提供一种通信方法以及通信装置，主要的思路是在应用层增加了一层封装协议，实现服务器能够监控客户端的状态。而封装协议包含了三个主要的部分：通信信道，消息传输方式和消息封装。服务器经由通信信道接收客户端发送的握手请求，其中，通信信道具体是支持服务器和客户端双向进行数据交互的信道。服务器基于握手请求，生成客户端的通信地址。服务器经由通信信道，将服务器的协议版本、服务器的连接类型、以及客户端的通信地址发送给客户端。在两者握手成功之后，服务器可以实时监控客户端的状态，例如，可以基于客户端从不同的通信信道发送的消息判断出客户端的状态，进而解决了有技术中存在的服务端无法实现对客户端的状态监控和识别，进而导致客户端需要采用定时刷新的方式来保证数据的实时获取的技术问题。实现了对和护短的状态监控和识别的技术效果。

下面通过附图以及具体实施例对本发明技术方案做详细的说明，应当理解本发明实施例和实施例中的具体特征是对本发明技术方案的详细的说明，而不是对本发明技术方案的限定，在不冲突的情况下，本发明实施例以及实施例中的技术特征可以相互组合。

实施例一：

在本申请实施例中，提出了一种通信方法。

下面请参看图1，本申请实施例中的方法包括：

S101，服务器经由通信信道接收客户端发送的握手请求。

S102，服务器基于握手请求，生成客户端的通信地址。

S103，服务器经由通信信道，将服务器的协议版本、服务器的连接类型、以及客户端的通信地址发送给客户端。

在具体的实施过程中，通信信道具体是支持服务器和客户端双向进行数据交互的信道。

在本申请实施例中，客户端可以但不限于为浏览器。

本申请实施例在应用层增加了一层封装协议，当客户端为浏览器时，实现服务器能够监控浏览器的状态。当然，所有的数据交互仍然需要在HTTP协议基础上工作，以保证穿越防火墙和浏览器无缝衔接。

而具体的，封装协议包含了三个主要的部分：通信信道，消息传输方式和消息封装。

这三个部分是相辅相成的。

下面首先介绍通信信道。

通信信道具体是支持服务器和客户端双向进行数据交互的信道。另外，其还同时支持消息的点对点传输及消息广播。

通信信道一般由协议信道，服务信道和消息信道构成。

在本申请实施例中，通信信道的描述采用类URI的方式，一个URI对应唯一的一个通信信道，通过URI的扩展支持多级和分类分组。利用通配符支持对信道的批量筛选。

例如：

/MESSAGE/DEVELOP_GROUP代表该信道属于MESSAGE类型下的DEVELOP_GROUP。

/MESSAGE/*代表MESSAGE下所有信道。

下面介绍消息传输方式。

目前定义的通信信道类型包含三种，针对不同信道类型存在不同消息传输方式。

首先是协议信道：

协议信道一般用于传输和协议相关的信息，属于保留信道。例如握手等信息通过协议信道传输。

其次是服务信道：

服务信道是一种特殊信道，所有的客户端都可以向该信道发布信息，但发布在该信道上的信息不会被传递给任何客户端。通过这种类型的信道，可以支持在服务端对一些特殊信息进行保密处理。

最后是消息信道：

在消息信道中，发布在某个消息信道上的信息默认会被广播给所有当前连接到该信道上的其他客户端。

下面介绍消息封装。

在本申请实施例中的协议，并不限制服务器和客户端来往的消息的封装类型，其可以选择xml、json等消息封装格式进行封装。

而封装的消息包含但不仅限于以下内容：

1)通信信道：即通信信道的URI描述格式。

2)客户端通信地址（IP）：在进行握手时由服务器生成的客户端IP，唯一表明一个客户端。

3)数据：字符串格式的信息，具体内容不限。例如可以包含基于BASE64等编码方式编辑的字符串。

4)协议版本：仅在握手时使用，用于协调判断客户端和服务器对协议的解释是否一致。

5)连接类型定义：由于客户端浏览器访问服务端有多种不同技术。例如：长连接，回调，iframe，flash等多种方式。因此，连接类型根据服务器支持的类型和客户端的具体实现进行匹配。

6)参考信息：包括服务器建议客户端通信时遵循的标准。例如：重新连接时间间隔，没有收到相应时重复请求的建议间隔时间等等。

具体的，在本申请实施例的通信方法的实施过程中，服务器和客户端需要进行连接之前，两者必须先通过握手协议。因为通讯设备之间任何实际应用信息的传送总是伴随着一些控制信息的传递，它们按照既定的通讯协议工作，将应用信息安全、可靠、高效地传送到目的地。握手协议就是两个设备在通信之前，要互相的认识一下，然后才能互相传送。

而此时，服务器和客户端需要进行握手时，具体是经由协议信道接收客户端发送的握手请求的。

进一步的，服务器基于握手请求，生成客户端的通信地址。然后，服务器经由通信信道，将服务器的协议版本、服务器的连接类型、以及客户端的通信地址发送给客户端。

因此，通过握手信息，客户端了解服务端的协议版本，支持的连接类型等。从而可以确定是否进行连接操作。

进一步的，在服务器经由通信信道，将服务器的协议版本、服务器的连接类型、以及客户端的通信地址发送给客户端之后，客户端自身会对服务器发送的服务器的协议版本、服务器的连接类型等进行解析。

服务器和客户端就可以执行连接过程。

具体如下：

服务器经由协议信道接收客户端发送的连接请求。

其中，连接请求包括客户端的通信地址，客户端的连接类型。

服务器解析连接请求，获得客户端的连接类型。

基于客户端的连接类型，生成连接响应消息。

服务器经由协议信道，将连接响应消息发送给客户端的通信地址，通知客户端连接成功。

当连接成功之后，两者就可以进行数据交互，例如客户端可以向服务器发布消息，或者订阅消息等等。

具体如下：

当客户端在服务器上发送消息时，经由不同的通信信道，服务器处理消息的方式是不一样的。

当经由服务信道时，具体的实施方式如下：

服务器经由服务信道接收客户端发送的消息发布请求，其中，消息发布请求包括客户端的通信地址，以及消息实体。

服务器将消息实体进行保密处理，并生成第一发布响应消息。

服务器经由服务信道，将第一发布响应消息发送给客户端的通信地址，通知客户端已对消息实体做保密处理。

当经由消息信道时，具体的实施方式如下：

服务器经由消息信道接收客户端发送的消息发布请求，其中，消息发布请求包括客户端的通信地址，以及消息实体。

服务器将消息实体进行发布，并生成第二发布响应消息。

服务器经由消息信道，将第二发布响应消息发送给客户端的通信地址，通知客户端已对消息实体进行发布。

当客户端向服务器订阅消息时，具体的实施方式如下：

服务器经由消息信道接收客户端发送的消息订阅请求，其中，消息订阅请求包括客户端的通信地址。

基于消息订阅请求，生成消息订阅实体。

服务器经由消息信道，将消息订阅实体发送给客户端的通信地址。

基于同一发明构思，下面的实施例介绍上述方法对应的通信装置。

实施例二：

在本申请实施例中，提出了一种通信装置。

下面请参看图2，该通信装置具体包括：

接收单元201，用于经由通信信道接收客户端发送的握手请求，其中，通信信道具体是支持服务器和客户端双向进行数据交互的信道。

生成单元202，用于基于握手请求，生成客户端的通信地址。

发送单元203，用于经由通信信道，将服务器的协议版本、服务器的连接类型、以及客户端的通信地址发送给客户端。

进一步的，通信信道由协议信道，服务信道和消息信道构成。

进一步的，接收单元201，还用于在经由通信信道，将服务器的协议版本、服务器的连接类型、以及客户端的通信地址发送给客户端之后，经由协议信道接收客户端发送的连接请求，其中，连接请求包括客户端的通信地址，客户端的连接类型。

进一步的，通信装置还包括：

解析单元，用于解析连接请求，获得客户端的连接类型。

生成单元202，还用于基于客户端的连接类型，生成连接响应消息。

发送单元203，还用于经由协议信道，将连接响应消息发送给客户端的通信地址，通知客户端连接成功。

进一步的，接收单元201，还用于在通知客户端连接成功之后，服务器经由服务信道接收客户端发送的消息发布请求，其中，消息发布请求包括客户端的通信地址，以及消息实体。

生成单元202，还用于将消息实体进行保密处理，并生成第一发布响应消息。

发送单元203，还用于经由服务信道，将第一发布响应消息发送给客户端的通信地址，通知客户端已对消息实体做保密处理。

进一步的，接收单元201，还用于在通知客户端连接成功之后，经由消息信道接收客户端发送的消息发布请求，其中，消息发布请求包括客户端的通信地址，以及消息实体。

生成单元202，还用于将消息实体进行发布，并生成第二发布响应消息。

发送单元203，还用于经由消息信道，将第二发布响应消息发送给客户端的通信地址，通知客户端已对消息实体进行发布。

进一步的，方法还包括：

接收单元201，还用于在通知客户端连接成功之后，经由消息信道接收客户端发送的消息订阅请求，其中，消息订阅请求包括客户端的通信地址。

生成单元202，还用于基于消息订阅请求，生成消息订阅实体。

发送单元203，还用于经由消息信道，将消息订阅实体发送给客户端的通信地址。

实施例三：

在本申请实施例中，提供了一种通信方法。

下面请参看图3，本申请实施例中的通信方法包括：

S301，客户端经由通信信道发送握手请求给服务器。

S302，客户端经由通信信道接收服务器的协议版本、服务器的连接类型、以及服务端为客户端分配的客户端的通信地址。

在具体的实施过程中，通信信道具体是支持服务端和客户端双向进行数据交互的信道。并且，通信信道由协议信道，服务信道和消息信道构成。

在本申请实施例中，客户端可以但不限于为浏览器。

本申请实施例在应用层增加了一层封装协议，当客户端为浏览器时，实现服务器能够监控浏览器的状态。当然，所有的数据交互仍然需要在HTTP协议基础上工作，以保证穿越防火墙和浏览器无缝衔接。

而具体的，封装协议包含了三个主要的部分：通信信道，消息传输方式和消息封装。

这三个部分是相辅相成的。而这三个部分在上面的实施例中已经有具体的描述，在此本申请不再赘述。

进一步的，本申请实施例是从客户端侧对通信方法进行描述。

在本申请实施例的通信方法的实施过程中，服务器和客户端需要进行连接之前，两者必须先通过握手协议。因为通讯设备之间任何实际应用信息的传送总是伴随着一些控制信息的传递，它们按照既定的通讯协议工作，将应用信息安全、可靠、高效地传送到目的地。握手协议就是两个设备在通信之前，要互相的认识一下，然后才能互相传送。

而在具体的握手过程中，客户端首先会经由协议信道发送握手请求给服务器。

当服务器接收到该握手请求，发送自身的协议版本、连接类型等等之后。对于客户端侧，则会经由协议信道接收服务器的协议版本、服务器的连接类型、以及服务端为客户端分配的客户端的通信地址。

进一步的，通过握手信息，客户端了解服务端的协议版本，支持的连接类型等。从而可以确定是否进行连接操作。

然后可以执行连接操作。

具体如下：

客户端经由协议信道向服务器发送连接请求，其中，连接请求包括客户端的通信地址，客户端的连接类型。

客户端经由协议信道，接收服务器发送的连接响应消息。

当连接成功之后，两者就可以进行数据交互，例如客户端可以向服务器发布消息，或者订阅消息等等。

当客户端在服务器上发送消息时，经由不同的通信信道，客户端接收到服务器处理消息之后，反馈的结果是不一样的。

当经由服务信道时，具体的实施方式如下：

客户端经由服务信道向服务器发送消息发布请求，其中，消息发布请求包括客户端的通信地址，以及消息实体。

客户端经由服务信道，接受第一发布响应消息，获知服务器已对消息实体做保密处理。

当经由消息信道时，具体的实施方式如下：

在客户端经由通信信道接收服务器的协议版本、服务器的连接类型、以及服务端为客户端分配的客户端的通信地址之后，方法还包括：

客户端经由消息信道向服务器发送消息发布请求。

客户端经由消息信道接收第二发布响应消息，获知服务器已对消息实体进行发布。

基于同一发明构思，下面的实施例介绍上述方法对应的通信装置。

实施例二：

在本申请实施例中，提出了一种通信装置。

下面请参看图4，该通信装置具体包括：

发送模块401，用于经由通信信道发送握手请求给服务器，其中，通信信道具体是支持服务端和客户端双向进行数据交互的信道。

接收模块402，用于经由通信信道接收服务器的协议版本、服务器的连接类型、以及服务端为客户端分配的客户端的通信地址。

进一步的，通信信道由协议信道，服务信道和消息信道构成。

进一步的，发送模块401，还用于在经由通信信道接收服务器的协议版本、服务器的连接类型、以及服务端为客户端分配的客户端的通信地址之后，经由协议信道向服务器发送连接请求，其中，连接请求包括客户端的通信地址，客户端的连接类型。

接收模块402，还用于客户端经由协议信道，接收服务器发送的连接响应消息。

进一步的，发送模块401，还用于在经由通信信道接收服务器的协议版本、服务器的连接类型、以及服务端为客户端分配的客户端的通信地址之后，经由服务信道向服务器发送消息发布请求，其中，消息发布请求包括客户端的通信地址，以及消息实体。

接收模块402，还用于经由服务信道，接受第一发布响应消息，获知服务器已对消息实体做保密处理。

进一步的，发送模块401，还用于在经由通信信道接收服务器的协议版本、服务器的连接类型、以及服务端为客户端分配的客户端的通信地址之后，经由消息信道向服务器发送消息发布请求。

接收模块402，还用于经由消息信道接收第二发布响应消息，获知服务器已对消息实体进行发布。

通过本发明的一个或多个实施例，可以实现如下技术效果：

在本实施例中，服务器经由通信信道接收客户端发送的握手请求，其中，通信信道具体是支持服务器和客户端双向进行数据交互的信道。服务器基于握手请求，生成客户端的通信地址。服务器经由通信信道，将服务器的协议版本、服务器的连接类型、以及客户端的通信地址发送给客户端。在两者握手成功之后，服务器可以实时监控客户端的状态，例如，可以基于客户端从不同的通信信道发送的消息判断出客户端的状态，进而解决了有技术中存在的服务端无法实现对客户端的状态监控和识别，进而导致客户端需要采用定时刷新的方式来保证数据的实时获取的技术问题。实现了对和护短的状态监控和识别的技术效果。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器，CD-ROM，光学存储器等）上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (20)

1.一种通信方法，其特征在于，所述方法包括：

服务器经由通信信道接收客户端发送的握手请求，其中，所述通信信道具体是支持所述服务器和所述客户端双向进行数据交互的信道；

所述服务器基于所述握手请求，生成所述客户端的通信地址；

所述服务器经由所述通信信道，将所述服务器的协议版本、所述服务器的连接类型、以及所述客户端的通信地址发送给所述客户端。

2.如权利要求1所述的方法，其特征在于，所述通信信道由协议信道，服务信道和消息信道构成。

3.如权利要求2所述的方法，其特征在于，在所述服务器经由所述通信信道，将所述服务器的协议版本、所述服务器的连接类型、以及所述客户端的通信地址发送给所述客户端之后，所述方法还包括：

所述服务器经由所述协议信道接收所述客户端发送的连接请求，其中，所述连接请求包括所述客户端的通信地址，所述客户端的连接类型；

所述服务器解析所述连接请求，获得所述客户端的连接类型；

基于所述客户端的连接类型，生成连接响应消息；

所述服务器经由所述协议信道，将所述连接响应消息发送给所述客户端的通信地址，通知所述客户端连接成功。

4.如权利要求3所述的方法，其特征在于，在所述通知所述客户端连接成功之后，所述方法还包括：

所述服务器经由所述服务信道接收所述客户端发送的消息发布请求，其中，所述消息发布请求包括所述客户端的通信地址，以及消息实体；

所述服务器将所述消息实体进行保密处理，并生成第一发布响应消息；

所述服务器经由所述服务信道，将所述第一发布响应消息发送给所述客户端的通信地址，通知所述客户端已对所述消息实体做保密处理。

5.如权利要求3所述的方法，其特征在于，在所述通知所述客户端连接成功之后，所述方法还包括：

所述服务器经由所述消息信道接收所述客户端发送的消息发布请求，其中，所述消息发布请求包括所述客户端的通信地址，以及消息实体；

所述服务器将所述消息实体进行发布，并生成第二发布响应消息；

所述服务器经由所述消息信道，将所述第二发布响应消息发送给所述客户端的通信地址，通知所述客户端已对所述消息实体进行发布。

6.如权利要求3所述的方法，其特征在于，在所述通知所述客户端连接成功之后，所述方法还包括：

所述服务器经由所述消息信道接收所述客户端发送的消息订阅请求，其中，所述消息订阅请求包括所述客户端的通信地址；

基于所述消息订阅请求，生成消息订阅实体；

所述服务器经由所述消息信道，将所述消息订阅实体发送给所述客户端的通信地址。

7.一种通信装置，其特征在于，包括：

接收单元，用于经由通信信道接收客户端发送的握手请求，其中，所述通信信道具体是支持所述服务器和所述客户端双向进行数据交互的信道；

生成单元，用于基于所述握手请求，生成所述客户端的通信地址；

发送单元，用于经由所述通信信道，将所述服务器的协议版本、所述服务器的连接类型、以及所述客户端的通信地址发送给所述客户端。

8.如权利要求7所述的通信装置，其特征在于，所述通信信道由协议信道，服务信道和消息信道构成。

9.如权利要求8所述的通信装置，其特征在于，所述接收单元，还用于在经由所述通信信道，将所述服务器的协议版本、所述服务器的连接类型、以及所述客户端的通信地址发送给所述客户端之后，经由所述协议信道接收所述客户端发送的连接请求，其中，所述连接请求包括所述客户端的通信地址，所述客户端的连接类型；

所述通信装置还包括：

解析单元，用于解析所述连接请求，获得所述客户端的连接类型；

所述生成单元，还用于基于所述客户端的连接类型，生成连接响应消息；

所述发送单元，还用于经由所述协议信道，将所述连接响应消息发送给所述客户端的通信地址，通知所述客户端连接成功。

10.如权利要求9所述的通信装置，其特征在于，

所述接收单元，还用于在通知所述客户端连接成功之后，所述服务器经由所述服务信道接收所述客户端发送的消息发布请求，其中，所述消息发布请求包括所述客户端的通信地址，以及消息实体；

所述生成单元，还用于将所述消息实体进行保密处理，并生成第一发布响应消息；

所述发送单元，还用于经由所述服务信道，将所述第一发布响应消息发送给所述客户端的通信地址，通知所述客户端已对所述消息实体做保密处理。

11.如权利要求9所述的通信装置，其特征在于，

所述接收单元，还用于在通知所述客户端连接成功之后，经由所述消息信道接收所述客户端发送的消息发布请求，其中，所述消息发布请求包括所述客户端的通信地址，以及消息实体；

所述生成单元，还用于将所述消息实体进行发布，并生成第二发布响应消息；

所述发送单元，还用于经由所述消息信道，将所述第二发布响应消息发送给所述客户端的通信地址，通知所述客户端已对所述消息实体进行发布。

12.如权利要求9所述的通信装置，其特征在于，

所述接收单元，还用于在通知所述客户端连接成功之后，经由所述消息信道接收所述客户端发送的消息订阅请求，其中，所述消息订阅请求包括所述客户端的通信地址；

所述生成单元，还用于基于所述消息订阅请求，生成消息订阅实体；

所述发送单元，还用于经由所述消息信道，将所述消息订阅实体发送给所述客户端的通信地址。

13.一种通信方法，其特征在于，所述方法包括：

客户端经由通信信道发送握手请求给服务器，其中，所述通信信道具体是支持所述服务端和所述客户端双向进行数据交互的信道；

所述客户端经由所述通信信道接收所述服务器的协议版本、所述服务器的连接类型、以及所述服务端为所述客户端分配的所述客户端的通信地址。

14.如权利要求13所述的方法，其特征在于，所述通信信道由协议信道，服务信道和消息信道构成。

15.如权利要求14所述的方法，其特征在于，在所述客户端经由所述通信信道接收所述服务器的协议版本、所述服务器的连接类型、以及所述服务端为所述客户端分配的所述客户端的通信地址之后，所述方法还包括：

所述客户端经由所述协议信道向所述服务器发送连接请求，其中，所述连接请求包括所述客户端的通信地址，所述客户端的连接类型；

所述客户端经由所述协议信道，接收所述服务器发送的连接响应消息。

16.如权利要求14所述的方法，其特征在于，在所述客户端经由所述通信信道接收所述服务器的协议版本、所述服务器的连接类型、以及所述服务端为所述客户端分配的所述客户端的通信地址之后，所述方法还包括：

所述客户端经由所述服务信道向所述服务器发送消息发布请求，其中，所述消息发布请求包括所述客户端的通信地址，以及消息实体；

所述客户端经由所述服务信道，接受所述第一发布响应消息，获知所述服务器已对所述消息实体做保密处理。

17.如权利要求14所述的方法，其特征在于，在所述客户端经由所述通信信道接收所述服务器的协议版本、所述服务器的连接类型、以及所述服务端为所述客户端分配的所述客户端的通信地址之后，所述方法还包括：

所述客户端经由所述消息信道向所述服务器发送消息发布请求；

所述客户端经由所述消息信道接收第二发布响应消息，获知所述服务器已对所述消息实体进行发布。

18.一种通信装置，其特征在于，包括：

发送模块，用于经由通信信道发送握手请求给服务器，其中，所述通信信道具体是支持所述服务端和所述客户端双向进行数据交互的信道；

接收模块，用于经由所述通信信道接收所述服务器的协议版本、所述服务器的连接类型、以及所述服务端为所述客户端分配的所述客户端的通信地址。

19.如权利要求18所述的通信装置，其特征在于，所述通信信道由协议信道，服务信道和消息信道构成。

20.如权利要求19所述的通信装置，其特征在于，

所述发送模块，还用于在经由所述通信信道接收所述服务器的协议版本、所述服务器的连接类型、以及所述服务端为所述客户端分配的所述客户端的通信地址之后，经由所述协议信道向所述服务器发送连接请求，其中，所述连接请求包括所述客户端的通信地址，所述客户端的连接类型；

所述接收模块，还用于所述客户端经由所述协议信道，接收所述服务器发送的连接响应消息。