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
Attachment:
test.log.gz
Description: GNU Zip compressed data
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
