Flash P2P 避开安全沙箱的方法

摘要

本发明提供一种Flash P2P避开安全沙箱的方法。所述方法包括：每个Peer节点预先向RTMFP服务器发布信息流；所述每个Peer节点向Gather服务器注册所述已发布的信息流和自身的节点信息；每个Peer节点需要与另外的Peer节点进行数据传输时，所述每个Peer节点需要预先在所述Gather服务器中查询所述另外的Peer节点已发布的信息流和所述另外的Peer节点的相关信息；所述每个Peer节点经由所述RTMFP服务器与所述另外的Peer节点进行内网穿越，然后继续进行所述每个Peer节点和所述另外的Peer节点间的数据传输。与现有技术相比，本发明的优点在于既能避开Adobe安全沙箱机制，不弹出警告窗口，又能正常进行P2P数据分享。

说明书

技术领域

本发明涉及网络通信技术领域，更具体地，涉及一种Flash P2P避开安全沙箱的方法。

背景技术

随着Adobe公司的Flash技术的迅速发展，Flash可以通过载入多媒体内容与服务器端进行通信，甚至Flash与Flash之间也可以进行交互通信，即Flash P2P技术。但是为了安全起见，在未经授权的情况下，Flash默认状态是不允许进行跨域通信的，这就是安全沙箱机制。

因为安全沙箱机制的存在，当使用Flash P2P技术时，一旦Flash Player与RTMFP服务器建立连接，就会弹出一个警告窗口，询问用户是否需要加入文件共享群组而进行P2P，用户必须同意加入群组，后续才可进行P2P。

专利申请号为201110042931.4的名称为“克服flex安全沙箱限制的视频像素信息采集存储的方法”的发明中披露了一种克服flex安全沙箱限制视频像素信息采集存储的方法，该发明采用的技术方案是将截取后待保存的一组帧图像像素点信息数据由flex视频控件上传至WEB服务器，由WEB服务器进行该一组帧图像像素点信息数据的处理并将处理后形成的图像文件回传至WEB终端。

现有技术中，常见的解决Flash安全沙箱的几种方法如下：

一、通过配置跨域文件System.security.allowDomain(例如，配置成"www.baidu.com"，"baidu.com"，"mp3.baidu.com")。

二、利用JS脚本绕过安全沙箱<param name="allowScriptAccess" value="always" />。

三、使用Asp.Net绕过As3的跨域安全沙箱完成文件转发，以极低的效率解决问题，基本无实用价值。

四、设置本地安全沙箱，在C:\windows\system32\Macromed\Flash\FlashPlayerTrust下面，添加一个txt文件，例如songhuan.txt，然后在里面添加你的本机目录。

图1示出了现有技术中的传统RTMFP协议交互流程的示意图。由于Flash P2P是基于Adobe RTMFP协议进行，在传统RTMFP协议交互中，Peer节点与RTMFP服务器的通信过程如图1所示：首先Peer节点通过Handshake报文，与RTMFP服务器进行鉴权认证。通过鉴权认证后，Peer节点通过Connect报文与RTMFP服务器进行连接。然后，Peer节点通过JoinGroup报文加入RTMFP服务器中记录的一个群组。第四，Peer节点通过setPeerInfo报文向RTMFP服务器注册自身的内网IP地址，注册内网地址的目的是用来进行后续的内网穿越。在完成上述步骤后，Peer节点通过Ping报文向RTMFP服务器发送请求。

需要注意的是，两个在同一群组内的Peer节点在进行数据分享之前，需要先借助RTMFP服务器进行内网穿越（NAT Relay），随后才可进行相互间的P2P数据传输。

由此可见，安全沙箱机制虽然使得Flash的安全可靠性得到了提高，但是也影响了用户体验。

发明内容

本发明提供一种Flash P2P避开安全沙箱的方法。所述方法包括如下步骤：每个Peer节点预先向RTMFP服务器注册；所述每个Peer节点向Gather服务器注册所述已发布的信息流和自身的节点信息；每个Peer节点需要与另外的Peer节点进行数据传输时，所述每个Peer节点需要预先在所述Gather服务器中查询所述另外的Peer节点已发布的信息流和所述另外的Peer节点的相关信息；所述每个Peer节点经由所述RTMFP服务器与所述另外的Peer节点进行内网穿越，然后继续进行所述每个Peer节点和所述另外的Peer节点间的数据传输。

优选的是，所述每个Peer节点预先向RTMFP服务器发布信息流包括如下步骤：1）所述每个Peer节点通过Handshake报文，与所述RTMFP服务器进行鉴权认证；2）通过所述鉴权认证后，所述每个Peer节点通过Connect报文与所述RTMFP服务器进行连接；3） 所述每个Peer节点通过setPeerInfo报文向所述RTMFP服务器注册自身的内网IP地址；4）所述每个Peer节点通过Ping报文向所述RTMFP服务器发送保活报文。

优选的是，所述每个Peer节点向Gather服务器注册所述已发布的信息流和自身的节点信息包括如下步骤：

     1）所述每个Peer节点通过Query Server报文请求所述Gather服务器的IP地址；

     2）所述每个Peer节点通过Register报文向所述Gather服务器注册；

     3）所述每个Peer节点通过Query Peers报文，查询在所述Gather服务器中存储的处于同一群组内的其他Peer节点；

4）所述每个Peer节点通过Query Explore报文，查询向自己发布所述信息流的其他Peer节点；

5）所述每个Peer节点通过Query Stream报文，查询自己向所述其他Peer节点发布的信息流；

6）所述每个Peer节点通过Publish Stream报文，向所述Gather服务器注册自己的所述发布的流；

7）所述每个Peer节点通过Heart Beat报文向所述Gather服务器维持保活状态。

优选的是，所述每个Peer节点通过所述Gather服务器的IP地址访问所述Gather服务器。

优选的是，与所述每个Peer节点当前播放的视频信息相同的Peer节点被划在所述同一群组内。

与现有技术相比，本发明的优点在于既能避开Adobe安全沙箱机制，不弹出警告窗口，又能正常进行P2P数据分享。

附图说明

为了使本发明便于理解，现在结合附图描述本发明的具体实施例。

图1示出了现有技术中的传统RTMFP协议交互流程的示意图。

图2示出了本发明一优选实施例的协议交互流程的示意图。

具体实施方式

下面结合附图和优选的实施方式对本发明作进一步详细描述。权利要求中构成要件和实施例中具体实例之间的对应关系可以如下例证。这里的描述意图在于确认在实施例中描述了用来支持在权利要求中陈述的主题的具体实例，由于在实施例中描述了实例，不意味着该具体实例不表示构成要件。相反地，即使在此包含了具体实例作为对应一个构成要件的要素特征，也不意味着该具体实例不表示任何其它构成要件。

此外，这里的描述不意味着对应于实施例中陈述的具体实例的所有主题都在权利要求中引用了。换句话说，这里的描述不否认这种实体，即对应实施例包含的具体实例，但不包含在其任何一项权利要求中，即，能够在以后的修正被分案并申请、或增加的可能发明的实体。

应当注意的是，“系统”在此意味着由两个或更多设备构成的处理。

显而易见地，用户终端可以由个人计算机构成。此外，所述用户终端还可以由例如蜂窝电话、任何其它PDA（个人数字助理）工具、AV（音频视频）装置、诸如家用电气（家庭用电气化）设备的CE（消费电子设备）等构成。

“网络”意味着至少连接了两个设备的机构，并且在其中，一条信息能够从一个设备发送到另一个设备。经由网络建立通信的设备可以是彼此分离的，也可以是构成一个机器的内部模块。

“通信”可表示无线通信和有线通信。然而，还可以是混合无线和有线通信的通信，更具体地，在某个区段采取无线通信而在另一个区段采取有线通信的通信。同样，它也可以是这样的通信：从一个设备向另一设备的通信是有线的，且相反方向的通信是无线的。

本发明的一优选实施例为设置每一个Peer节点为主动发布信息流的源，因此，需要增加一个收集Peer节点信息的Gather服务器。图2示出了本发明一优选实施例的协议交互流程的示意图。首先，每一个Peer节点需要先向RTMFP服务器发布信息流，随后每一个Peer节点向Gather服务器注册已发布的信息流和自身的节点信息。随后，若一个Peer节点想要与另外一个Peer节点进行数据传输，则需要在上述Gather服务器中查询对方节点已发布的信息流和其节点的相关信息，然后借助RTMFP服务器与对方节点进行NAT Relay，随后继续进行两个节点间的数据传输。

本发明的又一优选实施例的通信步骤如下：

首先，Peer节点通过Handshake报文，与RTMFP服务器进行鉴权认证。通过鉴权认证后，Peer节点通过Connect报文与RTMFP服务器进行连接。然后，Peer节点通过setPeerInfo报文向RTMFP服务器注册自身的内网IP地址，注册内网地址的目的是用来进行后续的内网穿越。在完成上述步骤后，Peer节点通过Ping报文向RTMFP服务器维持保活状态。即，每一个Peer节点与所述RTMFP服务器进行交互时，除了并不发送JoinGroup报文，其余过程与传统的RTMFP协议交互一致。

第二、每一个Peer节点通过Query Server报文请求Gather服务器的IP地址，后续通过IP地址访问该Gather服务器。

第三、每一个Peer节点通过Register报文向Gather服务器注册。

第四、每一个Peer节点通过Query Peers报文，查询在Gather服务器中存储的处于同一群组内的其他Peer节点，当前播放同一视频的Peer被划归在同一群组内。

第五、每一个Peer节点通过Query Explore报文，查询向自己发布流的其他Peer节点。

第六、每一个Peer节点通过Query Stream报文，查询自己向其他Peer节点发布的流。

第七、每一个Peer节点通过Publish Stream报文，向Gather服务器注册自己发布的流。

第八、每一个Peer节点通过Heart Beat报文向Gather服务器维持保活状态。

第九、每一个Peer节点经由所述RTMFP服务器，与想要进行通信的对端Peer节点进行内网穿越NAT Relay，所述内网穿越NAT Relay成功后，两个Peer节点即可进行数据分享传输。

上述详细描述通过实施例和/或示意图阐明了系统和/或过程的各种实施例。就这些示意图和/或包含一个或多个功能和/或操作而言，本领域技术人员将理解，这些示意图或实施例中的每一个功能和/或操作都可由各种各样的硬件、软件、固件、或实际上其任意组合来单独地和/或共同地实现。

应该理解，本文描述的方法可以结合硬件或软件，或在适当时结合两者的组合来实现。因此，本发明的方法，可以采用包含在诸如软盘、CD-ROM、硬盘驱动器或任何其他机器可读存储介质等有形介质中的程序代码（即，指令）的形式，其中，当程序代码在可编程计算机上执行的情况下，计算设备通常包括处理器、该处理器可读的存储介质(包括易失性存储器和/或存储元件)、至少一个输入设备、以及至少一个输出设备。一个或多个程序可以例如，通过使用API，可重用控件等来实现或利用结合本发明描述的过程。这样的程序优选地用高级过程语言或面向对象编程语言来实现，以与计算机系统通信。然而，如果需要，该程序可以用汇编语言或机器语言来实现。在任何情形中，语言可以是编译语言或解释语言，且与硬件实现相结合。

需要说明的是，本发明的一种Flash P2P避开安全沙箱的方案的范畴包括但不限于上述各部分之间的任意组合。

尽管具体地参考其优选实施例来示出并描述了本发明，但本领域的技术人员可以理解，可以做出形式和细节上的各种改变而不脱离所附权利要求书中所述的本发明的范围。以上结合本发明的具体实施例做了详细描述，但并非是对本发明的限制。凡是依据本发明的技术实质对以上实施例所做的任何简单修改，均仍属于本发明技术方案的范围。