客户端状态维护方法、系统、客户端及应用服务器

摘要

本发明公开了一种客户端状态维护方法、系统、客户端及应用服务器，通过接收客户端以固定时间间隔发送的携带有客户端签名信息的心跳包，根据所述客户端签名信息维护客户端的状态。该方法、系统、客户端及应用服务器使得客户端的状态信息可以以很短的固定时间间隔进行更新，从而实现了客户端状态的实时维护。

说明书

技术领域

本发明涉及通信技术领域，特别涉及客户端状态维护方法、系统、客户端及应用服务器。

背景技术

目前，在很多应用领域中，都使用了网页浏览器作为通信客户端，例如一些基于网页的即时通信系统、论坛等。与一般的通信系统类似，基于网页的通信系统中，后台服务器和系统中的每一个客户端都需要实时、准确的了解作为通信客户端的网页浏览器的状态，从而实现相应的功能。

然而，由于网页采用的是无状态的连接方式，因此，现有技术中，一般是通过会话(Session)和Cookie记录并保存客户端的相关信息，并在客户端再次以记录的相关信息对后台服务器进行业务请求时，确认客户端的状态。但是在现有技术中，客户端的现有状态只能在客户端提出业务请求时，才能被后台服务器所获知，如果作为客户端的网页浏览器被关闭，则后台服务器将无法及时得知客户端状态的改变，仍然认为客户端在线，此时，后台服务器提供的一些业务应用将无法正常完成。

从以上描述可以看出，现有技术中，对于客户端状态的获知是不确定的，因此无法进行客户端状态的实时维护，造成业务应用有可能无法正常完成。

发明内容

本发明实施例提供一种客户端状态维护方法，可以实现实时的客户端状态维护。

本发明实施例提供一种客户端状态维护系统，可以实现实时的客户端状态维护。

本发明实施例提供一种客户端，可以实现实时的客户端状态维护。

本发明实施例提供一种应用服务器，可以实现实时的客户端状态维护。

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

一种客户端状态维护方法，该方法包括：

接收客户端以固定时间间隔发送的携带有客户端签名信息的心跳包，根据所述客户端签名信息维护客户端的状态。

一种客户端状态维护系统，该系统包括：

客户端，用于以固定时间间隔发送携带有客户端签名信息的心跳包；

应用服务器，用于接收客户端以固定时间间隔发送的携带有客户端签名信息的心跳包；根据所述客户端签名信息维护客户端的状态。

一种客户端，该客户端包括：

心跳包生成模块，用于生成携带有客户端签名信息的心跳包；

心跳包发送模块，用于将所述心跳包生成模块生成的所述心跳包向应用服务器发送。

一种应用服务器，该服务器包括：

心跳包接收模块，用于接收客户端以固定时间间隔发送的携带有客户端签名信息的心跳包；

客户端状态维护模块，用于根据所述客户端签名信息维护客户端的状态。

由上述的技术方案可见，本发明的这种接收客户端以固定时间间隔发送的携带有客户端签名信息的心跳包，根据所述客户端签名信息维护客户端的状态的客户端状态维护方法、系统、客户端及应用服务器，使得客户端的状态信息可以以很短的固定时间间隔进行更新，从而实现了客户端状态的实时维护。

附图说明

图1为本发明实施例的客户端状态维护方法流程图；

图2为本发明实施例的客户端状态维护系统结构图。

具体实施方式

为使本发明的目的、技术方案及优点更加清楚明白，以下参照附图并举实施例，对本发明进一步详细说明。

本发明实施例主要是利用了心跳包的特性，让客户端以固定时间间隔发送的携带有客户端签名信息的心跳包，并根据心跳包中的客户端签名信息维护客户端的状态，使得客户端的状态信息可以以很短的固定时间间隔进行更新，从而实现了客户端状态的实时维护。

图1为本发明实施例的客户端状态维护方法流程图，如图1所示，该方法包括如下步骤：

步骤101，接收客户端以固定时间间隔发送的携带有客户端签名信息的心跳包。

步骤102，根据所述客户端签名信息维护客户端的状态。

步骤101中，客户端签名信息可以是根据用户输入的用户身份信息，如用户名和密码或可信任的会话(Session)ID等生成的一段字符串。

以社区论坛举例来说，当用户在使用网页客户端浏览社区首页时，需要先进行登录操作，用户输入其身份信息，如用户名和密码或会话(Session)ID后，客户端将通过HTTP协议，使用通信通道将该用户身份信息传送到HTTP服务器，HTTP服务器进行HTTP协议解释后，得到相应的登录请求数据，并将其使用与应用服务器约定的自有协议转发到应用服务器上。

应用服务器接收到用户身份信息后，会根据用户身份信息生成一段字符串，作为该用户的服务器端签名信息并保存，同时，根据用户身份信息生成一段字符串，作为该用户的客户端签名信息。将相对应的客户端签名信息使用自有协议回应HTTP服务器，HTTP服务器收到回应后，并将回应信息转换打包成HTTP响应包，既而回应网页客户端。

当然，一般来说应用服务器对接收到的用户身份信息可以进行合法性验证，如果通过验证，则继续执行后续步骤，如果用户身份信息不合法，则不执行后续步骤，而直接回复客户端用户登录失败。具体的验证方法或是否进行验证，可以根据实际需要而定。

客户端签名信息可以和服务器端签名信息之间含有特定的关系，比如通过某种公式可以相互计算得出，或者相同，只要保证生成的客户端签名信息可以和服务器端签名信息一一对应即可。如果客户端签名信息和服务器端签名信息是相同的，也可以不生成服务器端签名信息，应用服务器只需将客户端签名信息保存下来即可。

网页客户端在接收到应用服务器返回的客户端签名信息后，可以用任何数据存贮方式保存到该网页客户端所在的终端、PC、移动终端等设备中。

如果用户的身份信息验证失败，则用失败信息回应网页客户端，如果验证失败，则无需生成客户端签名信息和服务器端签名信息。

当客户端获得客户端签名信息后，会执行页面中的代码，以固定的时间间隔向应用服务器发送心跳包。

具体过程可以如下：

将客户端签名信息以HTTP协议封装，打包成心跳包，向HTTP服务器发送，HTTP服务器进行HTTP协议解释后，得到相应的心跳信息，并使用HTTP服务器与应用服务器之间的自有协议打包，发往应用服务器进行验证。

步骤102中，应用服务器将会根据收到的客户端签名信息进行验证，若客户端签名信息验证通过，则将客户端的状态置为在线，如果客户端原来的状态就是在线，则这里也可以不做操作，维持客户端的在线状态。

若客户端签名信息没有通过验证，则根据预定的客户端验证失败策略进行处理。具体的验证失败策略可以是：

判断签名信息验证失败的次数是否超过预设的最大允许失败次数，如果超过了预设的最大允许失败次数，则将客户端在线状态置为离线，否则保持客户端状态为在线；或者，若客户端签名信息验证失败，则请求客户端重发客户端签名信息；或者，若客户端签名信息验证失败，则直接将客户端状态置为离线。验证失败策略可以根据具体的需要进行设置。验证失败后也可以向客户端返回验证失败消息，并告知其失败原因。

客户端签名信息验证通过后，应用服务器可以向客户端返回验证成功消息，或者，进一步更换服务器端签名信息与客户端签名信息，并向客户端发送新的客户端签名信息，或者将新的客户端签名信息添加到返回得验证成功消息中，通知客户端，从而降低数据被截取后被重用的可能性，提高系统的安全性。

当客户端收到返回的验证成功或失败的消息后，可以根据验证成功或失败的消息改变自己的状态；如果收到验证成功消息，则继续保持自己的在线状态；若收到验证失败消息，则将状态改为离线。当然具体的状态可能不只离线和在线两种，可以根据需要，自行设定。

如果应用服务器需要更换新的客户端签名信息，则可以将新的客户端签名信息替换原客户端签名信息。

如果网页客户端状态为在线，则该网页客户端与应用服务器便可以使用通信通道进行各种应用功能。如果网页客户端被认为已经下线，则该网页客户端到应用服务器的通信通道也被认为是不可用的。

以上实施例中，实现心跳包以固定间隔时间发送的方法可以使用Ajax或JavaScript等技术实现。且具体时间间隔可以按照需要而定，只要间隔时间足够短，保证实时性即可。客户端签名信息与服务器端签名信息也可以在客户端和服务器端预先设定好。

另外，以上所述的客户端可以是网页浏览器、各种可以浏览网页的客户端程序等。

下面将具体介绍本发明实施例实现以上方法的客户端状态维护系统。

图2为本发明实施例的客户端状态维护系统结构图，如图2所示，该系统包括客户端201和应用服务器203。

客户端201用于以固定时间间隔发送携带有客户端签名信息的心跳包。

应用服务器203用于接收客户端201以固定时间间隔发送的携带有客户端签名信息的心跳包；根据所述客户端签名信息维护客户端201的状态。

为了获取客户端签名信息，所述客户端201可以进一步包括用于发送用户输入的用户身份信息，并接收客户端签名信息的模块。

所述应用服务器203可以进一步包括接收客户端201发送的用户身份信息，根据用户身份信息生成与所述用户对应的服务器端签名信息和客户端签名信息；保存服务器端签名信息，并发送客户端签名信息的模块。

当然，如果客户端201使用HTTP协议，而应用服务器203中没有集成识别HTTP协议信息的功能，那么该系统还可以包括用于协议转换的HTTP服务器202。

HTTP服务器202用于接收客户端201以固定时间间隔发送的，以HTTP协议封装的携带有客户端签名信息的心跳包，并转换为以应用服务器203使用的协议封装的心跳包，向应用服务器203发送。

HTTP服务器202接收客户端201发送的以HTTP协议封装的用户身份信息，并转换为以应用服务器203使用的协议封装的用户身份信息，向应用服务器203发送。接收应用服务器203发送的以应用服务器203使用的协议封装的客户端签名信息，并转换为以HTTP协议封装的客户端签名信息，向客户端201发送。

相应地，应用服务器203接收HTTP服务器202发送的以应用服务器203使用的协议封装的心跳包和用户身份信息，向HTTP服务器202发送以应用服务器203使用的协议封装的客户端签名信息。

另外，以上系统中，如果需要对客户端201发送的用户身份信息进行验证，则应用服务器203中还可以包括用于用户身份信息验证的模块。另外，所述用户身份的验证和客户端签名信息的生成、服务器端签名信息的生成，也可以通过单独的验证服务器实现，验证服务器将生成的客户端签名信息发送给客户端201，将服务器端签名信息发送给应用服务器203即可。

在该系统的客户端201中包括心跳包生成模块204和心跳包发送模块205。

心跳包生成模块204用于生成携带有客户端签名信息的心跳包。

心跳包发送模块205用于将所述心跳包生成模块204生成的所述心跳包向应用服务器203发送。

与用户身份验证过程对应，该客户端201进一步包括：

用户身份信息发送模块207，用于发送用户输入的用户身份信息；

客户端签名信息保存模块206，用于接收客户端签名信息并保存。

上述系统中的应用服务器203包括心跳包接收模块208和客户端状态维护模块209。

心跳包接收模块208用于接收客户端201以固定时间间隔发送的携带有客户端签名信息的心跳包。

客户端状态维护模块209用于根据所述客户端签名信息维护客户端201的状态。

较佳地，该应用服务器203还包括签名信息生成模块210、服务器端签名信息保存模块211和客户端签名信息发送模块212。

签名信息生成模块210用于接收客户端201发送的用户身份信息，根据用户身份信息生成与所述用户对应的服务器端签名信息和客户端签名信息。

服务器端签名信息保存模块211用于保存服务器端签名信息。

客户端签名信息发送模块212，用于发送客户端签名信息。

其中客户端状态维护模块209中包括客户端信息验证单元213和客户端状态设置单元214。

客户端信息验证单元213用于验证客户端签名信息，如客户端签名信息通过验证，则向客户端状态设置单元214发送验证通过消息，否则发送验证失败消息。

客户端状态设置单元214用于接收所述客户端信息验证单元213发送的验证通过消息，将客户端201的状态置为在线；接收所述客户端信息验证单元213发送的验证失败消息，将客户端201的状态置为离线。

若需要对客户签名信息验证失败后做其它处理，所述客户端状态维护模块还可以包括验证失败处理单元215。

验证失败处理单元215用于接收客户端状态信息验证单元213发送的验证失败消息，并根据预设的验证失败处理策略进行处理，按照处理结果向客户端状态设置单元发送验证通过消息或验证失败的消息。具体的失败处理策略可以参考对客户端状态维护方法中对验证失败后的处理方法，这里不再赘述。

当需要让系统中其它由应用服务器203进行状态维护的客户端也同步得到该客户端201的状态，客户端状态维护模块209还可以包括客户端状态发送单元215。

客户端状态发送单元215将所述客户端状态信息向其他客户端或相关的服务器发送。

以上所述的客户端状态维护系统中，HTTP服务器202的功能可以集成于应用服务器203中，或者由单独的验证服务器实现签名信息生成模块210和客户端签名信息发送模块212的功能。或者，应用服务器203可以由多个应用服务器组成分布式应用服务器群来实现，具体系统组成和实现方式可以根据实际需要而定。

由上述的实施例可见，本发明的这种接收客户端以固定时间间隔发送的携带有客户端签名信息的心跳包，根据所述客户端签名信息维护客户端的状态的客户端状态维护方法、系统、客户端及应用服务器，使得客户端的状态信息可以以很短的固定时间间隔进行更新，从而实现了客户端状态的实时维护。

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