字节加
第1页共8页
f一，e9034401的数据分发每个数据包是一致的。每一个节点都主动连接含有数据的上线，这可以从节点没有频繁和连续的accept动作看出。否则用户在获取数据之前必定有一组连续accept的被连接过程。一旦选择一个速度最高的节点，则播放所需所有数据都从这个节点获得。这点从获取数据包的流密度和各IP数据包之间的对比可知。在防火墙穿透策略上，经分析得知每个节点把自己的ip地址和开放的端口号汇报到服务器，服务器把这些信息通知有连接需要的节点。节点不区分获得的ip是公网ip还是内网ip（丛发出的udp测速数据包目标经常为1921680网段可知）。如果是公网的节点发起连接，连接公网ip的节点一般可以正常连接，如果连接内网ip的节点，肯定无法连接。如果是内网节点发起连接，连接公网ip的节点一般可以正常连接，如果连接内网ip的节点，分为两种情况：1、此节点位于不同局域网中，肯定连接不上；2、此节点位于同一局域网中，正好实现了内网互联。由此可知数据分发引擎完全不具备不同局域网的节点连接能力，网络性能非常依赖公网节点数量。按照这种模式开发流媒体产品，对不同媒体格式和媒体服务器的兼容性较好，节点之间连接策略的处理也比较简单高效。但难点在于如何把流媒体服务器和数据分发层连接，和如何模拟流媒体服务器和播放器握手。这部分技术确实可以解决，但之前没有考虑过实现细节。节点开始播放流媒体之前，必须和服务器建立连接，获得节点列表，然后判断节点之间的联通性。和可以连通的节点建立连接，尝试获得数据填充本地缓冲区。在此过程中，判断速度较高的节点。在持续连接建立后，已经可以获得稳定数据，继续保持低速的连接的发起，遇到更高速的节点，则转向由更高速的节点提供数据（此动作为分析得知，没有非常明确的证据）。二、ppstream：ppstream内嵌了浏览器，太多80端口的操作严重干扰了对socket的分析。但是出乎意料，ppstream的连接建立过程比pplive清晰得多！ppstream的缓冲等待画面位于播放窗口内，而不是像pplive那样由数据分发引擎的单独窗口显示。具体内容为嵌入flash的html页面。由61172197242的服务器提供节目表和频道表等内容，webServer：Apache2054U
ixPHP440。6115219956似乎是广告的web服务器。ppstream和pplive共有的关键字串应该是验证协议。连接61152240252：11012，回复xml格式的广播源信息，可阅读内容为从61152240252获得广播源信息后，开始连接大量节点，握手过程等同于r