[CentOS] Trackerless torrents (was: Can't connect to torrent tracker)

[William L. Maltby]

On Thu, 2007-12-20 at 07:59 -0500, William L. Maltby wrote:
> On Thu, 2007-12-20 at 00:32 +0100, Kai Schaetzl wrote:
> > Kenneth Porter wrote on Wed, 19 Dec 2007 14:08:56 -0800:
> > 
> > > Perhaps the next CentOS torrents can add the appropriate records to take 
> > > advantage of this?
> > 
> > AFAIK, there is nothing special about it, nothing to add. A DHT aware 
> > client just connects to other DHT clients and these again other clients to 
> > find those clients that have the torrent or parts of it available. It just 
> > works - if there are clients that already have the file and got it with the 
> > same torrent file, so the hash matches.

Given: the bittorrent client available from rpmforge is old (5.2 stable
are out there and 6.0-beta, but it seems both need porting to RH/CentOS
before we can test/use them). I don't know if it is DHT-enabled. I've
subscribed to the Rpmforge mailing list to see if there is a way I can
help make the newer ones available. It'll be slow going because many of
the prerequisites are not (transparently) met. It does look as if there
are some alternative implementations of the needed GTK, wx, twisted, ...
items. But I know nothing about them and can't tell if that is true. I
think Dag and Co. will be able to point me in the right direction.

Conclusion: current bittorrent from Rpmforge will not operate
successfully on a tracked torrent without access to the tracker, AFAICT.

Activity log attached.

If others would like to emulate this test with other clients/OSs, I
would find it interesting.

> 
> AFAICT now, at lease an initial successful connection with a tracker,
> some time previously or currently, or multiple trackers specified in the
> torrent file is needed to initialize everything if the primary (only?)
> tracker is unavailable.

If one emulates the activities detailed in the log, with modifications
toward testing if any of the clients connect when no record of a tracker
ever being seen exists, I would find the results interesting. Further,
one could also test when a tracker has previously been seen, but is
currently unavailable. I would also find that of interest.

> 
> So the "special" requirements seem to be at least one successful
> tracker-begun session by a DHT-enabled client or multiple trackers
> specified in the torrent file to allow "fail over" when the primary
> server is down and a DHT-enabled client is making its first attempt.

Anyone want/able to test this supposition if they find they have a
client that will operate when the tracker is not available?

> <snip>

Finally, it *seems* to me that a torrent must be somehow specified as
trackerless for bittorrent (and others?) to handle a tracked torrent
when no tracker is available. This is a supposition by me from various
non-extensive readings of things during this test.

-- 
Bill
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.log.gz
Type: application/x-gzip
Size: 1825 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos/attachments/20071223/ede118fe/attachment.bin>