组播协议研究.pptx

组播协议研究; 主要内容;单播 发送者与每个接收者进行数据传送 广播 发送者发送数据到相同局域网内的所有接收者 组播 发送者发送数据给一组接收者;组播分类 IP组播 由路由器将数据转发给多个接收者，实现在网络层 优点：减轻网络负载和发送者的负担，具有很高的性能 缺点：缺乏快速部署能力 应用层组播 转发功能由接收者完成 优点：实现在应用层，不依赖于底层的网络层，具有快速的部署能力 缺点：存在重复的传送路径，导致性能比IP组播低 ; 主要内容;IP组播协议分类 ;IP组播协议分类（续）;IP组播协议分类（续）;IP组播协议分类（续）;NAK爆炸ACK爆炸 错误恢复 缓存管理 重传控制 拥塞控制 树构建方法 反馈控制 吞吐量分析 ;问题描述 基于ACK组播 发送者给每一个接收者发送数据包时，若接收者接收到数据包，则发送一个ACK给发送者 发送者将接收到大量ACK，如果发送者不能及时处理，则导致ACK爆炸 基于NAK组播 发送者给每一个接收者发送数据包时，若接收者没有接收到数据包，则发送一个NAK给发送者 与基于ACK的组播相比降低了反馈的数量，仍会出现NAK爆炸的问题;解决方法 Baek针对NAK爆炸问题提出一种在组播中考虑包丢失的空间位置的NAK抑制方法 针对包丢失的不同位置，例如在修复节点或是接收者节点，分别对其进行抑制 优点：降低接收者的反馈数量，具有快速的错误恢复能力 缺点：没有考虑树的高度，若是树的高度太大，则错误恢复的延迟会变得很突出;问题描述 数据包的传送过程中，存在数据包丢失的情况 解决方法（1） RRMP:分布式错误恢复协议 根据与发送者的距离,接收者被分成几个不同的组，即本地区域和远程区域 当出现错误时，首先在本地区域进行恢复，若是不能恢复再进行远程恢复 优点：可以实现快速的错误恢复 缺点：当存在两个或多个成员同时检测到消息丢失时，存在冗余的请求 ;解决方法（2） LRRM：采用一种后退算法抑制请求 当一个节点检测到消息时，在组播请求之前，它会等待任意的时间，若在此时间内收到其他成员的组播请求，则其会抑制自身的请求 优点：可以更好更快地实现错误恢复 缺点：不适合动态地环境，如有频繁的节点加入和离开的情况 ;问题描述 什么时间从修复节点的缓存中将存储的包抛弃 太晚：导致修复节点缓存空间的无效使用 太早：导致有些未接收包的接收者的重传请求不能完成 解决方法 Baek提出一种启发式的方法从修复节点的缓存中抛弃包 每一个修复节点预测不需要重传的包并将其从修复节点的缓存中移除 它预测哪些接收者节点不可能丢失包 丢失的包由这些接收者节点重传而不是由发送者节点或者修复节点重传 ;问题描述 基于树的协议中一般包的重传由指定的接收者完成 但某些重传由修复节点完成，若这些由修复节点完成的额外重传不能得到有效的控制，将会导致NAK爆炸 解决方法（1） Baek提出一种有效的方法进行重传控制 基本思想：基于每一个组的接收者都有一个或多个成员，他们的错误率比其他成员的错误率低 任何被其他成员请求的包但其已经被修复节点抛弃的包将有可能被这些成员之一正确地传送 ;解决方法（2） Saikia提出一种改进的方法 设计点：RH（receiver Head）可被传播在大的区域，但其缓存存在限制，而发送者的缓存容量很大，虽然不是无限的 基本思想：若在中间节点RH上，未满足接收者的NAK，则数据不会从发送者的缓存中抛弃，直到数据被所有的接收者节点应答 优点：保证RH具有可用的缓存资源 ;问题描述 发送者的发送率超过接收者的接收能力 导致大量的组播包涌入到网络并且不能及时反应 一段时间之后，发送者会重新发送没有被应答的包 接收者的负担进一步加重，最后系统进入严重的恶性循环中 解决方法 Liu预测拥塞的发生 通过公式计算发送者的拥塞抑制率，使得吞吐量和包丢失之间保持平衡 通过公式计算缓存的容量，使得发送率和处理率之间保持平衡 通过得到的拥塞控制率和缓存容量预测拥塞的发生;问题描述 怎样以有效的方式构建一棵逻辑传送树 现有的方法只考虑修复节点决定接受或拒绝新接收者的能力 解决方法 Baek考虑每一个接收者的丢失概率 估计每个组的数学平均丢失概率 不允许接收者节点，以不正常的丢失概率加入组并降低组的性能;问题描述 如何对反馈进行控制 包丢失由组成员发送反馈消息进行报告，导致著名的反馈爆炸问题 解决方法 Time-based方法 在每个成员发送反馈之前，等待一段随机或者固定的时间，若是在时间停止之前接收到其他的反馈，则抑制自身反馈 Hierarchy-based方法 将组织成员分别到不同的层次上，在其层次结构上限制反馈;问题描述 解决方法 DHARM方法：将在发送者与接收者之间丢失恢复的责任进行分布 源处理在连接上接近于源的丢