数据交互方法及装置与流程

本发明涉及计算机领域，具体而言，涉及一种数据交互方法及装置。

背景技术：

如今在网络直播过程中，往往有很多播放应用客户端通过网络来观看直播的媒体文件，但是由于每个客户端所处的网络环境不同，对于所播放的原始媒体文件中的同一个分片数据，在到达不同的客户端所在的内容分发网络(Content delivery Network，CDN)的时间也各不相同，尤其是在跨省份甚至跨国家的时候，因而，目前在每个客户端还难以保持完全一致的播放位置。

进一步，很多播放应用为各个客户端配置了基于播放内容进行数据交互的权限，其中，在数据交互的过程中，数据传输的实时性通常都比较高，因而在网络直播过程中，通过网络来观看的各个客户端在进行数据交互时，对于播放位置不同的客户端将难以保证所交互的内容的一致性，如播放位置快的客户端将所观看的内容通过交互方式发布，播放位置慢的客户端将被动接收播放位置快的客户端所观看的内容；播放位置慢的客户端通过交互方式发布内容时，播放位置快的客户端早已观看过上述内容，发布的内容对播放位置快的客户端来说延迟时间较长。也就是说，目前，基于网络直播进行数据交互的过程中，不同的客户端之间存在数据交互的内容无法保持一致的问题。

针对上述的问题，目前尚未提出有效的解决方案。

技术实现要素：

本发明实施例提供了一种数据交互方法及装置，以至少解决基于直播进行数据交互时不同的客户端之间所交互的内容无法保持一致的技术问题。

根据本发明实施例的一个方面，提供了一种数据交互方法，包括：在使用第一账号登录的第一客户端播放媒体文件的过程中，获取上述第一客户端发送的交互请求，其中，上述交互请求携带有上述第一客户端播放上述媒体文件的第一播放位置，上述交互请求用于请求获取使用第二账号登录的第二客户端在播放上述媒体文件时，在第一会话发布的第一交互数据，上述第二账号通过上述第一会话与上述第一账号进行数据交互；根据上述第一播放位置判断是否满足向上述第一客户端推送上述第一交互数据的推送条件，其中，上述推送条件用于控制上述第一客户端在播放到上述媒体文件中的目标播放位置之后接收到上述第一交互数据，上述目标播放位置位于上述第一播放位置之后；在满足上述推送条件时，向上述第一客户端推送上述第一交互数据。

根据本发明实施例的另一方面，还提供了一种数据交互装置，包括：第一获取单元，用于在使用第一账号登录的第一客户端播放媒体文件的过程中，获取上述第一客户端发送的交互请求，其中，上述交互请求携带有上述第一客户端播放上述媒体文件的第一播放位置，上述交互请求用于请求获取使用第二账号登录的第二客户端在播放上述媒体文件时，在第一会话发布的第一交互数据，上述第二账号通过上述第一会话与上述第一账号进行数据交互；判断单元，用于根据上述第一播放位置判断是否满足向上述第一客户端推送上述第一交互数据的推送条件，其中，上述推送条件用于控制上述第一客户端在播放到上述媒体文件中的目标播放位置之后接收到上述第一交互数据，上述目标播放位置位于上述第一播放位置之后；推送单元，用于在满足上述推送条件时，向上述第一客户端推送上述第一交互数据。

根据本发明实施例的另一方面，还提供了一种数据交互系统，该系统包括：终端，安装有使用第一账号登录的第一客户端，用于发送交互请求，其中，上述交互请求携带有上述第一客户端播放媒体文件的第一播放位置，上述交互请求用于请求获取使用第二账号登录的第二客户端在播放上述媒体文件时，在第一会话发布的第一交互数据，上述第二账号通过上述第一会话与上述第一账号进行数据交互；服务器，在播放上述媒体文件的过程中，获取上述第一客户端发送的上述交互请求；根据上述第一播放位置判断是否满足向上述第一客户端推送上述第一交互数据的推送条件，其中，上述推送条件用于控制上述第一客户端在播放到上述媒体文件中的目标播放位置之后接收到上述第一交互数据，上述目标播放位置位于上述第一播放位置之后；在满足上述推送条件时，向上述第一客户端推送上述第一交互数据。

在本发明实施例中，通过判断交互请求所携带的第一客户端播放媒体文件的第一播放位置来判断是否向第一客户端推送第一交互数据，从而实现控制第一客户端在播放到媒体文件中位于第一播放位置之后的目标播放位置之后接收到第一交互数据，而并不是在接收到交互请求时直接推送第一交互数据，以克服相关技术中播放媒体文件的不同客户端之间由于网络延时所导致的交互内容不一致的问题，避免对第一客户端造成媒体文件内容的剧透，进而实现在保证数据交互一致性的同时，达到提高数据交互的交互效率的效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的一种可选的数据交互方法的应用环境示意图；

图2是根据本发明实施例的一种可选的数据交互方法的流程图；

图3是根据本发明实施例的一种可选的数据交互方法的示意图；

图4是根据本发明实施例的另一种可选的数据交互方法的示意图；

图5是根据本发明实施例的又一种可选的数据交互方法的示意图；

图6是根据本发明实施例的又一种可选的数据交互方法的示意图；

图7是根据本发明实施例的又一种可选的数据交互方法的示意图；

图8是根据本发明实施例的一种可选的数据交互装置的示意图；

图9是根据本发明实施例的一种可选的数据交互服务器的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

在本发明实施例中，提供了一种上述数据交互方法的实施例。作为一种可选的实施方式，该数据交互方法可以但不限于应用于如图1所示的应用环境中，其中，终端102中安装有使用第一账号登录的第一客户端，在该第一客户端播放媒体文件的过程中，终端102通过网络104向服务器106发送交互请求，其中，交互请求携带有第一客户端播放媒体文件的第一播放位置，交互请求用于请求获取使用第二账号登录的第二客户端在播放媒体文件时，在第一会话发布的第一交互数据，第二账号通过第一会话与第一账号进行数据交互；服务器106根据第一播放位置判断是否满足向第一客户端推送第一交互数据的推送条件，其中，推送条件用于控制第一客户端在播放到媒体文件中的目标播放位置之后接收到第一交互数据，目标播放位置位于第一播放位置之后；并在判断出满足推送条件时，向第一客户端推送第一交互数据。

在本实施例中，在使用第一账号登录的第一客户端播放媒体文件的过程中，服务器通过利用接收到的第一客户端发送的交互请求中所携带的第一客户端播放媒体文件的第一播放位置，来判断是否满足向第一客户端推送第一交互数据的推送条件，从而实现控制第一客户端在播放到媒体文件中位于第一播放位置之后的目标播放位置之后接收到第一交互数据，以克服相关技术中播放媒体文件的不同客户端之间由于网络延时所导致的交互内容不一致的问题，避免客户端在数据交互过程中出现媒体文件内容剧透，以保证数据交互的一致性和交互效率。

可选地，在本实施例中，上述终端可以包括但不限于以下至少之一：手机、平板电脑、笔记本电脑、台式PC机、数字电视及其他运行有媒体文件播放应用客户端的硬件设备。上述网络可以包括但不限于以下至少之一：广域网、城域网、局域网。上述只是一种示例，本实施例对此不做任何限定。

根据本发明实施例，提供了一种数据交互方法，如图2所示，该方法包括：

S202，在使用第一账号登录的第一客户端播放媒体文件的过程中，获取第一客户端发送的交互请求，其中，交互请求携带有第一客户端播放媒体文件的第一播放位置，交互请求用于请求获取使用第二账号登录的第二客户端在播放媒体文件时，在第一会话发布的第一交互数据，第二账号通过第一会话与第一账号进行数据交互；

S204，根据第一播放位置判断是否满足向第一客户端推送第一交互数据的推送条件，其中，推送条件用于控制第一客户端在播放到媒体文件中的目标播放位置之后接收到第一交互数据，目标播放位置位于第一播放位置之后；

S206，在满足推送条件时，向第一客户端推送第一交互数据。

可选地，在本实施例中，上述数据交互方法可以但不限于应用于媒体文件播放应用中，基于对媒体文件的播放，在不同账号之间进行关于媒体文件的数据交互，通过判断交互请求所携带的第一客户端播放媒体文件的第一播放位置来判断是否向第一客户端推送第一交互数据，从而实现控制第一客户端在播放到媒体文件中位于第一播放位置之后的目标播放位置之后接收到第一交互数据，而并不是在接收到交互请求时直接推送第一交互数据，以克服相关技术中播放媒体文件的不同客户端之间由于网络延时所导致的交互内容不一致的问题，避免对第一客户端造成媒体文件内容的剧透，进而实现在保证数据交互一致性的同时，达到提高数据交互的交互效率的效果。其中，第一客户端与第二客户端所播放的同一媒体文件可以但不限于为直播媒体文件。上述仅是一种示例，本实施例中对此不做任何限定。

需要说明的是，目前常用的通过弹幕进行数据交互的方式中，所发布的内容往往是与播放位置相匹配的，也就是说，在播放到对应的播放位置时，客户端才能看到所发布的内容，且对于播放同一媒体文件的客户端，播放进度慢的客户端可以看到播放进度快的客户端发布的内容，相反，播放进度快的客户端却无法看到播放进度快的客户端发布的内容，即各个客户端只能实现单向数据交互，各个客户端之间无法实现双向交互，因而数据交互的效率较低；此外，由于播放进度慢的客户端并不会提前观看到播放进度快的客户端发布的内容，因此也不存在剧透的问题。

可选地，在本实施例中，第一会话可以但不限于基于观看同一媒体文件的账号建立，如正在使用第一账号观看媒体文件A的第一客户端可以通过邀请的方式，与使用第二账号也在观看媒体文件A的第二客户端建立第一会话。此外，在本实施例中，上述第一会话还可以但不限于在接收到解散指令后，解散会话中的所有成员账号。也就是说，上述第一会话可以但不限于为临时会话。

需要说明的是，在本实施例中，上述第一会话中的账号可以但不限于通过不同的应用客户端邀请添加。假设正在使用第一账号观看媒体文件A的第一客户端(媒体文件播放应用客户端)，可以通过即时通讯应用邀请账号a加入第一会话，还可以通过微博应用邀请账号b加入第一会话，还可以通过社区空间应用邀请账号c加入第一会话，如图3所示，已成功通过即时通讯应用邀请账号a。

进一步，在本实施例中，用于创建上述第一会话或解散上述第一会话的操作按钮可以但不限于设置在媒体文件的播放界面，本实施例中对此不做任何限定。

可选地，在本实施例中，根据第一播放位置判断是否满足向第一客户端推送第一交互数据的推送条件包括：

S1，获取第二账号在第一会话发布第一交互数据的发布时间；

S2，根据第一播放位置与第一交互数据的发布时间判断是否满足推送条件。

需要说明的是，在本实施例中，上述发布时间可以但不限于为自然时间，且在该发布时间第二客户端中媒体文件的播放进度为第二播放位置，第一客户端中媒体文件的播放进度为第三播放位置，这里第三播放位置在第二播放位置之前，即，第二客户端的播放进度快于第一客户端的播放进度。此外，在本实施例中，上述第一播放位置可以但不限于与第三播放位置重合，也可以但不限于在第三播放位置之后，本实施例中对此不做任何限定。

可选地，在本实施例中，S2，根据第一播放位置与第一交互数据的发布时间判断是否满足推送条件包括：

S21，根据发布时间获取第二客户端在发布第一交互数据时媒体文件被播放至的第二播放位置，其中，在发布第一交互数据时，在第一客户端媒体文件被播放至第三播放位置，第三播放位置在第二播放位置之前；

S22，获取第二播放位置与第一播放位置二者之间的第一时间差；

S23，判断第一时间差是否小于等于预定阈值；

S24，在第一时间差小于等于预定阈值时，向第一客户端推送第一交互数据。

也就是说，通过将第二客户端发布第一交互数据的发布时间转换为第二播放位置，实现对第一播放位置与第二播放位置的比对，若二者之间的第一时间差小于等于预定阈值，则向第一客户端推送上述第一交互数据，否则，拒绝向第一客户端推送上述第一交互数据。

例如，如图4所示，在自然时间第20s，播放进度较快的客户端B(第二客户端)在第20s的播放位置发布了第一交互数据，播放进度较慢的客户端A(第一客户端)在第10s的播放位置发送了交互请求，则服务器在通过对交互请求中携带的第一播放位置判断是否满足推送请求，从而使第一客户端在第10s的播放位置之后的目标播放位置接收到第一交互数据，以达到保证不同客户端之间的数据交互的内容的一致性。

可选地，在本实施例中，上述预定阈值可以但不限于大于零，且小于等于第二播放位置与第三播放位置二者之间的时间差。需要说明的是，上述预定阈值用于在保证数据交互的实时性的情况下，减少播放进度快的客户端所发布的数据对播放进度慢的客户端的内容剧透。

可选地，在本实施例中，在第一时间差大于预定阈值时，不仅拒绝向第一客户端推送上述第一交互数据，还可以但不限于还指示第一客户端调整在下一次发送用于请求获取第一交互数据的交互请求之前的等待间隔，以使第一客户端在等待间隔后再次发送用于请求获取第一交互数据。

需要说明的是，在本实施例中，在按照等待间隔等待一段时间后，这时再次发送的交互请求所对应的播放进度已满足推送请求，则第一客户端将在目标播放位置接收到服务器推送的第二客户端所发布的第二交互数据。

可选地，在本实施例中，在获取第一客户端发送的交互请求之前，还包括：获取服务器中存储的在第一会话中已发布、且未推送给第一客户端的交互数据的发布时间；按照发布时间的顺序依次获取发布时间所对应的播放位置与第一播放位置之间的第二时间差，其中，第二账号所发布的第一交互数据的发布时间所对应的播放位置与第一播放位置之间的第二时间差最小；响应交互请求将第一交互数据作为推送给第一客户端的数据。

也就是说，在第一会话中包括多个账号在进行数据交互时，服务器可以但不限于按照发布时间的顺序依次获取发布时间所对应的播放位置与第一播放位置之间的第二时间差，以将第二时间差最小的客户端发布的交互数据，发送给发送交互请求的第一客户端。

通过本申请提供的实施例，通过判断交互请求所携带的第一客户端播放媒体文件的第一播放位置来判断是否向第一客户端推送第一交互数据，从而实现控制第一客户端在播放到媒体文件中位于第一播放位置之后的目标播放位置之后接收到第一交互数据，而并不是在接收到交互请求时直接推送第一交互数据，以克服相关技术中播放媒体文件的不同客户端之间由于网络延时所导致的交互内容不一致的问题，避免对第一客户端造成媒体文件内容的剧透，进而实现在保证数据交互一致性的同时，达到提高数据交互的交互效率的效果。其中，第一客户端与第二客户端所播放的同一媒体文件可以但不限于为直播媒体文件。上述仅是一种示例，本实施例中对此不做任何限定。

作为一种可选的方案，根据第一播放位置判断是否满足向第一客户端推送第一交互数据的推送条件包括：

S1，获取第二账号在第一会话发布第一交互数据的发布时间；

S2，根据第一播放位置与第一交互数据的发布时间判断是否满足推送条件。

可选地，在本实施例中，步骤S2，根据第一播放位置与第一交互数据的发布时间判断是否满足推送条件包括：

S21，根据发布时间获取第二客户端在发布第一交互数据时媒体文件被播放至的第二播放位置，其中，在发布第一交互数据时，在第一客户端媒体文件被播放至第三播放位置，第三播放位置在第二播放位置之前；

S22，获取第二播放位置与第一播放位置二者之间的第一时间差；

S23，判断第一时间差是否小于等于预定阈值；

S24，在第一时间差小于等于预定阈值时，向第一客户端推送第一交互数据。

可选地，为了保证数据的实时性交互，避免延迟时间太长，在本实施例中，上述预定阈值的配置范围可以但不限于大于零，且小于等于第二播放位置与第三播放位置二者之间的时间差。上述仅是一种示例，本实施例中对此不做任何限定。

具体结合图5所示进行说明，假设在自然时间第20s，播放进度较快的客户端B(即第二客户端)在第20s的第二播放位置发布了第一交互数据，播放进度较慢的客户端A(即第一客户端)在第18s的第一播放位置发送了交互请求，则服务器将通过对该交互请求中携带的第一播放位置判断是否小于预定阈值(假设预定阈值为5)，这里根据上述示例，20-18＝2<5，即判断出小于预定阈值5，则可以向第一客户端推送第一交互数据。

通过本申请提供的实施例，通过将发布时间转换为第二客户端在发布第一交互数据时媒体文件被播放至的第二播放位置，进一步根据第二播放位置与第一播放位置之间的第一时间差判断是否小于等于预定阈值，从而实现利用可配置的预定阈值来控制是否向第一客户端推送第一交互数据，以避免由于数据交互内容不一致导致的剧透问题。

作为一种可选的方案，在判断第一时间差是否小于等于预定阈值之后，还包括：

S1，在第一时间差大于预定阈值时，则向第一客户端发送调整指令，其中，调整指令用于拒绝向第一客户端推送第一交互数据，并用于指示第一客户端调整在下一次发送用于请求获取第一交互数据的交互请求之前的等待间隔，以使第一客户端在等待间隔后再次发送用于请求获取第一交互数据。

具体结合图6所示进行说明，假设在自然时间第20s，播放进度较快的客户端B(即第二客户端)在第20s的第二播放位置发布了第一交互数据，播放进度较慢的客户端A(即第一客户端)在第13s的第一播放位置发送了交互请求，则服务器将通过对该交互请求中携带的第一播放位置判断是否小于预定阈值(假设预定阈值为5)，这里根据上述示例，20-13＝7>5，即判断出大于预定阈值5，则向第一客户端发送调整指令，其中，调整指令用于拒绝向第一客户端推送第一交互数据，还用于指示第一客户端调整在下一次发送用于请求获取第一交互数据的交互请求之前的等待间隔，以使第一客户端在等待间隔后再次发送用于请求获取第一交互数据。这里，假设等待间隔为2s，则可以通知第一客户端在第13+2＝15s的播放位置再次发送交互请求以获取上述第二账号发布的第一交互数据。

通过本申请提供的实施例，在第一时间差大于预定阈值时，通过向第一客户端发送调整指令，以拒绝向第一客户端推送第一交互数据，并指示第一客户端调整在下一次发送用于请求获取第一交互数据的交互请求之前的等待间隔，从而实现准确控制第一客户端在等待间隔后再次发送用于请求以获取第一交互数据，以便于第一客户端在目标播放位置可以接收到第一交互数据，达到提高数据交互的准确率，进而保证第一客户端与第二客户端数据交互的一致性和数据交互效率。

作为一种可选的方案，向第一客户端发送调整指令包括：

S1，获取第二播放位置与预定阈值之间的第一差值；

S2，获取第一差值与第一播放位置之间的第二差值作为等待间隔；

S3，向第一客户端发送携带有等待间隔的调整指令。

具体结合以下示例进行说明，仍以上述示例举例，假设在自然时间第20s，播放进度较快的客户端B(即第二客户端)在第20s的第二播放位置发布了第一交互数据，播放进度较慢的客户端A(即第一客户端)在第13s的第一播放位置发送了交互请求，则服务器将通过对该交互请求中携带的第一播放位置判断是否小于预定阈值(假设预定阈值为5)。

进一步，在本示例中，上述等待间隔可以但不限于根据以下方式计算得到：

20-5＝15，

15-13＝2。

其中，15为第二播放位置20与预定阈值5之间的第一差值，2为第一差值与第一播放位置之间的第二差值，也就是说，调整指令中携带的用于控制第一客户端所等待的等待间隔可以为2s。

通过本申请提供的实施例，通过上述方式计算获取调整指令中所携带的等待间隔，从而实现准确控制第一客户端获取第一交互数据的时间，提高数据交互的准确性和交互效率。

作为一种可选的方案，在获取第一客户端发送的交互请求之前，还包括：

S1，获取服务器中存储的在第一会话中已发布、且未推送给第一客户端的交互数据的发布时间；

S2，按照发布时间的顺序依次获取发布时间所对应的播放位置与第一播放位置之间的第二时间差，其中，第二账号所发布的第一交互数据的发布时间所对应的播放位置与第一播放位置之间的第二时间差最小；

S3，响应交互请求将第一交互数据作为推送给第一客户端的数据。

可选地，在本实施例中，服务器中可以但不限于存储了在第一会话中已发布、且未推送给第一客户端的多个交互数据及对应的发布时间，这里的多个交互数据可以但不限于为一个或多个客户端在第一会话中发布的数据。

需要说明的是，在本实施例中，在发布时间不同时，可以但不限于按照发布时间的顺序，依次将发布时间转换为在对应客户端中所播放的媒体文件的播放位置，获取上述播放位置与第一播放位置之间的第二时间差中的最小值，将该最小值对应的发布时间发布的交互数据作为推送给第一客户端的数据；此外，在本实施例中，在发布时间相同时，由于播放进度不同，则上述发布时间在对应客户端中所播放的媒体文件中分别对应的播放位置也不同，还是可以通过获取上述播放位置与第一播放位置之间的第二时间差中的最小值，并将该最小值对应的发布时间发布的交互数据作为推送给第一客户端的数据，从而实现对交互一致性的控制。

通过本申请提供的实施例，获取服务器中存储的在第一会话中已发布、且未推送给第一客户端的交互数据的发布时间；并按照发布时间的顺序依次获取发布时间所对应的播放位置与第一播放位置之间的第二时间差，利用第二时间差中的最小值获取作为推送给第一客户端的数据，从而保证数据交互的完整性，避免遗漏交互数据。

作为一种可选的方案，在获取第一客户端发送的交互请求之前，还包括：

S1，接收第一客户端发送的邀请操作指令，其中，邀请操作指令用于邀请第二账号与第一账号加入第一会话；

S2，向第二客户端发送邀请请求，以邀请第二客户端所使用的第二账号加入第一会话。

可选地，在本实施例中，在接收第一客户端发送的邀请操作指令之前，还包括：在第一客户端播放媒体文件时，接收对位于媒体文件的播放画面上的会话创建按钮执行的点击操作所生成的邀请操作指令。

具体结合图7所示示例进行说明，通过点击位于媒体文件的播放画面上所显示的邀请按钮(即会话创建按钮)来生成用于邀请邀请第二账号加入第一会话的操作指令。

例如，如图3所示，正在使用第一账号观看媒体文件A的第一客户端(媒体文件播放应用客户端)，可以通过即时通讯应用邀请账号a加入第一会话，还可以通过微博应用邀请账号b加入第一会话，还可以通过社区空间应用邀请账号c加入第一会话，如图3所示，已成功通过即时通讯应用邀请账号a。

通过本申请提供的实施例，通过基于对媒体文件的播放，在不同账号之间创建用于对关于媒体文件的内容进行数据交互的会话，以实现对媒体文件的实时交互。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

实施例2

根据本发明实施例，还提供了一种用于实施上述数据交互方法的数据交互装置，如图8所示，该装置包括：

1)第一获取单元802，用于在使用第一账号登录的第一客户端播放媒体文件的过程中，获取第一客户端发送的交互请求，其中，交互请求携带有第一客户端播放媒体文件的第一播放位置，交互请求用于请求获取使用第二账号登录的第二客户端在播放媒体文件时，在第一会话发布的第一交互数据，第二账号通过第一会话与第一账号进行数据交互；

2)判断单元804，用于根据第一播放位置判断是否满足向第一客户端推送第一交互数据的推送条件，其中，推送条件用于控制第一客户端在播放到媒体文件中的目标播放位置之后接收到第一交互数据，目标播放位置位于第一播放位置之后；

3)推送单元806，用于在满足推送条件时，向第一客户端推送第一交互数据。

可选地，在本实施例中，上述数据交互方法可以但不限于应用于媒体文件播放应用中，基于对媒体文件的播放，在不同账号之间进行关于媒体文件的数据交互，通过判断交互请求所携带的第一客户端播放媒体文件的第一播放位置来判断是否向第一客户端推送第一交互数据，从而实现控制第一客户端在播放到媒体文件中位于第一播放位置之后的目标播放位置之后接收到第一交互数据，而并不是在接收到交互请求时直接推送第一交互数据，以克服相关技术中播放媒体文件的不同客户端之间由于网络延时所导致的交互内容不一致的问题，避免对第一客户端造成媒体文件内容的剧透，进而实现在保证数据交互一致性的同时，达到提高数据交互的交互效率的效果。其中，第一客户端与第二客户端所播放的同一媒体文件可以但不限于为直播媒体文件。上述仅是一种示例，本实施例中对此不做任何限定。

需要说明的是，目前常用的通过弹幕进行数据交互的方式中，所发布的内容往往是与播放位置相匹配的，也就是说，在播放到对应的播放位置时，客户端才能看到所发布的内容，且对于播放同一媒体文件的客户端，播放进度慢的客户端可以看到播放进度快的客户端发布的内容，相反，播放进度快的客户端却无法看到播放进度快的客户端发布的内容，即各个客户端只能实现单向数据交互，各个客户端之间无法实现双向交互，因而数据交互的效率较低；此外，由于播放进度慢的客户端并不会提前观看到播放进度快的客户端发布的内容，因此也不存在剧透的问题。

可选地，在本实施例中，第一会话可以但不限于基于观看同一媒体文件的账号建立，如正在使用第一账号观看媒体文件A的第一客户端可以通过邀请的方式，与使用第二账号也在观看媒体文件A的第二客户端建立第一会话。此外，在本实施例中，上述第一会话还可以但不限于在接收到解散指令后，解散会话中的所有成员账号。也就是说，上述第一会话可以但不限于为临时会话。

需要说明的是，在本实施例中，上述第一会话中的账号可以但不限于通过不同的应用客户端邀请添加。假设正在使用第一账号观看媒体文件A的第一客户端(媒体文件播放应用客户端)，可以通过即时通讯应用邀请账号a加入第一会话，还可以通过微博应用邀请账号b加入第一会话，还可以通过社区空间应用邀请账号c加入第一会话，如图3所示，已成功通过即时通讯应用邀请账号a。

进一步，在本实施例中，用于创建上述第一会话或解散上述第一会话的操作按钮可以但不限于设置在媒体文件的播放界面，本实施例中对此不做任何限定。

可选地，在本实施例中，根据第一播放位置判断是否满足向第一客户端推送第一交互数据的推送条件包括：

S1，获取第二账号在第一会话发布第一交互数据的发布时间；

S2，根据第一播放位置与第一交互数据的发布时间判断是否满足推送条件。

需要说明的是，在本实施例中，上述发布时间可以但不限于为自然时间，且在该发布时间第二客户端中媒体文件的播放进度为第二播放位置，第一客户端中媒体文件的播放进度为第三播放位置，这里第三播放位置在第二播放位置之前，即，第二客户端的播放进度快于第一客户端的播放进度。此外，在本实施例中，上述第一播放位置可以但不限于与第三播放位置重合，也可以但不限于在第三播放位置之后，本实施例中对此不做任何限定。

可选地，在本实施例中，判断模块包括：

(1)第一获取子模块，用于根据发布时间获取第二客户端在发布第一交互数据时媒体文件被播放至的第二播放位置，其中，在发布第一交互数据时，在第一客户端媒体文件被播放至第三播放位置，第三播放位置在第二播放位置之前；

(2)第二获取子模块，用于获取第二播放位置与第一播放位置二者之间的第一时间差；

(3)判断子模块，用于判断第一时间差是否小于等于预定阈值；

(4)推送子模块，用于在第一时间差小于等于预定阈值时，向第一客户端推送第一交互数据。

也就是说，通过将第二客户端发布第一交互数据的发布时间转换为第二播放位置，实现对第一播放位置与第二播放位置的比对，若二者之间的第一时间差小于等于预定阈值，则向第一客户端推送上述第一交互数据，否则，拒绝向第一客户端推送上述第一交互数据。

例如，如图4所示，在自然时间第20s，播放进度较快的客户端B(第二客户端)在第20s的播放位置发布了第一交互数据，播放进度较慢的客户端A(第一客户端)在第10s的播放位置发送了交互请求，则服务器在通过对交互请求中携带的第一播放位置判断是否满足推送请求，从而使第一客户端在第10s的播放位置之后的目标播放位置接收到第一交互数据，以达到保证不同客户端之间的数据交互的内容的一致性。

可选地，在本实施例中，上述预定阈值可以但不限于大于零，且小于等于第二播放位置与第三播放位置二者之间的时间差。需要说明的是，上述预定阈值用于在保证数据交互的实时性的情况下，减少播放进度快的客户端所发布的数据对播放进度慢的客户端的内容剧透。

可选地，在本实施例中，在第一时间差大于预定阈值时，不仅拒绝向第一客户端推送上述第一交互数据，还可以但不限于还指示第一客户端调整在下一次发送用于请求获取第一交互数据的交互请求之前的等待间隔，以使第一客户端在等待间隔后再次发送用于请求获取第一交互数据。

需要说明的是，在本实施例中，在按照等待间隔等待一段时间后，这时再次发送的交互请求所对应的播放进度已满足推送请求，则第一客户端将在目标播放位置接收到服务器推送的第二客户端所发布的第二交互数据。

可选地，在本实施例中，在获取第一客户端发送的交互请求之前，还包括：获取服务器中存储的在第一会话中已发布、且未推送给第一客户端的交互数据的发布时间；按照发布时间的顺序依次获取发布时间所对应的播放位置与第一播放位置之间的第二时间差，其中，第二账号所发布的第一交互数据的发布时间所对应的播放位置与第一播放位置之间的第二时间差最小；响应交互请求将第一交互数据作为推送给第一客户端的数据。

也就是说，在第一会话中包括多个账号在进行数据交互时，服务器可以但不限于按照发布时间的顺序依次获取发布时间所对应的播放位置与第一播放位置之间的第二时间差，以将第二时间差最小的客户端发布的交互数据，发送给发送交互请求的第一客户端。

通过本申请提供的实施例，通过判断交互请求所携带的第一客户端播放媒体文件的第一播放位置来判断是否向第一客户端推送第一交互数据，从而实现控制第一客户端在播放到媒体文件中位于第一播放位置之后的目标播放位置之后接收到第一交互数据，而并不是在接收到交互请求时直接推送第一交互数据，以克服相关技术中播放媒体文件的不同客户端之间由于网络延时所导致的交互内容不一致的问题，避免对第一客户端造成媒体文件内容的剧透，进而实现在保证数据交互一致性的同时，达到提高数据交互的交互效率的效果。其中，第一客户端与第二客户端所播放的同一媒体文件可以但不限于为直播媒体文件。上述仅是一种示例，本实施例中对此不做任何限定。

作为一种可选的方案，判断单元804包括：

1)获取模块，用于获取第二账号在第一会话发布第一交互数据的发布时间；

2)判断模块，用于根据第一播放位置与第一交互数据的发布时间判断是否满足推送条件。

可选地，在本实施例中，判断模块包括：

(1)第一获取子模块，用于根据发布时间获取第二客户端在发布第一交互数据时媒体文件被播放至的第二播放位置，其中，在发布第一交互数据时，在第一客户端媒体文件被播放至第三播放位置，第三播放位置在第二播放位置之前；

(2)第二获取子模块，用于获取第二播放位置与第一播放位置二者之间的第一时间差；

(3)判断子模块，用于判断第一时间差是否小于等于预定阈值；

(4)推送子模块，用于在第一时间差小于等于预定阈值时，向第一客户端推送第一交互数据。

可选地，为了保证数据的实时性交互，避免延迟时间太长，在本实施例中，上述预定阈值的配置范围可以但不限于大于零，且小于等于第二播放位置与第三播放位置二者之间的时间差。上述仅是一种示例，本实施例中对此不做任何限定。

具体结合图5所示进行说明，假设在自然时间第20s，播放进度较快的客户端B(即第二客户端)在第20s的第二播放位置发布了第一交互数据，播放进度较慢的客户端A(即第一客户端)在第18s的第一播放位置发送了交互请求，则服务器将通过对该交互请求中携带的第一播放位置判断是否小于预定阈值(假设预定阈值为5)，这里根据上述示例，20-18＝2<5，即判断出小于预定阈值5，则可以向第一客户端推送第一交互数据。

通过本申请提供的实施例，通过将发布时间转换为第二客户端在发布第一交互数据时媒体文件被播放至的第二播放位置，进一步根据第二播放位置与第一播放位置之间的第一时间差判断是否小于等于预定阈值，从而实现利用可配置的预定阈值来控制是否向第一客户端推送第一交互数据，以避免由于数据交互内容不一致导致的剧透问题。

作为一种可选的方案，还包括：

1)发送子模块，用于在判断第一时间差是否小于等于预定阈值之后，在第一时间差大于预定阈值时，则向第一客户端发送调整指令，其中，调整指令用于拒绝向第一客户端推送第一交互数据，并用于指示第一客户端调整在下一次发送用于请求获取第一交互数据的交互请求之前的等待间隔，以使第一客户端在等待间隔后再次发送用于请求获取第一交互数据。

具体结合图6所示进行说明，假设在自然时间第20s，播放进度较快的客户端B(即第二客户端)在第20s的第二播放位置发布了第一交互数据，播放进度较慢的客户端A(即第一客户端)在第13s的第一播放位置发送了交互请求，则服务器将通过对该交互请求中携带的第一播放位置判断是否小于预定阈值(假设预定阈值为5)，这里根据上述示例，20-13＝7>5，即判断出大于预定阈值5，则向第一客户端发送调整指令，其中，调整指令用于拒绝向第一客户端推送第一交互数据，还用于指示第一客户端调整在下一次发送用于请求获取第一交互数据的交互请求之前的等待间隔，以使第一客户端在等待间隔后再次发送用于请求获取第一交互数据。这里，假设等待间隔为2s，则可以通知第一客户端在第13+2＝15s的播放位置再次发送交互请求以获取上述第二账号发布的第一交互数据。

通过本申请提供的实施例，在第一时间差大于预定阈值时，通过向第一客户端发送调整指令，以拒绝向第一客户端推送第一交互数据，并指示第一客户端调整在下一次发送用于请求获取第一交互数据的交互请求之前的等待间隔，从而实现准确控制第一客户端在等待间隔后再次发送用于请求以获取第一交互数据，以便于第一客户端在目标播放位置可以接收到第一交互数据，达到提高数据交互的准确率，进而保证第一客户端与第二客户端数据交互的一致性和数据交互效率。

作为一种可选的方案，发送子模块通过以下步骤实现向第一客户端发送调整指令：

S1，获取第二播放位置与预定阈值之间的第一差值；

S2，获取第一差值与第一播放位置之间的第二差值作为等待间隔；

S3，向第一客户端发送携带有等待间隔的调整指令。

具体结合以下示例进行说明，仍以上述示例举例，假设在自然时间第20s，播放进度较快的客户端B(即第二客户端)在第20s的第二播放位置发布了第一交互数据，播放进度较慢的客户端A(即第一客户端)在第13s的第一播放位置发送了交互请求，则服务器将通过对该交互请求中携带的第一播放位置判断是否小于预定阈值(假设预定阈值为5)。

进一步，在本示例中，上述等待间隔可以但不限于根据以下方式计算得到：

20-5＝15，

15-13＝2。

其中，15为第二播放位置20与预定阈值5之间的第一差值，2为第一差值与第一播放位置之间的第二差值，也就是说，调整指令中携带的用于控制第一客户端所等待的等待间隔可以为2s。

通过本申请提供的实施例，通过上述方式计算获取调整指令中所携带的等待间隔，从而实现准确控制第一客户端获取第一交互数据的时间，提高数据交互的准确性和交互效率。

作为一种可选的方案，还包括：

1)第二获取单元，用于在获取第一客户端发送的交互请求之前，获取服务器中存储的在第一会话中已发布、且未推送给第一客户端的交互数据的发布时间；

2)第三获取单元，用于按照发布时间的顺序依次获取发布时间所对应的播放位置与第一播放位置之间的第二时间差，其中，第二账号所发布的第一交互数据的发布时间所对应的播放位置与第一播放位置之间的第二时间差最小；

3)确定单元，用于响应交互请求将第一交互数据作为推送给第一客户端的数据。

可选地，在本实施例中，服务器中可以但不限于存储了在第一会话中已发布、且未推送给第一客户端的多个交互数据及对应的发布时间，这里的多个交互数据可以但不限于为一个或多个客户端在第一会话中发布的数据。

需要说明的是，在本实施例中，在发布时间不同时，可以但不限于按照发布时间的顺序，依次将发布时间转换为在对应客户端中所播放的媒体文件的播放位置，获取上述播放位置与第一播放位置之间的第二时间差中的最小值，将该最小值对应的发布时间发布的交互数据作为推送给第一客户端的数据；此外，在本实施例中，在发布时间相同时，由于播放进度不同，则上述发布时间在对应客户端中所播放的媒体文件中分别对应的播放位置也不同，还是可以通过获取上述播放位置与第一播放位置之间的第二时间差中的最小值，并将该最小值对应的发布时间发布的交互数据作为推送给第一客户端的数据，从而实现对交互一致性的控制。

通过本申请提供的实施例，获取服务器中存储的在第一会话中已发布、且未推送给第一客户端的交互数据的发布时间；并按照发布时间的顺序依次获取发布时间所对应的播放位置与第一播放位置之间的第二时间差，利用第二时间差中的最小值获取作为推送给第一客户端的数据，从而保证数据交互的完整性，避免遗漏交互数据。

作为一种可选的方案，还包括：

1)第一接收单元，用于在获取第一客户端发送的交互请求之前，接收第一客户端发送的邀请操作指令，其中，邀请操作指令用于邀请第二账号与第一账号加入第一会话；

2)发送单元，用于向第二客户端发送邀请请求，以邀请第二客户端所使用的第二账号加入第一会话。

可选地，在本实施例中，还包括：第二接收单元，用于在接收第一客户端发送的邀请操作指令之前，在第一客户端播放媒体文件时，接收对位于媒体文件的播放画面上的会话创建按钮执行的点击操作所生成的邀请操作指令。

具体结合图7所示示例进行说明，通过点击位于媒体文件的播放画面上所显示的邀请按钮(即会话创建按钮)来生成用于邀请邀请第二账号加入第一会话的操作指令。

例如，如图3所示，正在使用第一账号观看媒体文件A的第一客户端(媒体文件播放应用客户端)，可以通过即时通讯应用邀请账号a加入第一会话，还可以通过微博应用邀请账号b加入第一会话，还可以通过社区空间应用邀请账号c加入第一会话，如图3所示，已成功通过即时通讯应用邀请账号a。

通过本申请提供的实施例，通过基于对媒体文件的播放，在不同账号之间创建用于对关于媒体文件的内容进行数据交互的会话，以实现对媒体文件的实时交互。

实施例3

根据本发明实施例，还提供了一种用于实施上述数据交互方法的数据交互服务器，如图9所示，该服务器包括：

1)通讯接口902，设置为在使用第一账号登录的第一客户端播放媒体文件的过程中，获取第一客户端发送的交互请求，其中，交互请求携带有第一客户端播放媒体文件的第一播放位置，交互请求用于请求获取使用第二账号登录的第二客户端在播放媒体文件时，在第一会话发布的第一交互数据，第二账号通过第一会话与第一账号进行数据交互；

2)处理器904，与通讯接口902连接，设置为根据第一播放位置判断是否满足向第一客户端推送第一交互数据的推送条件，其中，推送条件用于控制第一客户端在播放到媒体文件中的目标播放位置之后接收到第一交互数据，目标播放位置位于第一播放位置之后；

上述通讯接口，还设置为在满足推送条件时，向第一客户端推送第一交互数据。

3)存储器906，与通讯接口902与处理器904连接，设置为存储上述播放位置及交互数据。

可选地，本实施例中的具体示例可以参考上述实施例1和实施例2中所描述的示例，本实施例在此不再赘述。

实施例5

本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以位于网络中的多个网络设备中的至少一个网络设备。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：

S1，在使用第一账号登录的第一客户端播放媒体文件的过程中，获取所述第一客户端发送的交互请求，其中，所述交互请求携带有所述第一客户端播放所述媒体文件的第一播放位置，所述交互请求用于请求获取使用第二账号登录的第二客户端在播放所述媒体文件时，在第一会话发布的第一交互数据，所述第二账号通过所述第一会话与所述第一账号进行数据交互；

S2，根据所述第一播放位置判断是否满足向所述第一客户端推送所述第一交互数据的推送条件，其中，所述推送条件用于控制所述第一客户端在播放到所述媒体文件中的目标播放位置之后接收到所述第一交互数据，所述目标播放位置位于所述第一播放位置之后；

S3，在满足所述推送条件时，向所述第一客户端推送所述第一交互数据。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：

S1，获取所述第二账号在所述第一会话发布所述第一交互数据的发布时间；

S2，根据所述第一播放位置与所述第一交互数据的所述发布时间判断是否满足所述推送条件。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：根据发布时间获取第二客户端在发布第一交互数据时媒体文件被播放至的第二播放位置，其中，在发布第一交互数据时，在第一客户端媒体文件被播放至第三播放位置，第三播放位置在第二播放位置之前；获取第二播放位置与第一播放位置二者之间的第一时间差；判断第一时间差是否小于等于预定阈值；在第一时间差小于等于预定阈值时，向第一客户端推送第一交互数据。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：在判断第一时间差是否小于等于预定阈值之后，在第一时间差大于预定阈值时，则向第一客户端发送调整指令，其中，调整指令用于拒绝向第一客户端推送第一交互数据，并用于指示第一客户端调整在下一次发送用于请求获取第一交互数据的交互请求之前的等待间隔，以使第一客户端在等待间隔后再次发送用于请求获取第一交互数据。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：在获取第一客户端发送的交互请求之前，获取服务器中存储的在第一会话中已发布、且未推送给第一客户端的交互数据的发布时间；按照发布时间的顺序依次获取发布时间所对应的播放位置与第一播放位置之间的第二时间差，其中，第二账号所发布的第一交互数据的发布时间所对应的播放位置与第一播放位置之间的第二时间差最小；响应交互请求将第一交互数据作为推送给第一客户端的数据。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

可选地，本实施例中的具体示例可以参考上述实施例1和实施例2中所描述的示例，本实施例在此不再赘述。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。

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

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。