J
Jp Hastings-spital
(Bear with me, there's a reason this is on ruby-forum)
Bittorrent downloads can be a pain when there are no seeders at all. I
propose a special client, run in tandem with any bittorrent client
(there are some requirements, I'll go through these later) that would
allow an appropriately set-up torrent to always have at least one peer.
The basic concept: This new client finds the "pieces" of the torrent
file from alternate sources, namely the http-web (sites like
rapidshare.com, mediafire.com, but not exclusively so, even ftp and
basic hosting could be used).
In detail:
For the uninitiated: torrents work by splitting the target files into
pieces (usually of 64KB,128KB,512KB or 1MB in size) each piece has its
SHA1 hash taken and put into the .torrent file, along with a 'tracker'
url (eg. piratebay.org), this .torrent file is then distributed.
When a peer wants to download the files in the torrent, it will (very
broadly) query the 'tracker' to get a list of computers with that
specific torrent available, go through the list of SHA1 hashes and then
query each of these computers asking for some of the pieces needed (by
using the SHA1 hash).
The problem arises when the tracker lists no computers as having the
torrent available, then there is nowhere to download the file from!
My proposed solution: the initial seeder (or anyone with the torrent and
the files) generates hundreds of files, each containing exactly one
piece of the torrent data, and named by the SHA1 hash referring to that
piece. A number of these files are put into a zip file and uploaded to
rapidshare.com/mediafire.com/an ftp site/anywhere. The URL of the zip
file is put into a bookmarking site (I've actually built a very simple
dedicated bookmarking system for this purpose) and the URL is tagged
with something like:
'torrent
iece=01234_the_pieces_sha1_hash_here_BCDEF' - once for each of
the pieces contained within the zip. (The URL would also be tagged with
the 'infohash' of the torrent, allowing the file to be associated with a
specific torrent)
My proposed client would search the bookmarking site for any URLs
containing any pieces that might be needed by the 'real' bittorrent
client, would download them, extract the zip and provide the piece to
the 'real' bittorrent client as if it were a local peer.
--
So, I've written a (painfully hack-ish) script to create these zips and
upload them (in ruby) but I'd now like to go about modifying rubytorrent
(http://rubytorrent.rubyforge.org/) - old tho it is - to work as one of
these 'fake' peers.
Do you think this is a reasonable idea?
Can 'Local Peer Discovery' be used in reverse to find out what
torrents/pieces a specific client is looking for?
- (The proposed bonjour/zeroconf announcing of torrents/pieces would
have worked for this, but I'm unsure as to how Local Peer Discovery
works - as implemented by uTorrent etc)
Love to hear anyone's opinion, usability, feasibility or any other
'bility-ways, Cheers, JP
Bittorrent downloads can be a pain when there are no seeders at all. I
propose a special client, run in tandem with any bittorrent client
(there are some requirements, I'll go through these later) that would
allow an appropriately set-up torrent to always have at least one peer.
The basic concept: This new client finds the "pieces" of the torrent
file from alternate sources, namely the http-web (sites like
rapidshare.com, mediafire.com, but not exclusively so, even ftp and
basic hosting could be used).
In detail:
For the uninitiated: torrents work by splitting the target files into
pieces (usually of 64KB,128KB,512KB or 1MB in size) each piece has its
SHA1 hash taken and put into the .torrent file, along with a 'tracker'
url (eg. piratebay.org), this .torrent file is then distributed.
When a peer wants to download the files in the torrent, it will (very
broadly) query the 'tracker' to get a list of computers with that
specific torrent available, go through the list of SHA1 hashes and then
query each of these computers asking for some of the pieces needed (by
using the SHA1 hash).
The problem arises when the tracker lists no computers as having the
torrent available, then there is nowhere to download the file from!
My proposed solution: the initial seeder (or anyone with the torrent and
the files) generates hundreds of files, each containing exactly one
piece of the torrent data, and named by the SHA1 hash referring to that
piece. A number of these files are put into a zip file and uploaded to
rapidshare.com/mediafire.com/an ftp site/anywhere. The URL of the zip
file is put into a bookmarking site (I've actually built a very simple
dedicated bookmarking system for this purpose) and the URL is tagged
with something like:
'torrent
iece=01234_the_pieces_sha1_hash_here_BCDEF' - once for each ofthe pieces contained within the zip. (The URL would also be tagged with
the 'infohash' of the torrent, allowing the file to be associated with a
specific torrent)
My proposed client would search the bookmarking site for any URLs
containing any pieces that might be needed by the 'real' bittorrent
client, would download them, extract the zip and provide the piece to
the 'real' bittorrent client as if it were a local peer.
--
So, I've written a (painfully hack-ish) script to create these zips and
upload them (in ruby) but I'd now like to go about modifying rubytorrent
(http://rubytorrent.rubyforge.org/) - old tho it is - to work as one of
these 'fake' peers.
Do you think this is a reasonable idea?
Can 'Local Peer Discovery' be used in reverse to find out what
torrents/pieces a specific client is looking for?
- (The proposed bonjour/zeroconf announcing of torrents/pieces would
have worked for this, but I'm unsure as to how Local Peer Discovery
works - as implemented by uTorrent etc)
Love to hear anyone's opinion, usability, feasibility or any other
'bility-ways, Cheers, JP