CN108243171A - 在线直播互动***及方法 - Google Patents

Abstract

本发明实施例提供一种在线直播互动***及方法，***中第一客户端发送并存储为实现在线直播互动产生的交互信令消息以及对应交互信令消息的索引；后台服务器接收并存储交互信令消息以及交互信令消息的索引，当接收失败时后台服务器将接收失败的交互信令消息的索引与第一客户端上存储的交互信令消息的索引进行比对以从再次自动获取存储的交互信令消息及对应交互信令消息的索引；第二客户端接收后台服务器发送的交互信令消息以及对应交互信令消息的索引，当接收失败时第二客户端将接收失败的交互信令消息的索引与后台服务器上存储的交互信令消息的索引进行比对以从后台服务器再次自动获取存储的交互信令消息及对应交互信令消息的索引，保证了互动的效果。

Description

在线直播互动***及方法

技术领域

本发明实施例涉及在线直播技术领域，尤其涉及一种在线直播互动***及方法。

背景技术

在线教育或称远程教育、在线学习，以网络为介质的教学方式，通过网络，学员与教师即使相隔万里也可以开展教学活动；此外，借助网络课件，学员还可以随时随地进行学习，真正打破了时间和空间的限制。在线教育可以尽可能的摆脱时空、人力、物力等限制，可以实现资源利用最大化。

现有技术中，教育培训机构可通过互联网远程教学平台，运用视频、语音等教学软件，使老师和学生之间进行沟通，使得整个培训过程更具有互动性；另外，也使得老师、学生尽享足不出户却犹如面对面交流的感觉；同时也可以让教育培训机构与学生节省更多时间和人力物力的支出，得学生能够在短时间内学到更多需要的专业知识，让培训机构招纳更多的学员。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：由于目前的在线教育主要依赖于互联网，尤其其中通过互联网来进行基于课件的互动，常常由于网络的原因，导致互动过程中，常常会出现教师端发起了互动，该互动从技术层面会产生一系列有先后顺序的交互信令消息，而学生端缺不能及时甚至是没有收到具有先后顺序的交互信令信息，导致互动的效果无法保证。

发明内容

有鉴于此，本发明实施例所解决的技术问题之一在于提供一种在线直播互动***及方法，用以克服现有技术中上述缺陷。

本发明实施例提供一种在线直播互动***，其包括：第一客户端、第二客户端以及后台服务器；所述第一客户端发送并存储为实现在线直播互动产生的交互信令消息以及对应所述交互信令消息的索引；所述后台服务器接收并存储所述交互信令消息以及所述交互信令消息的索引，当接收失败时所述后台服务器将接收失败的所述交互信令消息的索引与所述第一客户端上存储的所述交互信令消息的索引进行比对以从所述第一客户端再次自动获取存储的所述交互信令消息及对应所述交互信令消息的索引；所述第二客户端接收所述后台服务器发送的所述交互信令消息以及对应所述交互信令消息的索引，当接收失败时所述第二客户端将接收失败的所述交互信令消息的索引与所述后台服务器上存储的所述交互信令消息的索引进行比对以从所述后台服务器再次自动获取存储的所述交互信令消息及对应所述交互信令消息的索引，所述交互信令的索引中包括所述交互信令消息的ID以及确定所述交互信令消息先后的时间戳。

可选地，在本发明的一实施例中，所述第一客户端、所述第二客户端分别与所述后台服务器建立第一长连接通讯通道以及第二长连接通讯通道，所述第一客户端通过所述第一长连接通讯通道与所述后台服务器进行所述交互信令消息以及对应所述交互信令消息的索引的传输，所述第二客户端通过所述第二长连接通讯通道与所述后台服务器进行所述交互信令消息以及对应所述交互信令消息的索引的传输。

可选地，在本发明的一实施例中，所述第一客户端在存储多个所述交互信令消息时，将每个所述交互信令消息与对应每个所述交互信令消息的索引封装为交互信令消息体，按照多个所述交互信令消息体的时序先后进行存储形成交互信令消息体队列。

可选地，在本发明的一实施例中，所述后台服务器自动重新从所述第一客户端成功获取到之前接收失败的所述交互信令消息及对应所述交互信令消息的索引时，重新获取之前接收失败的所述交互信令消息及在时序位于其后的多个交互信令信息及对应所述交互信令消息的索引，成功获取后，从所述第一客户端上的所述交互信令消息队列中删除接收成功的所述交互信令消息体，其中包括接收失败的所述交互信令消息以及对应的索引。

可选地，在本发明的一实施例中，当所述后台服务器从所述第一客户端成功获取到之前接收失败的所述交互信令消息及在时序位于其后的多个交互信令信息及对应所述交互信令消息的索引后，删除后台服务器上已成功获取到所有所述交互信令信息及对应所述交互信令消息的索引。

可选地，在本发明的一实施例中，当所述后台服务器重新从所述第一客户端成功获取到之前接收失败的所述交互信令消息及在时序位于其后的多个交互信令信息及对应所述交互信令消息的索引包括：根据所述后台服务器向所述第一客户端返回的确收通知，判定所述后台服务器从所述第一客户端成功获取到所述交互信令消息体。

可选地，在本发明的一实施例中，删除后台服务器上已成功获取到所有所述交互信令信息及对应所述交互信令消息的索引包括：根据对接收成功的所述交互信令消息体的确认标记，从所述第一客户端上的所述交互信令消息体队列中删除与后台服务器已成功接收的所有所述交互信令消息及对应所述交互信令消息的索引。

可选地，在本发明的一实施例中，当所述后台服务器接收失败时，所述第一客户端未收到所述确收通知的时长超过预定的时长后，所述第一客户端向所述后台服务器自动重发接收失败的所述交互信令消息体。

可选地，在本发明的一实施例中，在所述第一客户端向所述后台服务器重发接收失败的所述交互信令消息及对应所述交互信令消息的索引时，同时发送接收失败的所述交互信令消息之后的其他所述交互信令消息及对应其他所述交互信令消息的索引。

可选地，在本发明的一实施例中，所述后台服务器在存储多个交互信令消息时，将每个所述交互信令消息与对应每个所述交互信令消息的索引封装为交互信令消息体，按照多个所述交互信令消息体的时序先后进行存储形成交互信令消息体队列。

可选地，在本发明的一实施例中，所述后台服务器在存储多个交互信令消息时，将每个所述交互信令消息与对应每个所述交互信令消息的索引封装为交互信令消息体，按照多个所述交互信令消息体的时序先后进行存储形成交互信令消息体队列包括：按照多个所述交互信令消息体的时序先后进行存储形成交互信令消息体全量队列，以及根据所述交互信令消息体全量队列生成的交互信令消息体关键状态队列。

可选地，在本发明的一实施例中，所述后台服务器根据所述交互信令消息体全量队列生成的交互信令消息体关键状态队列时，通过在对所述交互信令消息体全量队列的所述交互信令消息体进行类型统计得到不同类型的所述交互信令消息体，通过对每一类型所述交互信令消息体增加帧属性标志，生成交互信令消息体关键帧队列。

可选地，在本发明的一实施例中，还包括：根据第一客户端和第二客户端在交互中在第一客户端或者第二客户端发起的交互动作针对的数据对象确定所述交互信令信息体的类型，不同类型的所述交互信令信息对应不同的交互信令信息体关键帧队列。

可选地，在本发明的一实施例中，还包括：根据增加帧属性标志对所述交互信令消息体关键帧队列进行维护，所述维护包括:在所述交互信令消息体关键帧队列中增加同类型的所述交互信令消息体、更改所述交互信令消息体的最新状态、删除所述交互信令消息体的最新状态。

可选地，在本发明的一实施例中，将同一类型所述交互信令信息中最新状态的所述交互信令信息体作为所述交互信令信息体关键帧队列的队列元素。

可选地，在本发明的一实施例中，当所述第二客户端接收所述交互信令消息体失败时，所述第二客户端首先从所述交互信令消息体全量队列中再次获取之前接收失败的所述交互信令消息体及在时序上位于其后的所述交互信令消息体，超过设定的时段，从所述交互信令消息体全量队列中再次获取失败，则从所述交互信令消息体关键帧队列中获取与之前接收失败的所述交互信令消息体同类型且帧属性标志最新的所述交互信令消息体，所述帧属性标志包括所述交互信令消息体的状态。

可选地，在本发明的一实施例中，从所述交互信令消息体关键帧队列中成功获取到与之前接收失败的所述交互信令消息体同类型且帧属性标志最新的所述交互信令消息体之后，根据帧属性标志从所述交互信令消息体关键帧队列中删除类型上与接收成功的所述交互信令消息相同的最新所述交互信令消息体。

本申请实施例还提供一种在线直播互动方法，其包括：

第一客户端发送并存储为实现在线直播互动产生的交互信令消息以及对应所述交互信令消息的索引；

后台服务器接收并存储所述交互信令消息以及所述交互信令消息的索引，当接收失败时所述后台服务器将接收失败的所述交互信令消息的索引与所述第一客户端上存储的所述交互信令消息的索引进行比对以从所述第一客户端再次自动获取存储的所述交互信令消息及对应所述交互信令消息的索引；

第二客户端接收所述后台服务器发送的所述交互信令消息以及对应所述交互信令消息的索引，当接收失败时所述第二客户端将接收失败的所述交互信令消息的索引与所述后台服务器上存储的所述交互信令消息的索引进行比对以从所述后台服务器再次自动获取存储的所述交互信令消息及对应所述交互信令消息的索引，所述交互信令的索引中包括所述交互信令消息的I D以及确定所述交互信令消息先后的时间戳。

由以上技术方案可见，本发明实施例中，通过所述第一客户端发送并存储为实现在线直播互动产生的交互信令消息以及对应所述交互信令消息的索引；所述后台服务器接收并存储所述交互信令消息以及所述交互信令消息的索引，当接收失败时所述后台服务器将接收失败的所述交互信令消息的索引与所述第一客户端上存储的所述交互信令消息的索引进行比对以从所述第一客户端再次自动获取存储的所述交互信令消息及对应所述交互信令消息的索引；所述第二客户端接收所述后台服务器发送的所述交互信令消息以及对应所述交互信令消息的索引，当接收失败时所述第二客户端将接收失败的所述交互信令消息的索引与所述后台服务器上存储的所述交互信令消息的索引进行比对以从所述后台服务器再次自动获取存储的所述交互信令消息及对应所述交互信令消息的索引，从而保证具有先后顺序的交互信令消息可以可靠的在第一客户端与第二客户端之间传输，从而保证了互动的效果。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1为本发明实施例一中在线直播互动***的结构示意图；

图2为本发明实施例二中在线直播互动方法流程示意图；

图3是本申请执行在线直播互动方法的一些电子设备的硬件结构示意图。

具体实施方式

当然，实施本发明实施例的任一技术方案必不一定需要同时达到以上的所有优点。

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

下面结合本发明实施例附图进一步说明本发明实施例具体实现。

本发明下述实施例中，通过所述第一客户端发送并存储为实现在线直播互动产生的交互信令消息以及对应所述交互信令消息的索引；所述后台服务器接收并存储所述交互信令消息以及所述交互信令消息的索引，当接收失败时所述后台服务器将接收失败的所述交互信令消息的索引与所述第一客户端上存储的所述交互信令消息的索引进行比对以从所述第一客户端再次自动获取存储的所述交互信令消息及对应所述交互信令消息的索引；所述第二客户端接收所述后台服务器发送的所述交互信令消息以及对应所述交互信令消息的索引，当接收失败时所述第二客户端将接收失败的所述交互信令消息的索引与所述后台服务器上存储的所述交互信令消息的索引进行比对以从所述后台服务器再次自动获取存储的所述交互信令消息及对应所述交互信令消息的索引，从而保证具有先后顺序的交互信令消息可以可靠的在第一客户端与第二客户端之间传输，从而保证了互动的效果。

图1为本发明实施例一中在线直播互动***的结构示意图；如图1所示，其包括：作为教师端的教师端、作为学生端的学生端以及后台服务器。本实施例中，所述教师端、所述学生端分别与所述后台服务器建立第一长连接通讯通道以及第二长连接通讯通道，所述教师端通过所述第一长连接通讯通道与所述后台服务器进行所述交互信令消息以及对应所述交互信令消息的索引的传输，所述学生端通过所述第二长连接通讯通道与所述后台服务器进行所述交互信令消息以及对应所述交互信令消息的索引的传输。具体地，由于TCP协议是面向连接(连接导向)的、可靠的、基于字节流的运输层(Transport layer)通信协议，因此，本实施例中，所述教师端、所述学生端分别与所述后台服务器通过TCP协议建立第一长连接通讯通道以及第二长连接通讯通道。本实施例中，第一长连接通讯通道以及第二长连接通讯通道始终处于持续有效的可通讯状态，教师端与后台服务器、后台服务器与学生端之间可以随时进行所述交互信令消息以及对应所述交互信令消息的索引的传输。但是，需要说明的是，上述第一长连接通讯通道以及第二长连接通讯通道可以分别被第一短连接通讯通道以及第二短连接通讯通道代替，与上述第一长连接通讯通道以及第二长连接通讯通道不同的是，在教师端与后台服务器、后台服务器与学生端之间需要进行所述交互信令消息以及对应所述交互信令消息的索引的传输时，第一短连接通讯通道以及第二短连接通讯通道才会存在，而当教师端与后台服务器、后台服务器与学生端之间不需要进行所述交互信令消息的传输时，第一短连接通讯通道以及第二短连接通讯通道就会消除，当教师端与后台服务器、后台服务器与学生端之间需要再次进行所述交互信令消息的传输时，需要重新搭建第一短连接通讯通道以及第二短连接通讯通道。无论上述第一短连接通讯通道以及第二短连接通讯通道还是第一长连接通讯通道以及第二长连接通讯通道都可通过通讯协议中的握手过程建立，详细不再赘述。

在建立了上述通讯通道以实现所述教师端发送并存储为实现在线直播互动产生的交互信令消息以及对应所述交互信令消息的索引，以及所述后台服务器接收并存储所述交互信令消息以及对应所述交互信令消息的索引以及对应所述交互信令消息的索引，当接收失败时所述后台服务器从所述教师端再次自动获取存储的所述交互信令消息以及对应所述交互信令消息的索引。所述学生端接收所述后台服务器发送的所述交互信令消息，当接收失败时所述学生端从所述后台服务器再次自动获取存储的所述交互信令消息以及对应所述交互信令消息的索引，所述交互信令的索引中包括所述交互信令消息的I D以及确定所述交互信令消息先后的时间戳。

本实施例中，所述教师端在存储多个所述交互信令消息时，将每个所述交互信令消息与对应每个所述交互信令消息的索引封装为交互信令消息体，按照多个所述交互信令消息体的时序先后进行存储形成交互信令消息体队列。具体地，考虑到实际的业务需要，交互信令消息体队列的长度可以自行自定义，比如，只保留预定时长内的多个交互信令消息。

具体地，可将最新的交互信令消息体放在队列的最后，在后台服务器获取之前接收失败的交互信令消息体时，可以按照交互信令消息体的ID，从交互信令消息队列的队尾开始逐个进行查询，直至查询并获取到交互信令消息体队列中ID与接收失败的交互信令消息体的ID相同的交互信令消息体。进一步地，本实施例中，在所述教师端向所述后台服务器重发接收失败的所述交互信令消息以及对应所述交互信令消息的索引时，同时发送接收失败的所述交互信令消息之后的其他所述交互信令消息以及对应其他所述交互信令消息的索引，覆盖所述后台服务器原先接收的对应多个所述交互信令消息以及对应多个所述交互信令消息的索引，在覆盖时，可以按照交互信令消息的ID是否重复来确定需要覆盖的所述交互信令消息。本实施例中，当所述后台服务器重新从所述教师端成功获取到之前接收失败的所述交互信令消息以及对应所述交互信令消息的索引时，重新获取之前接收失败的所述交互信令消息及在时序位于其后的多个交互信令信息及对应所述交互信令消息的索引，成功获取后，，从所述教师端上的所述交互信令消息体队列中删除接收成功的所述交互信令消息以及对应所述交互信令消息的索引，即所述交互信令消息体。

当所述后台服务器从所述教师端成功获取到之前接收失败的所述交互信令消息及在时序位于其后的多个交互信令信息及对应所述交互信令消息的索引后，删除后台服务器上已成功获取到所有所述交互信令信息重复的交互信令信息及对应所述交互信令消息的索引。

具体地，当所述后台服务器重新从所述第一客户端成功获取到之前接收失败的所述交互信令消息及在时序位于其后的多个交互信令信息及对应所述交互信令消息的索引包括：根据所述后台服务器向所述第一客户端返回的确收通知，判定所述后台服务器从所述第一客户端成功获取到所述交互信令消息体。

删除后台服务器上已成功获取到所有所述交互信令信息及对应所述交互信令消息的索引包括：根据对接收成功的所述交互信令消息体的确认标记，从所述教师端上的所述交互信令消息体队列中删除与后台服务器已成功获取到的所有所述交互信令消息及对应所述交互信令消息的索引。即本实施例中，制定了使用确认标记的队列缩减原则来对交互信令消息体队列进行维护，从而使得教师端向后台服务器发送所述交互信令消息体队列与教师端重发接收失败的所述交互信令消息体异步执行，相互之间不形成干扰。

如上所述“确认标记”可可以是交互信令消息中一个附加字段，该字段有两个取值：“未得到回复/已得到回复”，在交互信令消息刚发送并放到交互信令信息队列中时，“确认标记”被置为“未得到回复”，等收到该消息的确认消息后，将该消息的“确认标记”置为“已得到回复”。但是，需要说明的是，对应的消息虽然已经被服务器端确认，但发送端并不一定就能将该消息从确认队列中移除，优选在队列中比该消息更早发送的所有消息都得到确认(即之前发送的消息的“确认标记”全部置为了“已得到回复”)，才能将该消息从确认队列中移除。为此，每次收到确认消息时，优选从交互信令信息队列的最前端(即最早发送的消息)处，开始检查各消息的“确认标记”，将标记为“已得到回复”的消息从队列移出，直到遇到第一个为“未得到回复”的消息为止(有可能第一个消息就是“未得到回复”的，此时不会移出任何消息)。另外，为了确定等待回复是否超时，还可以在交互信令消息中增加发送时间字段。

在上述过程中，所述教师端未收到所述确收通知的时长超过预定的时长后，所述教师端向所述后台服务器自动重发接收失败的所述交互信令消息体，与此同时，所述教师端在存储所述交互信令消息体时，对服务器接收失败的所述交互。比如，在由于网络中断等异常导致所述教师端未收到所述确收通知的时长超过预定的时长。若所述教师端未收到所述确收通知的时长未超过预定的时长的话，所述教师端继续等待接收服务器返回的确收通知。

本实施例中，所述后台服务器在存储多个交互信令消息体时，将每个所述交互信令消息与对应每个所述交互信令消息的索引封装为交互信令消息体，按照多个所述交互信令消息体的时序先后进行存储形成交互信令消息体队列。具体地，所述后台服务器在存储多个交互信令消息体时，按照多个所述交互信令消息体的时序先后进行存储形成交互信令消息体队列包括：按照多个所述交互信令消息体的时序先后进行存储形成交互信令消息体全量队列，以及根据所述交互信令消息体全量队列生成的交互信令消息体关键状态队列。所述后台服务器根据所述交互信令消息体全量队列生成的交互信令消息体关键状态队列时，通过在对所述交互信令消息体全量队列的所述交互信令消息体进行类型统计得到不同类型的所述交互信令消息体，通过对每一类型所述交互信令消息体增加帧属性标志，生成交互信令消息体关键帧队列。

根据第一客户端和第二客户端在交互中在第一客户端或者第二客户端发起的交互动作针对的数据对象确定所述交互信令信息体的类型，不同类型的所述交互信令信息对应不同的交互信令信息体关键帧队列。

本实施例中，帧属性标志记录了同一类型的所述交互信令消息体的最新状态，即记录了最新状态的所述交互信令消息体。以在线直播课程中针对课件的互动来说，翻页、涂鸦分别对应一类所述交互信令消息体，而对于翻页这一类交互信令消息体来说，由于翻页过程的变化，比如，从课件的第1页翻到第8页，翻页对应的交互信令消息体的状态从翻到第1页至翻到第8页。

为此，本实施例中，当所述学生端接收所述交互信令消息体失败时，所述学生端首先从所述交互信令消息体全量队列中再次获取之前接收失败的所述交互信令消息体及在时序上位于其后的所述交互信令消息体，超过设定的时段，从所述交互信令消息体全量队列中再次获取失败，则从所述交互信令消息体关键帧队列中获取与之前接收失败的所述交互信令消息体同类型且帧属性标志最新的所述交互信令消息体，所述帧属性标志包括所述交互信令消息体的状态。需要说明的是，如果当所述学生端接收所述交互信令消息体失败的累计时间未超过设定的时段，可以从交互信令消息体全量队列接收失败的所述交互信令消息体，以实现教师端与学生端的局部同步，而当超过设定的时段时，判定网络出现异常比如中断，则从所述交互信令消息体关键帧队列中获取同类型且帧属性标志最新的所述交互信令消息体，而不是之前接收失败的所述交互信令消息体，以实现教师端与学生端的全局同步。比如，翻页类的交互信令消息体，当前时刻教师端将课件从第1页翻到了第8页，而学生端的课件，并未翻到第8页，即学生端未接收到翻到第8页的交互信令消息体，但实际在此之后，教师端的课件已从第8页翻到了第10页，由于翻页类型的交互信令消息体在交互信令消息体关键帧队列进行了维护，通过查询交互信令消息体关键帧队列即可得知课件已经翻到了第10页，因此，在学生端从后台服务器的交互信令消息体关键帧队列中获取已经翻到第10页的交互信令消息体关键帧，根据第10页的交互信令消息体关键帧把学生端的课件同步翻到第10页。

类似上述确收标记，本实施例中，还可以根据增加帧属性标志对所述交互信令消息体关键帧队列进行维护，所述维护包括:在所述交互信令消息体关键帧队列中增加同类型的所述交互信令消息体、更改所述交互信令消息体的最新状态、删除所述交互信令消息体的最新状态。以删除为例，从所述交互信令消息体关键帧队列中成功获取到与之前接收失败的所述交互信令消息体同类型且帧属性标志最新的所述交互信令消息体之后，根据帧属性标志从所述交互信令消息体关键帧队列中删除类型上与接收成功的所述交互信令消息体相同的最新所述交互信令消息体。

本实施例中，帧属性标志为所述交互信令消息中的一组附加字段，如果被发送的消息是关键帧，则包含该组字段，“帧属性标志”包含四个字段：是否是关键帧、队列类型、队列id、消息类型、操作类型。“是否是关键帧”的值取“是”或“不是”，不是关键帧的消息，服务器只负责转发，不会对维护的关键状态产生影响。

“队列类型”：某一类消息的总标识，比如，文档操作类消息：文档打开、文档翻页、文档关闭，都是文档消息，即这些消息都是文档类型的消息，这些消息的队列类型都为“文档”。类似的，所有音视频流打开、切换视频流、关闭视频流的消息的音视频类型的消息，这些消息的队列类型都为“音视频”。

“队列id”：在打开多个文档时，每个文档会对应一个交互信令信息关键帧队列，用队列id来区分消息属于哪个交互信令信息关键帧队列，即服务器端收到消息时，对关键状态中哪个子队列(不同文档对应的不同交互信令信息关键帧队列)进行更新等操作。

“消息类型”：队列中消息的类型，比如文档打开类型的消息、文档翻页类型的消息等。

“操作类型”：创建、销毁、添加、更新。

举例：

(1)打开一个文档时，需要在服务器端的关键状态队列中创建一个文档状态的子队列：

发送的第一个关键帧的四个字段为：

是否关键帧：是

队列类型：文档

队列id：唯一标识abc

消息类型：空(代表本次是对子对列进行操作)

操作类型：创建(创建子对列)

(2)发送“打开文档消息”，附加的四个字段为：

是否关键帧：是

队列类型：文档

队列id：唯一标识abc

消息类型：文档打开

操作类型：添加(在abc标识的子对列中添加本条消息)

(3)发送“文档翻页消息”，附加的四个字段为：

是否关键帧：是

队列类型：文档

队列id：唯一标识abc

消息类型：文档翻页(第一页)

操作类型：添加(在abc标识的子对列中添加本条消息)

(4)发送“文档翻页消息”，附加的四个字段为：

是否关键帧：是

队列类型：文档

队列id：唯一标识abc

消息类型：文档翻页(第二页)

操作类型：添加(在abc标识的子对列中更新文档翻页消息，即将上一条文档翻页消息删除，再添加本条消息)

(5)发送“关闭文档消息”，附加的四个字段为：

是否关键帧：是

队列类型：文档

队列id：唯一标识abc

消息类型：空(代表本次是对子对列进行操作)

操作类型：销毁(销毁abc标识的子对列及队列中保存的所有消息，客户端之后进来的，认为没有打开过此文档)

需要说明的是，在其他实施例中，上述第一客户端可以是一学生端，第二客户端可以另一学生端，详细不再说明。

上述实施例中，由于每一条交互信令消息都对应一个索引，在该索引中记录了与前后交互信令消息的时序关系，因此，无论是上述后台服务器从第一客户端再次获取接收失败的所述交互信令消息时，还是第二客户端从所述后台服务器再次获取接收失败的所述交互性信令消息时，可以通过接收失败的所述交互信令消息对应的索引判断出与前后其他交互信令消息的时序关系，从而保证再次获取到的所述交互信令消息与其他交互信令消息在时序关系上，与在第一客户端上生成时完全相同，进而保证即使有交互信令消息的传输失败，再次获取到的交互信令消息在时序上维持原有的状态，保证互动实现的有效性。

图2为本发明实施例二中在线直播互动方法流程示意图；如图2所示，其包括：

S201、第一客户端发送并存储为实现在线直播互动产生的交互信令消息以及对应所述交互信令消息的索引；

S202、后台服务器接收并存储所述交互信令消息以及所述交互信令消息的索引，当接收失败时所述后台服务器将接收失败的所述交互信令消息的索引与所述第一客户端上存储的所述交互信令消息的索引进行比对以从所述第一客户端再次获取存储的所述交互信令消息及对应所述交互信令消息的索引；

S203、第二客户端接收所述后台服务器发送的所述交互信令消息以及对应所述交互信令消息的索引，当接收失败时所述第二客户端将接收失败的所述交互信令消息的索引与所述后台服务器上存储的所述交互信令消息的索引进行比对以再次从所述后台服务器再次获取存储的所述交互信令消息及对应所述交互信令消息的索引。

有关步骤S201-S203的详细解释或者扩展性解释可参见上述图1的记载，在此不再赘述。

在上述实施例中，第一客户端、第二客户端可以是为了实现在线直播***编制的APP，上述第一客户端、第二客户端可以安装在PC、智能手机或者平板电脑上。

图3是本申请执行在线直播互动方法的一些电子设备的硬件结构示意图。根据图3所示，该设备包括：

一个或多个处理器310以及存储器320，图3中以一个处理器310为例。

执行在线直播互动方法的设备还可以包括：输入装置330和输出装置330。

处理器310、存储器320、输入装置330和输出装置830可以通过总线或者其他方式连接，图3中以通过总线连接为例。

存储器320作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如本申请实施例中的在线直播互动方法对应的程序指令/模块。处理器310通过运行存储在存储器320中的非易失性软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例中在线直播互动方法。

存储器320可以包括存储程序区和存储数据区，其中，存储程序区可存储操作***、至少一个功能所需要的应用程序；存储数据区可存储根据在线直播互动***的使用所创建的数据等。此外，存储器320可以包括高速随机存取存储器320，还可以包括非易失性存储器320，例如至少一个磁盘存储器320件、闪存器件、或其他非易失性固态存储器320件。在一些实施例中，存储器320可选包括相对于处理器310远程设置的存储器320，这些远程存储器320可以通过网络连接至在线直播互动***。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置330可接收输入的数字或字符消息，以及产生与在线直播互动***的用户设置以及功能控制有关的键信号输入。输入装置330可包括按压模组等设备。

所述一个或者多个模块存储在所述存储器320中，当被所述一个或者多个处理器310执行时，执行上述任意方法实施例中的在线直播互动方法。

上述产品可执行本申请实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本申请实施例所提供的方法。

本申请实施例的电子设备以多种形式存在，包括但不限于:

(1)移动通信设备:这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括:智能手机(例如iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备:这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括:PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备:这类设备可以显示和播放多媒体内容。该类设备包括:音频、视频播放器(例如iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器:提供计算服务的设备，服务器的构成包括处理器410、硬盘、内存、***总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其他具有数据交互功能的电子装置。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，所述计算机可读记录介质包括用于以计算机(例如计算机)可读的形式存储或传送消息的任何机制。例如，机器可读介质包括只读存储器(ROM)、随机存取存储器(RAM)、磁盘存储介质、光存储介质、闪速存储介质、电、光、声或其他形式的传播信号(例如，载波、红外信号、数字信号等)等，该计算机软件产品包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本申请实施例的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

本领域的技术人员应明白，本发明实施例的实施例可提供为方法、装置(设备)、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明实施例是参照根据本发明实施例的方法、装置(设备)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

Claims (17)

1.一种在线直播互动***，其特征在于，包括：第一客户端、第二客户端以及后台服务器；所述第一客户端发送并存储为实现在线直播互动产生的交互信令消息以及对应所述交互信令消息的索引；所述后台服务器接收并存储所述交互信令消息以及所述交互信令消息的索引，当接收失败时所述后台服务器将接收失败的所述交互信令消息的索引与所述第一客户端上存储的所述交互信令消息的索引进行比对以从所述第一客户端再次自动获取存储的所述交互信令消息及对应所述交互信令消息的索引；所述第二客户端接收所述后台服务器发送的所述交互信令消息以及对应所述交互信令消息的索引，当接收失败时所述第二客户端将接收失败的所述交互信令消息的索引与所述后台服务器上存储的所述交互信令消息的索引进行比对以从所述后台服务器再次自动获取存储的所述交互信令消息及对应所述交互信令消息的索引，所述交互信令的索引中包括所述交互信令消息的I D以及确定所述交互信令消息先后的时间戳。

2.根据权利要求1所述的在线直播互动***，其特征在于，所述第一客户端、所述第二客户端分别与所述后台服务器建立第一长连接通讯通道以及第二长连接通讯通道，所述第一客户端通过所述第一长连接通讯通道与所述后台服务器进行所述交互信令消息以及对应所述交互信令消息的索引的传输，所述第二客户端通过所述第二长连接通讯通道与所述后台服务器进行所述交互信令消息以及对应所述交互信令消息的索引的传输。

3.根据权利要求1所述的在线直播互动***，其特征在于，所述第一客户端在存储多个所述交互信令消息时，将每个所述交互信令消息与对应每个所述交互信令消息的索引封装为交互信令消息体，按照多个所述交互信令消息体的时序先后进行存储形成交互信令消息体队列。

4.根据权利要求3所述的在线直播互动***，其特征在于，所述后台服务器自动重新从所述第一客户端成功获取到之前接收失败的所述交互信令消息及对应所述交互信令消息的索引时，重新获取之前接收失败的所述交互信令消息及在时序位于其后的多个交互信令信息及对应所述交互信令消息的索引，成功获取后，从所述第一客户端上的所述交互信令消息队列中删除接收成功的所述交互信令消息体，其中包括接收成功的所述交互信令消息以及对应的索引。

5.根据权利要求4所述的直播互动***，其特征在于，当所述后台服务器从所述第一客户端成功获取到之前接收失败的所述交互信令消息及在时序位于其后的多个交互信令信息及对应所述交互信令消息的索引后，删除后台服务器上已成功获取到的所有所述交互信令信息及对应所述交互信令消息的索引。

6.根据权利要求4所述的在线直播互动***，其特征在于，所述后台服务器重新从所述第一客户端成功获取到之前接收失败的所述交互信令消息及在时序位于其后的多个交互信令信息及对应所述交互信令消息的索引包括：根据所述后台服务器向所述第一客户端返回的确收通知，判定所述后台服务器从所述第一客户端成功获取到所述交互信令消息体。

7.根据权利要求6所述的在线直播互动***，其特征在于，删除后台服务器上已成功获取到所有所述交互信令信息及对应所述交互信令消息的索引包括：根据对接收成功的所述交互信令消息体的确认标记，从所述第一客户端上的所述交互信令消息体队列中删除与后台服务器已成功接收的所有所述交互信令消息及对应所述交互信令消息的索引。

8.根据权利要求6所述的在线直播互动***，其特征在于，当所述后台服务器接收失败时，所述第一客户端未收到所述确收通知的时长超过预定的时长后，所述第一客户端向所述后台服务器自动重发接收失败的所述交互信令消息体。

9.根据权利要求1所述的在线直播互动***，其特征在于，所述后台服务器在存储多个交互信令消息时，将每个所述交互信令消息与对应每个所述交互信令消息的索引封装为交互信令消息体，按照多个所述交互信令消息体的时序先后进行存储形成交互信令消息体队列。

10.根据权利要求9所述的在线直播互动***，其特征在于，所述后台服务器在存储多个交互信令消息时，将每个所述交互信令消息与对应每个所述交互信令消息的索引封装为交互信令消息体，按照多个所述交互信令消息体的时序先后进行存储形成交互信令消息体队列包括：按照多个所述交互信令消息体的时序先后进行存储形成交互信令消息体全量队列，以及根据所述交互信令消息体全量队列生成的交互信令消息体关键状态队列。

11.根据权利要求10所述的在线直播互动***，其特征在于，所述后台服务器根据所述交互信令消息体全量队列生成的交互信令消息体关键状态队列时，通过在对所述交互信令消息体全量队列的所述交互信令消息体进行类型统计得到不同类型的所述交互信令消息体，通过对每一类型所述交互信令消息体增加帧属性标志，生成交互信令消息体关键帧队列。

12.根据权利要求11所述的在线直播互动***，其特征在于，还包括：根据第一客户端和第二客户端在交互中在第一客户端或者第二客户端发起的交互动作针对的数据对象确定所述交互信令信息体的类型，不同类型的所述交互信令信息对应不同的交互信令信息体关键帧队列。

13.根据权利要求11所述的在线直播互动***，其特征在于，还包括：根据增加帧属性标志对所述交互信令消息体关键帧队列进行维护，所述维护包括:在所述交互信令消息体关键帧队列中增加同类型的所述交互信令消息体、更改所述交互信令消息体的最新状态、删除所述交互信令消息体的最新状态。

14.根据权利要求11所述的在线直播互动***，其特征在于，将同一类型所述交互信令信息中最新状态的所述交互信令信息体作为所述交互信令信息体关键帧队列的队列元素。

15.根据权利要求10所述的在线直播互动***，其特征在于，当所述第二客户端接收所述交互信令消息体失败时，所述第二客户端首先从所述交互信令消息体全量队列中再次获取之前接收失败的所述交互信令消息体及在时序上位于其后的所述交互信令消息体，超过设定的时段，从所述交互信令消息体全量队列中再次获取失败，则从所述交互信令消息体关键帧队列中获取与之前接收失败的所述交互信令消息体同类型且帧属性标志最新的所述交互信令消息体，所述帧属性标志包括所述交互信令消息体的状态。

16.根据权利要求11所述的在线直播互动***，其特征在于，从所述交互信令消息体关键帧队列中成功获取到与之前接收失败的所述交互信令消息体同类型且帧属性标志最新的所述交互信令消息体之后，根据帧属性标志从所述交互信令消息体关键帧队列中删除类型上与接收成功的所述交互信令消息相同的最新所述交互信令消息体。

17.一种在线直播互动方法，其特征在于，包括：

第一客户端发送并存储为实现在线直播互动产生的交互信令消息以及对应所述交互信令消息的索引；

后台服务器接收并存储所述交互信令消息以及所述交互信令消息的索引，当接收失败时所述后台服务器将接收失败的所述交互信令消息的索引与所述第一客户端上存储的所述交互信令消息的索引进行比对以从所述第一客户端再次自动获取存储的所述交互信令消息及对应所述交互信令消息的索引；

第二客户端接收所述后台服务器发送的所述交互信令消息以及对应所述交互信令消息的索引，当接收失败时所述第二客户端将接收失败的所述交互信令消息的索引与所述后台服务器上存储的所述交互信令消息的索引进行比对以从所述后台服务器再次自动获取存储的所述交互信令消息及对应所述交互信令消息的索引，所述交互信令的索引中包括所述交互信令消息的I D以及确定所述交互信令消息先后的时间戳。