CN103051715A - 一种向终端发布通知的方法、相关装置及系统 - Google Patents

Abstract

本发明公开了一种向用户多终端发布通知的方法、相关装置及系统，用于解决现有技术中采用短连接通信的应用无法主动的、即时的向用户终端发布通知的问题。包括：响应终端设备的长连接请求并保持与终端设备的连接；接收并验证终端设备的登陆数据；如果终端设备通过验证，则当接收到来自终端设备的用户与设备的绑定请求时，将终端设备与用户的对应关系保存到用户设备绑定列表；当接收到来自应用服务端的通知时，在用户设备绑定列表中提取与用户绑定的设备的信息；向与用户绑定的设备发送通知。该方案支持实时向已经与用户绑定的终端设备推送通知，并且支持多种智能推送模式，提高了用户体验。

Description

一种向终端发布通知的方法、相关装置及系统

技术领域

本发明涉及通信领域，具体而言，涉及一种向终端发布通知的方法、相关装置及系统。

背景技术

短连接是只有在有数据传输的时候才进行连接，客户－服务器通信/传输数据完毕就关闭连接。在开发采用短连接，例如http协议进行通信的客户－服务器应用程序时，在一些场景下服务端需要即时的、主动的向客户端发送一些通知信息。如天气预报，服务端在预测到一些特殊天气时会主动的、即时的向客户端发送预警信息，例如“大风蓝色预警，预计16日傍晚：渤海区域西北风6到7级，大连附近海域和航线将受影响，请注意防范。”的信息。但实现这样的需求往往比较困难，因为服务端与客户端采用的是短连接通讯，服务端无法直接定位到客户端。业界目前一般采用以下几种方式来解决这个问题：客户端轮询方式、短信方式、短连接长轮询方式，这些方案都存在一定的缺陷，如不断轮询的方式会使服务器端产生较大的压力，短信方式要求客户端必须具备接收短信的能力，而且发送短信还会产生费用，因此增加了开销。此外，业界的一些推送系统都是基于统一类型的终端，如：苹果的APNS、只能支持IOS设备，Google的C2DM只支持android系统终端，如果一个用户拥有多类型终端，期望根据这些设备的在线情况与接收情况实现多终端的智能推送就成了一个难题。

发明内容

本发明提供了一种向终端发布通知的方法、相关装置及系统，用于解决现有技术中采用短连接通信的应用服务端无法主动的、即时的向安装在用户多终端设备上的应用客户端推送通知的问题。

根据本发明的一个方面，提供了一种向终端发布通知的方法，包括：

响应终端设备的长连接请求并保持与终端设备的连接；接收并验证终端设备的登陆数据；如果终端设备通过验证，则当接收到来自终端设备的用户与设备的绑定请求时，将终端设备与用户的对应关系保存到用户设备绑定列表；当接收到来自应用服务端的通知时，在用户设备绑定列表中提取与用户绑定的设备的信息；向与用户绑定的设备发送通知。

进一步地，上述方法还包括：接收来自终端设备与用户解绑请求，在用户设备绑定列表中删除终端设备与用户的对应关系。

进一步地，上述方法还包括：在响应终端设备的长连接请求并保持与终端设备的长连接之后，设置终端设备的状态为在线状态；当终端关机、退出系统或与通知推送服务端断开连接时，设置终端设备的状态为离线状态。

其中，上述向设备列表中的设备发送通知包括：当设备列表中的终端设备在线时向终端设备发送通知。

其中，上述向与用户绑定的设备发送通知包括：优先向设备列表中处于在线状态的终端设备发送通知，通知发送成功后不再向设备列表中后续上线的设备发送通知；如果设备列表中不存在处于在线状态的终端设备，则优先向第一个上线的终端设备发送通知，通知发送成功后不再向设备列表中后续上线的设备发送通知。

根据本发明的另一个方面，提供了一种接收通知的方法，包括：

当终端设备处于开机且与通信网络连接的状态时，主动与通知推送服务端建立长连接；根据终端设备的信息生成登陆数据，将登陆数据发送至通知推送服务端；在终端设备通过推送服务端的验证并且用户在终端设备上登录后，如果终端设备未与用户建立绑定关系，则将用户的信息发送至通知推送服务端，以使通知推送服务端将用户与终端设备进行绑定；接收来自通知推送服务端的通知，根据通知所属的应用将通知分发到终端设备上对应的应用客户端中。

根据本发明的另一个方面，提供了一种向终端发布通知的装置，包括：响应模块，用于响应终端设备的长连接请求并保持与终端设备的连接；验证模块，用于接收并验证终端设备的登陆数据；保存模块，用于当终端设备通过验证，接收到来自终端设备的用户与设备的绑定请求时，终端设备与用户的对应关系保存到用户设备绑定列表；提取模块，用于如果终端设备通过验证，则当接收到来自终端设备的用户与设备的绑定请求时，将终端设备与用户的对应关系保存到用户设备绑定列表；发送模块，用于向与已与用户绑定的设备发送通知。

进一步地，上述装置还包括：解绑模块，用于接收来自终端设备与用户解绑请求，在用户设备绑定列表中删除终端设备与用户的对应关系。

进一步地，上述装置还包括：第一设置模块，用于在响应终端设备的长连接请求并保持与终端设备的长连接之后，设置终端设备的状态为在线状态；第二设置模块，用于当终端关机、退出系统或与通知推送服务端断开连接时，设置终端设备的状态为离线状态。

其中，上述发送模块包括：第一发送单元，用于当设备列表中的终端设备在线时向终端设备发送通知。

其中，上述发送模块包括：第二发送单元，用于优先向设备列表中处于在线状态的终端设备发送通知，通知发送成功后不再向设备列表中后续上线的设备发送通知；第三发送单元，用于如果设备列表中不存在处于在线状态的终端设备，则优先向第一个上线的终端设备发送通知，通知发送成功后不再向设备列表中后续上线的设备发送通知。

根据本发明的又一个方面，提供了一种接收通知的装置，包括：建立模块，用于当终端设备处于开机且与通信网络连接的状态时，主动与通知推送服务端建立长连接；第二发送模块，用于在终端设备通过推送服务端的验证并且用户在终端设备上登录后，如果终端设备未与用户建立绑定关系，将用户的信息发送至通知推送服务端，以使通知推送服务端将用户与终端设备进行绑定；分发模块，用于接收来自通知推送服务端的通知，根据通知所属的应用将通知分发到终端设备上对应的应用客户端中。

根据本发明的再一个方面，提供了一种向终端发布通知的系统，包括：

上述向终端发布通知的装置以及接收通知的装置。

本发明的技术方案中，终端设备与通知推送服务端采用长连接通信方式进行通信，并且将通知发送至用户绑定的设备列表中的终端设备，解决了现有技术中采用短连接通信的应用服务端无法主动的、即时的向安装在用户多终端设备上的应用客户端推送通知的问题。同时，由于服务端与客户端采用长连接通讯方式，可以实时向用户绑定终端列表中的终端推送通知，并且可以向与用户绑定的多个终端发送通知，提高了用户体验。将终端设备与用户信息进行绑定，并将终端设备与用户信息的对应关系保存到用户绑定的设备列表，这样可以实现将应用服务器的通知发布到与用户建立绑定关系的多个终端设备，扩大了通知发布的范围。

附图说明

图1是本发明的向终端发布通知的方法的流程图；

图2为本发明的另一种接收通知的方法的流程图；

图3是本发明的通知推送服务端向终端发送通知的方法流程图；

图4是本发明的终端设备注册与登陆过程的信令流程图；

图5是本发明的终端设备与用户绑定过程的信令流程图；

图6是本发明的通知推送服务端向终端设备推送消息过程的信令流程图；

图7是本发明的向终端发布通知的装置的结构框图；

图8是本发明的接收通知的装置的结构框图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明实施例作进一步详细的说明。

本发明中终端设备与通知推送端采用长连接通信方式，所谓长连接就是指在基于tcp的通讯中，一直保持连接，不管当前是否发送或者接收数据。

图1是本发明的向终端发布通知的方法的流程图。

如图1所示，该方法包括以下步骤：

步骤101：响应终端设备的长连接请求并保持与终端设备的连接；

步骤102：接收并验证终端设备的登陆数据；

步骤103：如果终端设备通过验证，则当接收到来自终端设备的用户与设备的绑定请求时，将终端设备与用户的对应关系保存到用户设备绑定列表；

步骤104：当接收到来自应用服务端的通知时，在用户设备绑定列表中提取与用户绑定的设备的信息；

步骤105：向与用户绑定的设备发送通知。

上述步骤101至步骤105可以是由位于通知推送服务器上的通知推送服务端执行的，具体地可以是该服务端与位于用户的终端设备上的客户端的通讯交互过程。该通知推送服务端与终端设备实时通讯，该服务端可以对外提供不同的通知发布接口，允许多种不同类型的应用服务端调用该通知发布接口向客户端发布通知，例如可以是具备安卓系统的终端、MTK系统的终端、Linxu系统的终端或IOS系统的终端等。同时，用户可以绑定多个终端设备，因此，在上述步骤105中将通知发送至与用户绑定的设备列表中的设备。

在本实施例中，为了避免在用户退出系统后仍然会收到系统的消息，上述方法还可以包括以下步骤：

接收来自所述终端设备与用户解绑请求，在所述用户设备绑定列表中删除所述终端设备与用户的对应关系。

当用户登出系统时，终端设备上的通知推送客户端主动向通知推送服务端发送用户的信息，以便通知推送服务端解除用户与终端设备的绑定关系，具体地，可以是服务端在设备绑定列表中删除用户与终端设备的对应关系。

当通知推送服务端对终端设备的长连接请求进行认证后，响应终端设备的长连接请求，并保持与终端设备的长连接，设置终端设备的状态为在线状态；当终端设备关机或退出登陆时，客户端会主动向通知推送服务端发送下线消息，通知推送服务端根据该下线消息将终端设备的状态设置为离线状态，如果终端设备因网络原因无法与通知推送服务端通信时，通知推送服务端同样将终端设备的状态设置为离线状态。

根据用户绑定的终端是否处于在线状态，可以采用以下几种通知发布模式向终端发布通知：

在线优先模式：优先向用户绑定设备列表中的在线设备推送通知，推送成功后不再向其他不在线的设备推送通知，如果没有在线设备，则将优先向第一个上线的设备推送通知，通知推送成功后不再向其他设备推送通知。

在线模式：仅仅当用户绑定设备列表中的设备在线时，向终端设备推送通知。

标准模式：向用户绑定设备列表中的设备推送通知，无论设备是否在线。

此外，当用户设备不在线时，通知分发服务器可以将用户的通知进行保管，以便在用户上线后将通知再发送给用户设备，为了避免给通知分发服务器造成过大的负担，可以设置离线通知的最长保管期为7天。

图2为本发明的接收通知的方法的流程图。

如图2所示，该方法包括以下步骤：

步骤201：当终端设备处于开机且与通信网络连接的状态时，主动与通知推送服务端建立长连接；

步骤202：根据终端设备的信息生成登陆数据，将登陆数据发送至通知推送服务端；

步骤203：在终端设备通过推送服务端的验证并且用户在终端设备上登录后，如果所述终端设备未与所述用户建立绑定关系，将用户的信息发送至通知推送服务端，以使通知推送服务端将用户与终端设备进行绑定；

步骤204：接收来自通知推送服务端的通知，根据通知所属的应用将通知分发到终端设备上对应的应用客户端中。

上述步骤201至步骤204可以是位于终端设备上的通知推送客户端执行的步骤。其中，根据通知所属的应用将通知分发到终端设备上对应的应用客户端，是根据通知的来源，也就是说通知的创建方来决定将通知发送给终端设备上的哪个客户端。例如，来自飞信通知推送服务端的通知需要发送至终端设备上的飞信推送客户端。

上述步骤202中，具体地，通知推送客户端可以通过系统函数获取设备编号，作为登陆终端设备的名称，采用加密算法对设备编号进行加密运算，生成设备密码，设备的名称以及设备的密码作为登录数据。基于此，通知推送服务端保存有相同的加密算法，当通知推送服务端对设备进行登陆验证时，可以通过该加密算法生成密码并与推送客户端发送的密码进行比对，从而实现对设备的验证。

图3是本发明的通知推送服务端向终端发送通知的方法流程图。

如图3所示，该方法包括以下步骤：

步骤301：当终端设备处于开机且与通信网络连接的状态时，主动与通知推送服务端建立长连接；

步骤302：推送服务端响应终端设备的长连接请求并保持与终端设备的连接；

步骤303：终端设备根据其自身的信息生成登陆数据，将登陆数据提交到通知推送服务端；

步骤304：通知推送服务端根据登陆数据，对终端设备进行验证；

步骤305：如果终端设备通过验证，当该终端设备需要与用户进行绑定时，则将用户信息发送至通知推送服务端；

步骤306：通知推送服务端将终端设备与用户信息的对应关系保存在用户设备绑定列表中；

步骤307：当通知推送服务端接收到来自应用服务端的通知时，在用户设备绑定列表中提取用户绑定的设备的信息；向设备列表中的设备发送通知；

步骤308：终端设备接收来自通知推送服务端的通知，根据通知所属的应用将通知分发到终端设备上对应的应用客户端中。

在上述步骤301之前，应用提供商的应用服务器如果要调用通知推送服务，需要预先将其应用在通知推送服务端进行注册，注册时需要将应用的名称、应用的描述、应用客户端所含终端种类等信息提交给通知推送服务端，可以由系统管理员在服务端将应用注册、注册后的应用服务端会为其分配用于唯一标识该应用的标识符以及应用用于生成数字签名的密钥，该密钥可以在调用通知推送服务时使用。

以下参照图4对步骤301至步骤305中的具体信令流程来进行详细阐述：

如图所示，当用户开启终端设备，终端系统将自动运行通知推送客户端，客户端进行初始化，获取初始化参数等信息，例如服务器端地址、端口号等，通知客户端与通知推送服务端建立长连接，客户端在本地生成登陆信息，通过系统函数获取设备编码号，作为登陆设备名称，可以将设备编号生成设备密码，进行设备登陆，通知推送服务端对设备进行登陆验证，验证成功后返回登陆结果。

以下参照信令流程图5对上述步骤306进行阐述：

用户在终端登陆后，终端将设备编号、帐户ID一并发送给通知推送服务端，以完用户绑定，具体在实际应用中，考虑应用的实用性，可以设置用户只可以绑定同类型的一个终端设备，用户重复绑定同类型设备将会覆盖原来的绑定信息。

以下参照信令流程图6对上述步骤307至步骤308进行阐述：

第三方应用服务器调用通知推送服务，通知推送服务器端对应用服务器进行验证，并查询用户与设备的绑定关系，根据绑定关系将通知内容推送给终端设备。

本发明还提供了一种向终端发布通知的装置，图7是该装置的结构框图。如图7所示，该装置70包括以下组成部分：

响应模块71，用于响应终端设备的长连接请求，保持与终端设备的长连接；

验证模块72，用于接收并验证所述终端设备的登陆数据；

保存模块73，用于如果终端设备通过验证，则当接收到来自终端设备的用户与设备的绑定请求时，将终端设备与用户的对应关系保存到用户设备绑定列表；

提取模块74，用于如果终端设备通过验证，则当接收到来自终端设备的用户与设备的绑定请求时，将终端设备与用户的对应关系保存到用户设备绑定列表；

发送模块75，用于向与用户绑定的设备发送通知。

该装置70可以是位于通知推送服务器上的推送服务端，用于与终端设备上的通知推送客户端进行信息交互，从而实现将来自应用服务器的消息推送至终端设备。

为了避免用户退出系统后，终端设备还会收到来自通知推送服务的通知，上述装置70还可以包括以下模块：

第二接收模块，用于接收用户退出系统时来自终端设备的用户信息；

解除模块，用于接收来自终端设备与用户解绑请求，在用户设备绑定列表中删除终端设备与用户的对应关系。

上述装置70还可以包括设置终端设备在线状态的各模块，以便通知发布服务器根据终端设备的状态来向其发送通知，基于此，该装置可以包括以下模块：

第一设置模块，用于在响应终端设备的长连接请求，保持与终端设备的长连接之后，设置终端设备的状态为在线状态；

第二设置模块，用于当终端关机、退出登陆或与推送服务端断开连接时，设置终端设备的状态为离线状态。

其中，上述装置可以支持不同的通知发布模式，基于此，发送模块可以包括：

第一发送单元，用于当所述设备列表中的终端设备在线时向所述终端设备发送所述通知。

此外上述装置还可以采用另一中通知推送模式，基于此，上述装置还可以包括以下单元：

第二发送单元，用于优先向设备列表中处于在线状态的终端设备发送通知，通知发送成功后不再向设备列表中后续上线的设备发送通知；

第三发送单元，用于如果设备列表中不存在处于在线状态的终端设备，则优先向第一个上线的终端设备发送通知，通知发送成功后不再向设备列表中后续上线的设备发送通知。

图8是本发明的接收通知的装置的结构框图。

如图8所示，该装置80包括以下组成部分：

建立模块81，用于当终端处于开机且具备网络的状态时，主动与推送服务端建立长连接；

生成模块82，用于根据终端设备的信息生成登陆数据，将登陆数据发送至通知推送服务端；

第二发送模块83，用于在终端设备通过推送服务端的验证并且用户在终端设备上登录后，如果所述终端设备未与所述用户建立绑定关系，将用户的信息发送至通知推送服务端，以使通知推送服务端将用户与终端设备进行绑定；

分发模块84，用于接收来自通知推送服务端的通知，根据通知所属的应用将通知分发到终端设备上对应的应用客户端中。

该装置80可以是位于终端上的通知推送客户端。

本发明还提供了一种向终端发布通知的系统，该系统包括上述位于终端设备上的通知推送装置70以及位于通知发布服务器上的接收通知的装置80。

本发明的技术方案，终端设备与通知推送端采用长连接通信方式，并且将通知发送至设备列表中的终端设备，解决了现有技术中服务端与客户端采用短连接通讯方式时，服务端无法直接定位到客户端的问题。同时，由于服务端与客户端采用长连接通讯方式，因此可以实时向用户绑定终端列表中的终端推送通知，在降低开销的同时可以向与用户绑定的多个终端发送通知，同时，由于通知推送服务端向外提供通知推送接口，可供应用服务器调用，从而向终端设备发送通知，实现推送系统支持多类型终端的目的，提高了用户体验。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (13)

1.一种向终端发布通知的方法，其特征在于，包括：

响应终端设备的长连接请求并保持与所述终端设备的连接；

接收并验证所述终端设备的登陆数据；

如果所述终端设备通过验证，则当接收到来自所述终端设备的用户与设备的绑定请求时，将所述终端设备与用户的对应关系保存到用户设备绑定列表；

当接收到来自应用服务端的通知时，在所述用户设备绑定列表中提取与所述用户绑定的设备的信息；

向与所述用户绑定的设备发送通知。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

接收来自所述终端设备与用户解绑请求，在所述用户设备绑定列表中删除所述终端设备与用户的对应关系。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在响应终端设备的长连接请求并保持与所述终端设备的长连接之后，设置所述终端设备的状态为在线状态；

当所述终端关机、退出系统或与通知推送服务端断开连接时，设置所述终端设备的状态为离线状态。

4.根据权利要求3所述的方法，其特征在于，所述向所述设备列表中的设备发送所述通知包括：

当所述设备列表中的终端设备在线时向所述终端设备发送所述通知。

5.根据权利要求3所述的方法，其特征在于，所述向与所述用户绑定的设备发送通知包括：

优先向所述设备列表中处于在线状态的终端设备发送所述通知，所述通知发送成功后不再向所述设备列表中后续上线的设备发送所述通知；

如果所述设备列表中不存在处于在线状态的终端设备，则优先向第一个上线的终端设备发送所述通知，所述通知发送成功后不再向所述设备列表中后续上线的设备发送所述通知。

6.一种接收通知的方法，其特征在于，包括：

当终端设备处于开机且与通信网络连接的状态时，主动与通知推送服务端建立长连接；

根据所述终端设备的信息生成登陆数据，将所述登陆数据发送至所述通知推送服务端；

在所述终端设备通过所述推送服务端的验证并且用户在所述终端设备上登录后，如果所述终端设备未与所述用户建立绑定关系，则将所述用户的信息发送至所述通知推送服务端，以使所述通知推送服务端将所述用户与所述终端设备进行绑定；

接收来自所述通知推送服务端的通知，根据所述通知所属的应用将所述通知分发到所述终端设备上对应的应用客户端中。

7.一种向终端发布通知的装置，其特征在于，包括：

响应模块，用于响应终端设备的长连接请求并保持与所述终端设备的连接；

验证模块，用于接收并验证所述终端设备的登陆数据；

保存模块，用于当所述终端设备通过验证，接收到来自所述终端设备的用户与设备的绑定请求时，将所述终端设备与用户的对应关系保存到用户设备绑定列表；提取模块，用于如果所述终端设备通过验证，则当接收到来自所述终端设备的用户与设备的绑定请求时，将所述终端设备与用户的对应关系保存到用户设备绑定列表；

发送模块，用于向与已与所述用户绑定的设备发送通知。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

解绑模块，用于接收来自所述终端设备与用户解绑请求，在所述用户设备绑定列表中删除所述终端设备与用户的对应关系。

9.根据权利要求7所述的装置，其特征在于，所述装置还包括：

第一设置模块，用于在响应终端设备的长连接请求并保持与所述终端设备的长连接之后，设置所述终端设备的状态为在线状态；

第二设置模块，用于当所述终端关机、退出系统或与通知推送服务端断开连接时，设置所述终端设备的状态为离线状态。

10.根据权利要求9所述的装置，其特征在于，所述发送模块包括：

第一发送单元，用于当所述设备列表中的终端设备在线时向所述终端设备发送所述通知。

11.根据权利要求9所述的装置，其特征在于，所述发送模块包括：

第二发送单元，用于优先向所述设备列表中处于在线状态的终端设备发送所述通知，所述通知发送成功后不再向所述设备列表中后续上线的设备发送所述通知；

第三发送单元，用于如果所述设备列表中不存在处于在线状态的终端设备，则优先向第一个上线的终端设备发送所述通知，所述通知发送成功后不再向所述设备列表中后续上线的设备发送所述通知。

12.一种接收通知的装置，其特征在于，包括：

建立模块，用于当终端设备处于开机且与通信网络连接的状态时，主动与通知推送服务端建立长连接；

第二发送模块，用于在所述终端设备通过所述推送服务端的验证并且用户在所述终端设备上登录后，如果所述终端设备未与所述用户建立绑定关系，将所述用户的信息发送至所述通知所述推送服务端，以使所述通知推送服务端将所述用户与所述终端设备进行绑定；

分发模块，用于接收来自所述通知推送服务端的通知，根据所述通知所属的应用将所述通知分发到所述终端设备上对应的应用客户端中。

13.一种向终端发布通知的系统，其特征在于，包括：

权利要求7与12所述的装置。

Images