Problems using BitTornado for file distribution

I'm experimenting with BitTornado-0.3.17 to distribute a file to several machines (*nix). I ran into couple of problems while doing so. Here is what I have done so far.

1. Download BitTornado-0.3.17.tar.gz from http://download2.bittornado.com/download/BitTornado-0.3.17.tar.gz and untar it.
2. Created a torrent file and started tracker following instructions in the README file.
3. Started a seeder

./btdownloadheadless.py ../BitTornado-0.3.17.tar.gz.torrent --saveas ../BitTornado-0.3.17.tar.gz

saving:         BitTornado-0.3.17.tar.gz (0.2 MB)
percent done:   0.0
time left:      Download Succeeded!
download to:    /h开发者_JAVA技巧ome/srikanth/BitTornado-0.3.17.tar.gz
download rate:  
upload rate:    0.0 kB/s
share rating:   0.000  (0.0 MB up / 0.0 MB down)
seed status:    0 seen recently, plus 0.000 distributed copies
peer status:    0 seen now, 0.0% done at 0.0 kB/s

1. Now we have a seeder. I start a peer on another machine to download BitTornado-0.3.17.tar.gz.

   ./btdownloadheadless.py BitTornado-0.3.17.tar.gz.torrent

At this point I do not observer my peer to download data from seeder. However if I kill my seeder and start again, the peer immediately downloads from the seeder. Why is it happening this way? The first time seeder reports tracker, tracker should be aware of the seeder and share that information to newly joined peer. Its happening only when I start seeder after peer joins the network.

Has anyone used BitTornado to distribute files programmatically (not using GUI tools at all.) ?

Thanks :-)

EDIT: Here is what happened a few days later. I dig into tracker logs and figure that seeder is binding itself onto a private ip address interface and reporting it. It is causing other clients to not reach seeder. hence no download. So I passed --ip options to it, which made it to report the tracker the machine's public ip address to which it bound. Even then for some reason i couldn't get client to download from seeder. However I got it working by starting client first and seeder last. This worked for me consistently. I can't think of any reason why it shouldn't work the other way. So, I'm starting clients first and then starting seeder.

All the symptoms indicate only one of your machines is able to connect to the other (in this case, the "seeder" machine). Restarting the "seeder" means it announces to the tracker and gets the other peers info, then connects. If the downloader is unconnectable, it simply cannot do anything until the seeder sees its IP.

This may be also related to rerequest_interval in download_bt1.py or reannounce_interval in track.py. Setting them to smaller values may help you debug if the tracker receives and distributes the right information.

When I diff BitTornado with twitter murder code, I found a little different. Especially the at line 75 of Downloader.py file:

self.backlog = max(50, int(self.backlog * 0.075))

this will fix the bug, download uncomplete.