BitTorrent将资源分成很多个piece，BitTorrent如何选择piece的下载次序，一个良好的块下载的调度策略可以增强网络的健壮性。
1.最简单，你可以采用随机的选择。在p2p中，当需要一个调度策略的时候，有时候随机直接采用随机，达到的效果也还不错，而且随机实现很简单。
2.一个比较好的策略是，在网络中越是稀有的Piece越是优先下载，当然，如果计算得出的稀有程度相同，这时候就随机就可以了。这种办法可以提高整个系 统的性能，因为如果全部随机的话，那万一大家一段时间都没有随机到某个piece，而这时候种子又下线了，那么所有人都下不到完整资源了。而且BT客户端 下载了一个稀有piece后，就可以马上为其他人提供这个稀有的piece了。那么我们怎样计算一个piece的稀有程度呢，最理想的是整个网络全局的稀 有程度，那最好了， 但是在p2p网络中，单个peer是很难知道全局信息的，所以BitTorrent的下载策略计算稀有程度是在peer的它连接的所有其他peers中计算的，也就是一个局部的信息。即便这样，这种方法仍然比随机选择要好的多。
3.由于piece又被分成多个block，请求和传输的最小单位是block，所以当某个piece的一个block获得了或者发出去了请求，那么剩下的block的优先级将最高。这样做是为了尽可能快获取一个完整的piece。
4.下载的最后阶段。BT客户端应当向它连接的所有peers都发出请求，也就是冗余的请求，以便尽快完成下载。如果某个block接收到了，BT客户端 应当立即向其他peers发出cancel包，取消请求。那这里也存在一个关键问题，如何来界定是否到达最后阶段了？这个问题也一直被很多人讨论，用百分 比?用剩余block个数?等等。个人认为，用剩余block个数来界定是比较合理的。有一种就是取剩余block个数小于正在传输的block个数并且 不超过20个的情况作为判断条件。
5.BT阻塞算法（下面这些内容来自互联网）
BT提倡peer之间尽可能多的相互共享。对于合作者，提供上传服务，对于不合作的，就阻塞对方。所以说，阻塞是一种临时的拒绝上传策略，虽然上传停止 了，但是下载仍然继续。在阻塞停止的时候，连接并不需要重新建立。阻塞算法并不属于BT对等协议（指peers 之间交互的协议）的技术部分，但是对提高性能是必要的。一个好的阻塞算法应该利用所有可用的资源，为所有下载者提供一致可靠的下载速率，并适当惩罚那些只 下载而不上传的peers。
从技术层面上说，BT的每个peer一直与固定数量的其它 peers 保持疏通（通常是4个，(这个也太少了吧)），所以问题就变成了哪些peers应该保持疏通？这种方法使得TCP的拥塞控制性能能够可靠的饱和上传容量。 （也就是说，尽量让整个系统的上传能力达到最大）。
严格的根据当前的下载速率来决定哪些peers应该保持疏通。令人惊讶的是，计算当前下载速率是个大难题。当前的实现实质上是一个每隔20秒的轮询。而原来的算法是对一个长时间的网络传输进行总计，但这种方法很差劲，因为由于资源可用或者不可用，带宽会变化的很快。
为了避免因为频繁的阻塞和疏通 peers造成的资源浪费，BT每隔10秒计算一次哪个peer需要被阻塞，然后将这种状态保持到下一个10秒。10秒已经足够使得TCP来调整它的传输性能到最大。
optimistic unchoking
如果只是简单的为提供最好的下载速率的peers们提供上载，那么就没有办法来发现那些空闲的连接是否比当前正使用的连接更好。为了解决这个问题，在任何 时候，每个peer都拥有一个称为“optimistic unchoking”的连接，这个连接总是保持疏通状态，而不管它的下载速率是怎样。每隔30秒，重新计算一次哪个连接应该是“optimistic unchoking”。30秒足以让上载能力达到最大，下载能力也相应的达到最大。这种和针锋相对类似的思想非常的伟大。“optimistic unchoking”非常和谐的与“囚徒困境”合作。
反对歧视
某些情况下，一个peer可能被它所有的peers都阻塞了，这种情况下，它将会保持较低的下载速率直到通过“optimistic unchoking”找到更好peers。为了减轻这种问题，如果一段时间过后，从某个peer那里一个片断也没有得到，那么这个peer认为自己被对方 “怠慢”了，于是不再为对方提供上传，除非对方是“optimistic unchoking”。这种情况频繁发生，会导致多于一个的并发的“optimistic unchoking”。
仅仅上传
一旦某个peer完成了下载，它不能再通过下载速率（因为下载速率已经为0了）来决定为哪些 peers 提供上载了。目前采用的解决办法是，优先选择那些从它这里得到更好的上载速率的peers。这样的理由是可以尽可能的利用上载带宽。
1.最简单，你可以采用随机的选择。在p2p中，当需要一个调度策略的时候，有时候随机直接采用随机，达到的效果也还不错，而且随机实现很简单。
2.一个比较好的策略是，在网络中越是稀有的Piece越是优先下载，当然，如果计算得出的稀有程度相同，这时候就随机就可以了。这种办法可以提高整个系 统的性能，因为如果全部随机的话，那万一大家一段时间都没有随机到某个piece，而这时候种子又下线了，那么所有人都下不到完整资源了。而且BT客户端 下载了一个稀有piece后，就可以马上为其他人提供这个稀有的piece了。那么我们怎样计算一个piece的稀有程度呢，最理想的是整个网络全局的稀 有程度，那最好了， 但是在p2p网络中，单个peer是很难知道全局信息的，所以BitTorrent的下载策略计算稀有程度是在peer的它连接的所有其他peers中计算的，也就是一个局部的信息。即便这样，这种方法仍然比随机选择要好的多。
3.由于piece又被分成多个block，请求和传输的最小单位是block，所以当某个piece的一个block获得了或者发出去了请求，那么剩下的block的优先级将最高。这样做是为了尽可能快获取一个完整的piece。
4.下载的最后阶段。BT客户端应当向它连接的所有peers都发出请求，也就是冗余的请求，以便尽快完成下载。如果某个block接收到了，BT客户端 应当立即向其他peers发出cancel包，取消请求。那这里也存在一个关键问题，如何来界定是否到达最后阶段了？这个问题也一直被很多人讨论，用百分 比?用剩余block个数?等等。个人认为，用剩余block个数来界定是比较合理的。有一种就是取剩余block个数小于正在传输的block个数并且 不超过20个的情况作为判断条件。
5.BT阻塞算法（下面这些内容来自互联网）
BT提倡peer之间尽可能多的相互共享。对于合作者，提供上传服务，对于不合作的，就阻塞对方。所以说，阻塞是一种临时的拒绝上传策略，虽然上传停止 了，但是下载仍然继续。在阻塞停止的时候，连接并不需要重新建立。阻塞算法并不属于BT对等协议（指peers 之间交互的协议）的技术部分，但是对提高性能是必要的。一个好的阻塞算法应该利用所有可用的资源，为所有下载者提供一致可靠的下载速率，并适当惩罚那些只 下载而不上传的peers。
从技术层面上说，BT的每个peer一直与固定数量的其它 peers 保持疏通（通常是4个，(这个也太少了吧)），所以问题就变成了哪些peers应该保持疏通？这种方法使得TCP的拥塞控制性能能够可靠的饱和上传容量。 （也就是说，尽量让整个系统的上传能力达到最大）。
严格的根据当前的下载速率来决定哪些peers应该保持疏通。令人惊讶的是，计算当前下载速率是个大难题。当前的实现实质上是一个每隔20秒的轮询。而原来的算法是对一个长时间的网络传输进行总计，但这种方法很差劲，因为由于资源可用或者不可用，带宽会变化的很快。
为了避免因为频繁的阻塞和疏通 peers造成的资源浪费，BT每隔10秒计算一次哪个peer需要被阻塞，然后将这种状态保持到下一个10秒。10秒已经足够使得TCP来调整它的传输性能到最大。
optimistic unchoking
如果只是简单的为提供最好的下载速率的peers们提供上载，那么就没有办法来发现那些空闲的连接是否比当前正使用的连接更好。为了解决这个问题，在任何 时候，每个peer都拥有一个称为“optimistic unchoking”的连接，这个连接总是保持疏通状态，而不管它的下载速率是怎样。每隔30秒，重新计算一次哪个连接应该是“optimistic unchoking”。30秒足以让上载能力达到最大，下载能力也相应的达到最大。这种和针锋相对类似的思想非常的伟大。“optimistic unchoking”非常和谐的与“囚徒困境”合作。
反对歧视
某些情况下，一个peer可能被它所有的peers都阻塞了，这种情况下，它将会保持较低的下载速率直到通过“optimistic unchoking”找到更好peers。为了减轻这种问题，如果一段时间过后，从某个peer那里一个片断也没有得到，那么这个peer认为自己被对方 “怠慢”了，于是不再为对方提供上传，除非对方是“optimistic unchoking”。这种情况频繁发生，会导致多于一个的并发的“optimistic unchoking”。
仅仅上传
一旦某个peer完成了下载，它不能再通过下载速率（因为下载速率已经为0了）来决定为哪些 peers 提供上载了。目前采用的解决办法是，优先选择那些从它这里得到更好的上载速率的peers。这样的理由是可以尽可能的利用上载带宽。
扫一扫
1299
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
