CN104125249A - 通信终端配置文件的同步系统和方法 - Google Patents

Abstract

通信终端配置文件的同步系统和方法，该系统包括如下模块：推送平台客户端，其发动更新配置请求；推送平台服务器，其发送更新配置应答。该方法包括如下步骤：客户端发动更新配置请求；服务器端发送更新配置应答。

Description

通信终端配置文件的同步系统和方法

技术领域

本申请涉及一种通信终端配置文件的同步系统和方法，属于通信网络的同步机制，属于数字信息传输领域。

背景技术

目前，随着通信终端在通信网络中的广泛应用，尤其是移动网络中通信终端的广泛使用，使得通信终端的配置文件如何及时更新成为非常重要的技术问题。

为了实现通信终端配置文件的及时更新，现有技术中主要存在两种思路。一是通过通信信息本身的优化，二是通过通信机制本身的优化。

第一种思路在于，通过通信信息本身的优化实现通信终端配置文件的及时更新。这一思路是本领域中较少采用的一种方式。采用这一思路的最新现有技术主要表现为LG电子株式会社公开的KR20090065417A号韩国专利申请。该专利申请系一种在移动通信系统中生成和传送数据的方法，其将OFDM信号配置为至少两个子信号，然后通过多个载波信道（例如时分多路模式下的信道和频分多路模式下的信道）进行传输。也就是说，基于OFDM信号生成的多个子信号通过同步信道加以传送，从而是实现配置文件的高效更新。然而，显然上述方式借助于通信信息本身的优化，加重了通信网络的通信负担。

第二种思路在于，通过通信机制本身的优化实现通信终端配置文件的及时更新。这一思路是本领域中较多采用的一种方式。例如，华为科技有限公司提出的WO2010031347号国际专利申请公开了一种多播单频网络中信息同步的机制，其设置主网络控制器和从属网络控制器，主网络控制器用于将多播单频网络配置信息传送到每个从属网络控制器，从而实现主网络控制器和从属网络控制器的同步，满足了多播单频网络空中接口切换和软切换的需要。也就是说，通过主网络控制器和从属网络控制器的设置，提高同步效率。

然而，上述方式显然较大地增加了通信负担，并且增加了通信网络的管理难度。为了较高效率实现通信终端与服务器的数据同步，中兴公司提出的WO2011082632A号国际专利申请公开了一种配置信息的发布机制，其中当P2P网络中的配置信息得以改变的时候，配置文件服务器向计算机网络中的引导节点（bootstrap node）发布改变的配置信息，然后由引导节点向其他非引导节点的通信终端转发该配置信息。通过这种方式，使得P2P网络中的通信终端的配置信息能够与服务器端的配置信息实时同步。类似地，US2011026704A号美国专利申请则公开了一种基于网络配置信息实现用户群的管理的方法，其中用户配置信息存储于服务器，服务器用于维护和管理上述用户配置信息，并且启动相应的用户识别。上述方式均以服务器作为配置信息更新的主动方，较大地增加了服务器的负担。同时，CN1956452A公开了一种实现数据同步的方法，应用于客户端和服务器之间，该方法包括：客户端和服务器中的任一端发送第一同步命令至二者中的另一端；其在发送第一同步命令之前，客户端和服务器确定待同步目录；所述第一同步命令的接收端在收到第一同步命令之后，按接收到的第一同步命令，对所确定的待同步目录进行数据同步。其仅仅给出了客户端发布同步命令的方式，但是并未对于同步机制本身的效率提高提出可行性思路。

现有的方案是每次推送平台服务器上的信息有变化，都要求客户端来同步信息。具体过程参见如说明书附图1所示。应用配置信息的更新，由第三方应用提供商在发布新应用，或者更新应用版本的时候，向推送服务器发起。推送平台服务器在获得更新的配置信息后，将更新通知推送到移动终端上的推送平台客户端。上述推送通过二进制短信或者IP连接等方式实现。之后，移动平台客户端建立新的IP连接或者使用已有的和推送平台的连接，向推送平台服务器发起更新配置请求。最后，推送平台服务器将更新的内容下发给推送平台客户端。至此，整个更新过程结束。直到下次配置信息有更新，这里描述的更新过程，再从头开始。

如图1所描述的应用配置文件的同步过程主要有两个缺点：一方面，同步动作过于频繁，尤其是那些关于非活跃状态的应用（用户很少使用的应用）的信息变更引起的同步，造成用户网络流量的流失和浪费。频繁的同步也会消耗更多的电量，降低用户体验。另一方面，推送服务器并发压力大，也就是说，在推送服务器上的应用配置信息更新后，需要下发大量的更新通知，之后，所有得到通知的推送平台客户端会同时向推送平台服务器发起更新请求。

综上所述，如何实现高效地通信终端配置文件同步，并且同时降低网络通信负担和服务器信息处理负担，成为本领域需要解决的技术问题。

发明内容

为了解决上述技术问题，尤其是存在第三方应用的情况下高效实现通信终端配置文件的同步，使得第三方应用的厂商提供给推送平台服务器的关于第三方应用信息不断更新，在推送平台服务器和推送平台客户端之间进行同步。从而，在推送平台服务器上面的存储的应用配置信息被更新后，在推送平台客户端存储的配置信息及时进行相应的更新。并且，在同步过程中有效降低服务器的计算负担和网络的通信负担。也就是说，本发明所要解决的技术问题是，存在第三方应用的情况下高效实现通信终端配置文件的同步，并且在同步过程中有效降低服务器的计算负担和网络的通信负担。

为了解决上述技术问题，本专利申请提出一种通信终端配置文件的同步系统和方法。具体内容包括：

一种通信终端配置文件同步系统，其包括，推送平台客户端，其发动更新配置请求；推送平台服务器，其发送更新配置应答。

进一步，在该通信终端配置文件同步系统中，当客户端首次启动或者客户端应用配置文件有所损坏并且无法确定由哪些配置文件所致时，客户端发送全同步更新配置请求；当客户端首次启动或者客户端应用配置文件有所损坏并且无法确定由哪些配置文件所致时，服务器端发送全同步更新配置应答。

进一步，在该通信终端配置文件同步系统中，每隔一段时间，客户端发送部分同步更新配置请求；每隔一段时间服务器端发送部分同步更新配置应答。

进一步，在该通信终端配置文件同步系统中，当客户端应用配置文件有所损坏并且可以确定由哪些配置文件所致时，客户端发送部分同步更新配置请求；当客户端应用配置文件有所损坏并且可以确定由哪些配置文件所致时，服务器端发送部分同步更新配置应答。

进一步，在该通信终端配置文件同步系统中，推送平台服务器会将应用配置的最新版本信息包裹在推送消息的消息头中，推送平台客户端收到消息后，将消息头中对应的应用配置版本与存储在终端上的应用配置的版本信息进行比较，如果后者已经过期，则向推送服务器发起对该应用的配置信息的更新请求。

相应地，本发明还提供一种通信终端配置文件的同步方法，其特征在于，客户端发动更新配置请求；服务器端发送更新配置应答。

进一步，在通信终端配置文件同步方法中，当客户端首次启动时，客户端发送全同步更新配置请求；当客户端首次启动时，服务器端发送全同步更新配置应答。

进一步，在通信终端配置文件同步方法中，当客户端应用配置文件有所损坏并且无法确定由哪些配置文件所致时，客户端发送全同步更新配置请求；当客户端应用配置文件有所损坏并且无法确定由哪些配置文件所致时，服务器端发送全同步更新配置应答。

进一步，在通信终端配置文件同步方法中，每隔一段时间，客户端发送部分同步更新配置请求；每隔一段时间服务器端发送部分同步更新配置应答。

进一步，在通信终端配置文件同步方法中，当客户端应用配置文件有所损坏并且可以确定由哪些配置文件所致时，客户端发送部分同步更新配置请求；当客户端应用配置文件有所损坏并且可以确定由哪些配置文件所致时，服务器端发送部分同步更新配置应答。

进一步，在通信终端配置文件同步方法中，推送平台服务器会将应用配置的最新版本信息包裹在推送消息的消息头中。推送平台客户端收到消息后，将消息头中对应的应用配置版本与存储在终端上的应用配置的版本信息进行比较，如果后者已经过期，则向推送服务器发起对该应用的配置信息的更新请求。

本发明的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1是通信终端配置文件同步的现有技术思路图；

图2是推送平台结构原理图；

图3是通信终端配置文件同步的原理图；

图4是通信终端配置文件配置的效果图。

具体实施方式

图1是通信终端配置文件同步的现有技术思路图。其中，应用配置信息的更新，由第三方应用提供商在发布新应用，或者更新应用版本的时候，向推送服务器发起。推送平台服务器在获得更新的配置信息后，将更新通知推送到移动终端上的推送平台客户端。移动平台向推送平台服务器发起更新配置请求，推送平台服务器将更新的内容下发给推送平台客户端。每次更新配置，则循环执行上述过程。由此导致同步动作过于频繁和同步负担较重。

如图2所示，为了向移动终端的第三方应用提供消息推送，设立推送平台。推送平台包括推送平台服务器和推送平台客户端。推送平台建立第三方应用服务器到第三方应用客户端的消息推送通道，将第三方应用服务器的消息，经过推送平台，推送到第三方应用的客户端。当第三方应用厂商发布基于各个移动终端操作系统(比如，Android，iOS，WP等)的应用或者更新应用版本时，要向推送平台提供一些关于应用的一些信息（例如但不限于应用的版本号、运行环境、名称、图标等），推送平台需要把这些信息传递到终端的推送平台客户端，推送平台客户端以配置文件的形式保存这些信息，这些文件就是终端配置文件（或简称为配置文件）。推送平台客户端使用配置文件提供的应用信息，来传递推送消息到第三方应用客户端和针对应用实现推送消息的个性化。

首先，我们将推送平台服务器与推送平台客户端的配置信息同步过程的发起者，由推送平台服务器，改为推送平台客户端。通信流程的示例之一如图3所示。也就是说，在本申请所公开的通信终端配置文件同步系统中，推送平台客户端发动更新配置请求；推送平台服务器发送更新配置应答。在本申请所公开的通信终端配置文件的同步方法中，主要包括以下步骤：客户端发动更新配置请求；服务器端发送更新配置应答。

同时，本申请定义了三种同步方法:全同步(fullsynchronization)：推送平台客户端需要更新全部应用的配置信息；部分同步(partialsynchronization)：推送平台客户端需要更新部分应用的配置信息；单同步(lazysynchronization)：推送平台客户端需要更新某一应用的配置信息。

三种同步方法的具体实现方式如下：

全同步中，推送平台客户端安装后，首次被启动时，推送平台客户端没有任何应用配置信息。在这种情况下，客户端需要向服务器索取全部应用的配置信息。另一个需要实行全同步的场景是，存储在移动终端上的应用的配置文件有损坏的情况下（比如被用户删除或者存储介质损坏），并且不能确定是由哪些应用的配置文件引起的。

部分同步中，每隔一段时间（时间间隔可以由用户设定，或使用默认值，比如一天），推送平台客户端需要向服务器索取部分应用的配置信息。应用的选取，可以由用户选取不同的策略（比如，在近三天内，有过推送消息的应用）。另一个需要实行部分同步的场景是，存储在移动终端上的应用的配置文件有损坏的情况下（比如被用户删除或者存储介质损坏），并且可以确定是由哪些应用的配置文件引起的，可以启动部分同步的工作机制。

单同步中，第三方应用服务器委托推送平台服务器发送消息后，推送平台服务器会将该应用配置的最新版本信息，包裹在推送消息的消息头中。推送平台客户端收到消息后，将消息头中对应的应用配置版本与存储在终端上的应用配置的版本信息进行比较，如果后者已经过期，则向推送服务器发起对该应用的配置信息的更新请求。

推送平台客户端与推送平台服务器的应用配置同步，通过移动运营商提供的移动网络（例如GPRS，EDGE等）或者无线网络（WIFI）通讯。通讯协议可以基于超文本传输协议(HTTP协议)。协议示例如下：

请求：

具体而言，在服务器端，应用的配置信息可由第三方应用厂商再发布新应用或者更新应用版本时，通过推送服务器的网址，在网页中输入，提交。推送服务器将所有应用提交的配置信息保存在数据库中，等待客户端的更新请求。在客户端，推送平台客户端安装后，用户可以启动该客户端。首次启动客户端后，在执行同步配置文件以前，客户端首先需要在推送服务器上注册推送服务。注册过程如下：推送平台客户端向推送平台服务器上报运行环境信息（例如，IMEI,IMSI，终端的操作系统及其版本信息等），服务器根据客户端上报的信息，生成客户端标示符（client id），并将其返回给客户端。在推送平台客户端以后每次更新配置文件，都需要上报客户端标示符给服务器，以明确客户端身份（见前面同步协议中的“client-id”字段）。推送平台客户端完成注册以后，立即建立与推送平台服务器的HTTP连接，启动全同步。协议中，“request-name”字段取值为“fs”，“app-id-list”字段取值为空，表示客户端需要同步符合终端操作系统版本的所有应用。服务器在收到全同步请求以后，根据请求中的客户端标示符，先在数据库中搜索该客户端所在的操作系统信息，之后，在保存应用配置信息的数据库中搜索满足该操作系统的应用配置信息。最后，将这些应用的配置信息作为应答下发给推送平台客户端。推送平台客户端在收到服务器的应答后，解析其内容，将应用的配置文件存储在终端上。本专利并不规定客户端在终端上的配置文件的存储方式，可以依据终端的操作系统而定。下面以基于Android系统的终端为例，加以说明。

在Android终端上，可以将应用的配置信息以文件的形式存储在SD卡上，如图4所示。配置信息包含了APP_VERSION,APP_LOCATION，OS等配置信息。

尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在不脱离本发明的原理和宗旨的情况下在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (12)

1.一种通信终端配置文件同步系统，其包括，

推送平台客户端，其发动更新配置请求；

推送平台服务器，其发送更新配置应答。

2.如权利要求1所述的通信终端配置文件同步系统，其特征在于：当客户端首次启动或者客户端应用配置文件有所损坏并且无法确定由哪些配置文件所致时，客户端发送全同步更新配置请求；

当客户端首次启动或者客户端应用配置文件有所损坏并且无法确定由哪些配置文件所致时，服务器端发送全同步更新配置应答。

3.如权利要求1或2之一所述的通信终端配置文件同步系统，其特征在于：每隔一段时间，客户端发送部分同步更新配置请求；

每隔一段时间服务器端发送部分同步更新配置应答。

4.如权利要求1或2之一所述的通信终端配置文件同步系统，其特征在于：当客户端应用配置文件有所损坏并且可以确定由哪些配置文件所致时，客户端发送部分同步更新配置请求；

当客户端应用配置文件有所损坏并且可以确定由哪些配置文件所致时，服务器端发送部分同步更新配置应答。

5.如权利要求1或2之一所述的通信终端配置文件同步系统，其特征在于，推送平台服务器会将应用配置的最新版本信息包裹在推送消息的消息头中，推送平台客户端收到消息后，将消息头中对应的应用配置版本与存储在终端上的应用配置的版本信息进行比较，如果后者已经过期，则向推送服务器发起对该应用的配置信息的更新请求。

6.一种通信终端配置文件的同步方法，其特征在于，

客户端发动更新配置请求；

服务器端发送更新配置应答。

7.如权利要求6所述的通信终端配置文件同步方法，其特征在于：

当客户端首次启动时，客户端发送全同步更新配置请求；

当客户端首次启动时，服务器端发送全同步更新配置应答。

8.如权利要求6所述的通信终端配置文件同步方法，其特征在于：

当客户端应用配置文件有所损坏并且无法确定由哪些配置文件所致时，客户端发送全同步更新配置请求；

当客户端应用配置文件有所损坏并且无法确定由哪些配置文件所致时，服务器端发送全同步更新配置应答。

9.如权利要求6-8任一项所述的通信终端配置文件同步方法，其特征在于：

每隔一段时间，客户端发送部分同步更新配置请求；

每隔一段时间服务器端发送部分同步更新配置应答。

10.如权利要求6-8任一项所述的通信终端配置文件同步方法，其特征在于：

当客户端应用配置文件有所损坏并且可以确定由哪些配置文件所致时，客户端发送部分同步更新配置请求；

当客户端应用配置文件有所损坏并且可以确定由哪些配置文件所致时，服务器端发送部分同步更新配置应答。

11.如权利要求6-8任一项所述的通信终端配置文件同步方法，其特征在于：推送平台服务器会将应用配置的最新版本信息包裹在推送消息的消息头中。

12.如权利要求11所述的通信终端配置文件同步方法，其特征在于：推送平台客户端收到消息后，将消息头中对应的应用配置版本与存储在终端上的应用配置的版本信息进行比较，如果后者已经过期，则向推送服务器发起对该应用的配置信息的更新请求。