消息交互的方法、装置及系统与流程

本发明涉及互联网技术领域，尤其涉及一种消息交互的方法、装置及系统。

背景技术：

随着互联网的飞速发展，大量互联网应用随之出现，关于互联网应用的服务器与客户端的消息交互，主要有以下两种模式：一种是客户端主动向服务器发起请求，服务器接收到请求后返回响应结果。一种是服务器向客户端主动推送消息。上述两种消息交互的方式都存在一定的弊端，对于客户端主动请求的模式，客户端无法精准的获知什么时段是服务器的访问高峰期，因此会经常性的出现服务器系统宕机或资源浪费的情况；对于服务器主动推送消息的模式，会出现服务器响应不及时的现象。

技术实现要素：

鉴于上述问题，本发明提供一种消息交互的方法、装置及系统，用以解决现有的互联网应用中客户端与服务器之间消息交互的方式效率低的问题。

为解决上述技术问题，第一方面，本发明提供了一种消息交互的方法，所述方法包括：

服务器接收到客户端发送的数据请求后，根据抽取随机数算法确定所述客户端下次发送数据请求的时间段，所述数据请求用于向服务器请求服务器更新的数据；

将确定的下次发送数据请求的时间段添加到响应包中返回给所述客户端，使客户端在下次发送数据请求的时间段内，自动向服务器发送数据请求，所述响应包为数据请求对应的响应包。

可选的，在根据抽取随机数算法确定所述客户端下次发送数据请求的时间段之前，所述方法还包括：

将下次进行数据更新后的更新时段平均分割为预设数量的多个子更新时段，所述更新时段为将下次更新的数据下发给所有客户端使客户端进行数据更新的时段；

所述根据抽取随机数算法确定所述客户端下次发送数据请求的时间段包括：

根据抽取随机数算法为所述客户端从多个子更新时段中抽取一个子更新时段确定为所述客户端下次发送数据请求的时间段。

可选的，所述方法还包括：

服务器在不同的时间对不同类型的数据进行更新；

分别为每种类型的数据设置一个对应的更新时段。

可选的，在根据抽取随机数算法确定所述客户端下次发送数据请求的时间段之前，所述方法还包括：

将每种类型数据对应的更新时段平均分割为预设数量的多个子更新时段，得到多个子更新时段组，一种类型的数据对应一个子更新时段组；

所述根据抽取随机数算法确定所述客户端下次发送数据请求的时间段包括：

根据抽取随机数算法依次从不同的子更新时段组中分别抽取一个子更新时段分别确定为客户端下次发送对应数据类型的数据请求的时间段。

可选的，所述根据抽取随机数算法依次从不同的子更新时段组中分别抽取一个子更新时段分别确定为客户端下次发送对应数据类型的数据请求的时间段还包括：

每抽取一个子更新时段后，判断没有被抽取子更新时段的更新时段内是否包含当前抽取的子更新时段；

若包含，则不再对包含当前抽取的子更新时段的更新时段进行抽取。

可选的，在确定所述客户端下次发送数据请求的时间段之后，所述方法还包括：

从下次发送数据请求的时间段中选取任一时刻作为客户端下次发送数据请求的时间；

所述将确定的下次发送数据请求的时间段添加到响应包中返回给所述客户端，包括：

将确定的下次发送数据请求的时间返回给所述客户端。

第二方面，本发明提供了一种消息交互的装置，所述方法包括：

确定单元，用于服务器接收到客户端发送的数据请求后，根据抽取随机数算法确定所述客户端下次发送数据请求的时间段，所述数据请求用于向服务器请求服务器更新的数据；

返回单元，用于将确定的下次发送数据请求的时间段添加到响应包中返回给所述客户端，使客户端在下次发送数据请求的时间段内，自动向服务器发送数据请求，所述响应包为数据请求对应的响应包。

可选的，所述装置还包括：

第一分割单元，用于在根据抽取随机数算法确定所述客户端下次发送数据请求的时间段之前，将下次进行数据更新后的更新时段平均分割为预设数量的多个子更新时段，所述更新时段为将下次更新的数据下发给所有客户端使客户端进行数据更新的时段；

所述确定单元，还用于：

根据抽取随机数算法为所述客户端从多个子更新时段中抽取一个子更新时段确定为所述客户端下次发送数据请求的时间段。

可选的，所述装置还包括：

更新单元，用于服务器在不同的时间对不同类型的数据进行更新；

设置单元，用于分别为每种类型的数据设置一个对应的更新时段。

可选的，所述装置还包括：

第二分割单元，用于在根据抽取随机数算法确定所述客户端下次发送数据请求的时间段之前，将每种类型数据对应的更新时段平均分割为预设数量的多个子更新时段，得到多个子更新时段组，一种类型的数据对应一个子更新时段组；

所述确定单元，还用于：

根据抽取随机数算法依次从不同的子更新时段组中分别抽取一个子更新时段分别确定为客户端下次发送对应数据类型的数据请求的时间段。

可选的，所述确定单元，还包括：

判断模块，用于每抽取一个子更新时段后，判断没有被抽取子更新时段的更新时段内是否包含当前抽取的子更新时段；

抽取模块，用于若包含，则不再对包含当前抽取的子更新时段的更新时段进行抽取。

可选的，所述装置还包括：

选取单元，用于在确定所述客户端下次发送数据请求的时间段之后，从下次发送数据请求的时间段中选取任一时刻作为客户端下次发送数据请求的时间；

所述确定单元，还用于：

将确定的下次发送数据请求的时间返回给所述客户端。

第三方面，本发明提供了一种消息交互的系统，所述系统包括客户端与服务器：

所述客户端，用于向服务器发送数据请求，所述数据请求用于向服务器请求服务器更新的数据；接收服务器返回的响应包，所述响应包中包含下次发送数据请求的时间段；并在下次发送更新请求的时间段时，自动向服务器发送数据请求；

所述服务器，用于接收到客户端发送的数据请求后，根据抽取随机数算法确定所述客户端下次发送数据请求的时间段；将确定的下次发送数据请求的时间段添加到响应包中返回给所述客户端。

借由上述技术方案，本发明提供的消息交互的方法、装置及系统，在客户端向服务器发送数据请求之后，再次向服务器发送数据请求时是根据服务器返回的下次发送数据请求时间段自动发起的。并且下次发送数据请求的时间段是服务器根据抽取随机数算法确定的，因此，可以保证服务器均衡的接收客户端发送的数据请求，不会出现大量的客户端集中发送数据请求的现象，有效的避免服务器出现访问高峰期，甚至宕机的现象，另外，是由客户端向服务器主动发送的请求，所以在一定程度相比于服务器主动推送消息的模式提高了服务器的及时响应性。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例提供的一种消息交互的方法的流程图；

图2示出了本发明实施例提供的另一种消息交互的方法的流程图；

图3示出了本发明实施例提供的又一种消息交互的方法的流程图；

图4示出了本发明实施例提供的一种消息交互的方法的效果图；

图5示出了本发明实施例提供的一种消息交互的装置的组成框图；

图6示出了本发明实施例提供的另一种消息交互的装置的组成框图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

为解决现有的互联网应用中客户端与服务器之间消息交互的方式效率低的问题，本发明实施例提供了一种消息交互的方法，该方法应用于服务器，如图1所示，该方法包括：

101、服务器接收到客户端发送的数据请求后，根据抽取随机数算法确定所述客户端下次发送数据请求的时间段。

其中，数据请求是客户端发送的用于向服务器请求服务器更新的数据的请求。当服务器每次进行数据的更新后，为了保证客户端可以及时为用户提供最新的数据，因此需要向服务器发送数据请求来获取更新的数据。

本实施例中客户端发送数据请求的时间是由服务器确定的，目的是为了统筹安排所有客户端发送数据请求的时间。因此服务器每次接收到客户端发送的数据请求后需要为对应的客户端确定该客户端下次发送数据请求的时间段。

本实施例中应用抽取随机数算法确定客户端下次发送数据请求的时间段的方式为：为每个发送数据请求的客户端按照抽取随机数算法从服务器设定的更新时段中选择一个子更新时段作为客户端下次发送数据请求的时间段。应用抽取随机数算法可以保证各个子更新时段内对应的客户端的数量是较均衡的。其中，更新时段为服务器将下次更新的数据下发给所有客户端使客户端进行数据更新的时段。更新时段是预先设定的，假设上午8：00服务器完成了一次数据的更新，则设定的更新时段可以为8:00之后的任意时段，具体可以为8:00-12:00，或其他的时间段。

102、将确定的下次发送数据请求的时间段添加到响应包中返回给客户端。

将由步骤101确定的下次发送数据请求的时间段添加到响应包中，并将响应包返回给对应的客户端。其中，响应包为数据请求对应的响应包，响应包中包括服务器更新的数据。客户端在接收到响应包之后，会根据响应包中的更新数据进行对应的更新，并且提取响应包中的下次发送数据请求的时间段，设置下次发送数据请求的时间，使在下次发送数据请求的时间段内，自动向服务器发送数据请求。

本发明实施例提供的消息交互的方法，在客户端向服务器发送数据请求之后，再次向服务器发送数据请求时是根据服务器返回的下次发送数据请求时间段自动发起的，其中数据请求用于向服务器请求服务器更新的数据。并且下次发送数据请求的时间段是服务器根据抽取随机数算法确定的，因此，可以保证服务器均衡的接收客户端发送的数据请求，不会出现大量的客户端集中发送数据请求的现象，有效的避免服务器出现访问高峰期，甚至宕机的现象，另外，是由客户端向服务器主动发送的请求，所以在一定程度相比于服务器主动推送消息的模式提高了服务器的及时响应性。

作为图1方法的补充和扩展，本发明实施例还提供了一种消息交互的方法，如图2所示，该方法包括：

201、将下次进行数据更新后的更新时段平均分割为预设数量的多个子更新时段。

其中，更新时段为服务器将下次更新的数据下发给所有客户端使客户端进行数据更新的时段。更新时段是用户设定的，假设上午8:00服务器完成了一次数据的更新，则设定的更新时段可以为8:00之后的任意时段，具体可以为8:00-12:00，或其他的时间段。更新时段的设定是需要使所有的客户端在这个更新时段内获取到本次的更新数据。将更新时段平均分割的目的是为了使所有客户端向服务器发送的数据请求可以更加均匀的分散在更新时段内。

另外，预设数量可以自由设定；也可以根据服务器对应的所有客户端的数量来设定，即依据预设数量与客户端的数量成正比例关系进行设定，客户端数量越多，分割成的子更新时段越多。

202、服务器接收到客户端发送的数据请求后，根据抽取随机数算法为客户端从多个子更新时段中抽取一个子更新时段确定为客户端下次发送数据请求的时间段。

本实施例中应用抽取随机数算法的原理为：以产生随机数的方式为客户端抽取一个子更新时段，以产生随机数的方式抽取可以保证为客户端选择任意一个子更新时段的概率是相等的。对于每一个发送数据请求的客户端都会采用随机数的方式为其抽取一个子更新时段，当服务器对应的需要获取服务器更新数据的客户端的数量级比较大的情况下，可以保证最终更新时段的每个子更新时内段对应的客户端的数量是相对均匀的。客户端数量级越大，客户端在不同的子更新时间段中分散越均匀。分散均匀就可以避免服务器在更新时段内，大量的客户端集中发送数据请求，出现数据请求峰值甚至服务器宕机等现象。

203、从下次发送数据请求的时间段中选取任一时刻作为客户端下次发送数据请求的时间。

由步骤202确定的下次发送数据请求的时间段是一个时间范围，通常在实际应用中该时间范围是一个很小的时间范围，因此通常可以选择发送数据请求的时间段中的任意一个时刻作为客户端下次发送更新请求的时间。

204、将确定的下次发送数据请求的时间返回给客户端。

将由步骤203确定的下次发送数据请求的时间添加到响应包中，并将响应包返回给对应的客户端。其中，响应包为数据请求对应的响应包，响应包中包括服务器更新的数据。客户端在接收到响应包之后，会根据响应包中的更新数据进行对应的更新，并且提取响应包中的下次发送数据请求的时间，设置下次发送数据请求的时间，使到达下次发送数据请求的时间时，自动向服务器发送数据请求。

作为图1方法的补充和扩展，本发明实施例还提供了一种消息交互的方法，如图3所示，该方法包括：

301、分别为每种类型的数据设置一个对应的更新时段。

在实际应用中，服务器在进行数据更新时，通常会存在在不同的时间对不同类型的数据进行更新的情况，因此需要针对每一种类型的数据设置一个对应的更新时段。这种情况下，客户端在获取服务器中的更新数据时，不能一次获取所有类型数据的更新数据，需要分成多次进行获取。

302、将每种类型数据对应的更新时段平均分割为预设数量的多个子更新时段，得到多个子更新时段组。

具体的对每种类型据对应的更新时段平均分割为预设数量的多个子更新时段的实现方式与图2中步骤201中的实现方式相同，此处不再赘述。每一种类型的数据对应的更新时段分割后得到的多个子更新时段记作一个子更新时段组。

303、服务器接收到客户端发送的数据请求后，根据抽取随机数算法依次从不同的子更新时段组中分别抽取一个子更新时段分别确定为客户端下次发送对应数据类型的数据请求的时间段。

首先，按照不同类型数据对饮的更新时段的先后顺序，选择第一个更新时段进行子更新时段的抽取，具体的抽取的方法与图2步骤202中实现抽取的方法是相同的，此处不再赘述。

当第一个更新时段抽取完后，判断没有被抽取子更新时段的更新时段内是否包含当前抽取确定的子更新时段；若包含，则不再对包含当前抽取的子更新时段的更新时段进行抽取。每抽取出一个子更新时段后，都需要判断剩余的没有被抽取子更新时段的更新时段内是否包含当前抽取的子更新时段。直到没有需要进行抽取的更新时段为止。

上述每抽取出一个子更新时段后进行判断操作的原因是：服务器向客户端返回更新的数据时，会将所有当前已经更新的所有类型的更新的数据返回给客户端，因此当客户端在下次发送对应某一种类型的数据请求时，服务器会将该种类型的更新的数据以及已经更新的其他类型数据的更新数据返回给客户端，所以当没有被抽取子更新时段的更新时段内包含当前抽取的子更新时段，则不再对包含当前抽取的子更新时段的更新时段进行抽取。这样也是为了减少客户端发送更新请求的次数。

给出具体的示例进行说明，假设服务器包含三种类型的数据a、b、c三种，若a对应的更新时段为8:00-11:00，b对应的更新时段为10:30-14:00，c对应的更新时段为14:00-17:00，当接收到客户端A发送的数据请求后，先对a对应的更新时段进行子更新时段的抽取，假设抽取后确定的客户端A下次发送对应a的数据请求的时间段为10:35-10:36，而10:35-10:36时间段在b对应的更新时段内不在c对应的更新时段，则服务器在10:35-10:36时间段接收客户端A的数据请求时，会将a以及b的对应的更新的数据都返回给客户端A，因此不需要再对b对应的更新时段进行子更新时间段的抽取，即不需要确定客户端A下次发送对应b的数据请求的时间段，而继续对c对应的更新时段进行子更新时段的抽取，确定客户端下次发送对应c的数据请求的时间段。

304、从下次发送数据请求的时间段中选取任一时刻作为客户端下次发送数据请求的时间。

本步骤的实现方式与图2中步骤203的实现方式相同，此处不再赘述。

305、将确定的下次发送数据请求的时间返回给客户端。

本步骤的实现方式与图2中步骤204的实现方式相同，此处不再赘述。

另外，在实际应用中，存在客户端与服务器之间存在订购关系的情况，即客户端向服务器订购其中某几种类型数据，这种情况下服务器只需要向客户端返回下次发送订购的类型数据对应的数据请求的时间段即可。另外对于这种情况需要说明的是，在确定客户端下次发送数据请求的时间段之前，需要获取客户端订购的数据类型，通常服务器中记录有每个客户端订购的数据类型。

另外，对于服务器与客户端之间存在订购关系的情况，由于不同的客户端有不同的数据需求，因此对于每种类型的数据来讲，对应的有获取需求的客户端的数量是不同，因此对应于图3步骤302中将更新时段分割成多个子更新时段时可以分割为不同预设数量的子更新时段。

为了更清晰的对上述图3中消息交互的方法的效果进行说明，给出一种消息交互的方法的效果图，如图4所示，其中服务器包括两种类型的数据A和B，其中AC之间的时间段为A对应的第一次的更新时段，CE之间的时间段为A对应的第二次的更新时段，BD之间的时间段为B对应的第一次的更新时段，DE之间的时间段为B对应的第二次的更新时段，使用上述消息交互的方法的效果是：相对于A，实现在AC时间段内服务器使需要获取A的更新的数据的所有客户端均匀的发送第一次数据请求，在CE时间段内服务器使需要获取A的更新的数据的所有客户端均匀的发送第二次更新请求；相对于B，实现在BD时间段内服务器使需要获取B的更新的数据的所有客户端均匀的发送第一次更新请求，在DE时间段内使需要获取B的更新的数据的所有客户端均匀的发送第二次更新请求。可以看到，最终可以保证每个客户端在设定的更新时段内都能够向服务器发送数据请求来获取更新的服务数据，并且所有的客户端的数据请求均匀散列在对应的更新时段内，避免了大量客户端集中向服务器发送数据请求造成的数据请求峰值甚至出现服务器宕机等现象。

另外，为了防止客户端在关闭的期间服务器有数据更新，本实施例设置当客户端开启或初始化后自动向服务器发送数据请求，这时的数据请求不需要由服务器确定发送的时间。

进一步的，作为对上述各实施例的实现，本发明实施例的另一实施例还提供了一种消息交互的装置，所述装置位于服务器侧，用于实现上述图1至图3中所述的方法。如图5所示，该装置包括：确定单元31以及返回单元32。

确定单元31，用于服务器接收到客户端发送的数据请求后，根据抽取随机数算法确定客户端下次发送数据请求的时间段，数据请求用于向服务器请求服务器更新的数据；

其中，数据请求是客户端发送的用于向服务器请求服务器更新的数据的请求。当服务器每次进行数据的更新后，为了保证客户端可以及时为用户提供最新的数据，因此需要向服务器发送数据请求来获取更新的数据。

本实施例中客户端发送数据请求的时间是由服务器确定的，目的是为了统筹安排所有客户端发送数据请求的时间。因此服务器每次接收到客户端发送的数据请求后需要为对应的客户端确定该客户端下次发送数据请求的时间段。

本实施例中应用抽取随机数算法确定客户端下次发送数据请求的时间段的方式为：为每个发送数据请求的客户端按照抽取随机数算法从服务器设定的更新时段中选择一个子更新时段作为客户端下次发送数据请求的时间段。应用抽取随机数算法可以保证各个子更新时段内对应的客户端的数量是较均衡的。其中，更新时段为服务器将下次更新的数据下发给所有客户端使客户端进行数据更新的时段。更新时段是预先设定的，假设上午8：00服务器完成了一次数据的更新，则设定的更新时段可以为8:00之后的任意时段，具体可以为8:00-12:00，或其他的时间段。

返回单元32，用于将确定的下次发送数据请求的时间段添加到响应包中返回给客户端，使客户端在下次发送数据请求的时间段内，自动向服务器发送数据请求，响应包为数据请求对应的响应包。

将由确定单元31确定的下次发送数据请求的时间段添加到响应包中，并将响应包返回给对应的客户端。其中，响应包为数据请求对应的响应包，响应包中包括服务器更新的数据。客户端在接收到响应包之后，会根据响应包中的更新数据进行对应的更新，并且提取响应包中的下次发送数据请求的时间段，设置下次发送数据请求的时间，使在下次发送数据请求的时间段内，自动向服务器发送数据请求。

如图6所示，装置还包括：

第一分割单元33，用于在根据抽取随机数算法确定客户端下次发送数据请求的时间段之前，将下次进行数据更新后的更新时段平均分割为预设数量的多个子更新时段，更新时段为将下次更新的数据下发给所有客户端使客户端进行数据更新的时段；

确定单元31，还用于：

根据抽取随机数算法为客户端从多个子更新时段中抽取一个子更新时段确定为客户端下次发送数据请求的时间段。

如图6所示，装置还包括：

更新单元34，用于服务器在不同的时间对不同类型的数据进行更新；

设置单元35，用于分别为每种类型的数据设置一个对应的更新时段。

在实际应用中，服务器在进行数据更新时，通常会存在在不同的时间对不同类型的数据进行更新的情况，因此需要针对每一种类型的数据设置一个对应的更新时段。这种情况下，客户端在获取服务器中的更新数据时，不能一次获取所有类型数据的更新数据，需要分成多次进行获取。

如图6所示，装置还包括：

第二分割单元36，用于在根据抽取随机数算法确定客户端下次发送数据请求的时间段之前，将每种类型数据对应的更新时段平均分割为预设数量的多个子更新时段，得到多个子更新时段组，一种类型的数据对应一个子更新时段组；

确定单元31，还用于：

根据抽取随机数算法依次从不同的子更新时段组中分别抽取一个子更新时段分别确定为客户端下次发送对应数据类型的数据请求的时间段。

如图6所示，确定单元31，还包括：

判断模块311，用于每抽取一个子更新时段后，判断没有被抽取子更新时段的更新时段内是否包含当前抽取的子更新时段；

抽取模块312，用于若包含，则不再对包含当前抽取的子更新时段的更新时段进行抽取。

如图6所示，装置还包括：

选取单元37，用于在确定客户端下次发送数据请求的时间段之后，从下次发送数据请求的时间段中选取任一时刻作为客户端下次发送数据请求的时间；

确定单元31，还用于：

将确定的下次发送数据请求的时间返回给客户端。

本发明实施例提供的消息交互的装置，在客户端向服务器发送数据请求之后，再次向服务器发送数据请求时是根据服务器返回的下次发送数据请求时间段自动发起的，其中数据请求用于向服务器请求服务器更新的数据。并且下次发送数据请求的时间段是服务器根据抽取随机数算法确定的，因此，可以保证服务器均衡的接收客户端发送的数据请求，不会出现大量的客户端集中发送数据请求的现象，有效的避免服务器出现访问高峰期，甚至宕机的现象，另外，是由客户端向服务器主动发送的请求，所以在一定程度相比于服务器主动推送消息的模式提高了服务器的及时响应性。

进一步的，本发明的最后一个实施例还提供了一种消息交互的系统，用以实现图1-图3所示的方法。本系统实施例与前述方法实施例对应，能够实现前述方法实施例中的全部内容。为便于阅读，本系统实施例仅对前述方法实施例中的内容进行概要性描述，不对方法实施例中的细节内容进行逐一赘述。该系统包括客户端以及服务器，其中，所述服务器包括上述图5或图6所示的装置。具体的：

客户端，用于向服务器发送数据请求，数据请求用于向服务器请求服务器更新的数据；接收服务器返回的响应包，响应包中包含下次发送数据请求的时间段；并在下次发送更新请求的时间段时，自动向服务器发送数据请求；

服务器，用于接收到客户端发送的数据请求后，根据抽取随机数算法确定客户端下次发送数据请求的时间段；将确定的下次发送数据请求的时间段添加到响应包中返回给客户端。

本发明实施例提供的消息交互的系统，在客户端向服务器发送数据请求之后，再次向服务器发送数据请求时是根据服务器返回的下次发送数据请求时间段自动发起的，其中数据请求用于向服务器请求服务器更新的数据。并且下次发送数据请求的时间段是服务器根据抽取随机数算法确定的，因此，可以保证服务器均衡的接收客户端发送的数据请求，不会出现大量的客户端集中发送数据请求的现象，有效的避免服务器出现访问高峰期，甚至宕机的现象，另外，是由客户端向服务器主动发送的请求，所以在一定程度相比于服务器主动推送消息的模式提高了服务器的及时响应性。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

可以理解的是，上述方法及装置中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的发明名称(如消息交互的装置)中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。