Dritte‘s BitMate may solve the problems I touched in my last post and may serve as a solution for the mapping crowd including OSM HOT. Schuyler ran into this problem in Haiti as did Jeff and I in Indo. By circulating data locally it eliminates the need to burn up costly bandwidth. I am sure Aptivate will take note.
From the Dritte site:
A BitMate client achieves good performance under low-bandwidth conditions by the following key design principles:
- Minimize Wasted Goodwill:A BitMate client minimizes “wasted” goodwill. Instead of trying to earn goodwill from high-bandwidth nodes, which rarely reciprocate due to a bandwidth mismatch, a BitMate client utilizes its limited bandwidth to earn goodwill with other low-bandwidth peers with which it can establish the most mutually beneficial tit-for-tat connections. As a result, low-bandwidth clients talk to each other more often, helping each other download faster. In doing so, BitMate clients also reduce the arbitrage between their upload and download bandwidth, minimizing the element of free-riding associated with low-bandwidth peers.
- Don’t Compete Unnecessarily:Instead of competing with each other to download the same blocks from high-bandwidth peers, BitMate clients download distinct blocks of a file (that other low-bandwidth nodes have not already downloaded) from high bandwidth peers. This improves performance since low-bandwidth clients download from (reluctant) high-bandwidth peers only when necessary. In essence, by avoiding competition for the same blocks, low-bandwidth BitMate clients “pool” their bandwidth when talking to high bandwidth clients. This also improves fairness since it minimizes the data gratuitously downloaded by low-bandwidth clients from higher bandwidth peers — instead encouraging mutually beneficial tit-for-tat connections between matching low-bandwidth peers.
- Avoid Redundant Downloads:A BitMate client is watchful when downloading data from other clients and only downloads from those peers that have it unchoked at the time of download. As a result, a low-bandwidth BitMate node makes faster progress in stringing together a piece and avoids redundant downloads due to “premature chokes” by higher bandwidth peers. This also reduces the element of free riding by not downloading from nodes that have choked a low-bandwidth node.
- Share Aggressively:A BitMate client does not wait for a piece to download completely before sharing it with other peers. Instead, BitMate implements pipelined uploads to enable uploading by low-bandwidth clients that are otherwise struggling to string together a piece in the face of repeated chokes by other peers. As a result, a BitMate client can start earning goodwill with other peers (by uploading blocks of a piece) quickly while traditional clients are struggling to string together a piece before starting upload
- Minimize Cross-ISP Traffic:BitMate is designed to minimize cross-ISP traffic without adversely affecting the performance of a low-bandwidth client. However, unlike previous work like Ono, which bias peer selection solely based on the proximity of the peers, BitMate matches peer locality as well as bandwidth. The goal of our work is not to find local peers that may offer better bandwidth due to better path properties, but to find bandwidth-matched peers that may also help reduce congestion on the upstream link of a developing-world ISP.
Overall, a low-bandwidth BitMate client prefers stable, bandwidth-matched peers over the greedy strategy of vanilla BitTorrent. Instead of wasting optimistic unchokes on high bandwidth peers, a BitMate client optimistically unchokes those peers that have a similar low-bandwidth. As a result, a BitMate client invests its scarce upload bandwidth on peers that are most likely to reciprocate. At the same time, BiTMate leaves the tit-for-tat reciprocal unchoke policy untouched to uphold the fairness of BitTorrent. This leads to both increased performance and fairness since low-bandwidth clients can quickly form mutually beneficial peer-to-peer connections.
More at CNN Money/Fortune/GigaOm.
