On 18 June 2010 20:46, David Barrett <[email protected]> wrote: >> >> The purpose of the currency in robonobo is not to enforce >> seeder:leecher ratios, but rather to allocate bandwidth within the >> swarm. > > I think that somewhat makes sense, but I wonder if most of the same > effect could be had by simply having the application built to > voluntarily download slower if there are other swarm members that claim > they want streaming performance? >
You wrote earlier about altruistic behaviour in BitTorrent, but I don't think this compares. Good citizenship in BT (keeping a high upload ratio) comes at a very low cost to the altruist: essentially it just involves donating some spare upload capacity for some time after the download has finished, which doesn't impact most other activities too greatly - and if it does, one can suspend seeding for a while and resume it later. Voluntarily giving up one of the primary goals of the downloader (getting the content as fast as possible) is a different ask. As an analogy to your proposed system: if under BitTorrent there were a 'loophole' in the protocol that allowed a node to get faster downloads at the expense of other nodes in the swarm, I am fairly certain it would be exploited. You are right in saying that the majority of users won't hack about with their clients, but if the incentive is great enough (and I would argue that any significant increase in download speed would be enough), someone will write a modified client, and if any client gets consistently better speeds, it would quickly become very popular, and other clients would be forced to exploit the loophole. There must be some BT client implementors on this list; has there ever been such a competitive advantage for a specific client? > Granted, if the swarm has a high seeder:leecher ratio (which it should > be if the content is popular), then probably everybody can download as > fast as possible and none of this matters. > Yes and no. Standard BitTorrent is not capable of delivering real-time streaming, no matter how many seeds there are, because chunks are downloaded out of order. BiToS does do in-order downloads, and contains some great ideas (which I've pinched for robonobo), but this means sacrificing the barter system because a leecher with 30% done has no chunks useful to a leecher with 40% done. I've never been able to get BiToS to deliver real-time content reliably, which I've always ascribed to this, but perhaps list members can suggest other reasons. > > However, if someone wants to stream *and* if it's finding that it can't > stream due to not having a sufficient download rate, it could just > broadcast "hey dudes, I want to stream but I can't, can you help a > brother out and slow down your download to free up capacity?" > I tried this first, and it doesn't work because you have no reliable way of telling whether your insufficient download speed is due to network limitation or competition from another node - and if the latter, which node is the competing one. I don't believe that a reliable real-time streaming p2p app can be created in top of vanilla TCP for this reason. W _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
