#3 crash while seeding

[Anonymous]

Well, kenosis isn't as error free as it claims to be.

I made a kenosis-enabled .torrent file, and then I
started a tracker/kenosis node (at port 7969/7970), and
I started btdownloadheadless.py (or
btdownloadcurses.py) to seed the torrent. After
checking the file (thus just before it starts seeding),
I get the following trace:

resolving Kenosis address for node
0x9b03eeaa7e69842290fd530f1cf223e12a0e8324 (url
http://bef554b56914acfef195b37ed8bf90b58fb77527.bt.kenosisp2p.org:6969/announce\)
Traceback (most recent call last):
File "/usr/bin/btdownloadheadless.py", line 166, in ?
run(argv[1:])
File "/usr/bin/btdownloadheadless.py", line 161, in run
download(params, h.chooseFile, h.display,
h.finished, h.error, Event(), cols, h.newpath)
File
"/usr/lib/python2.3/site-packages/BitTorrent/download.py",
line 295, in download
encoder.ever_got_incoming, kenosisNode=kenosisNode)
File
"/usr/lib/python2.3/site-packages/BitTorrent/Rerequester.py",
line 42, in __init__
trackerNetAddress = "%s:%s" % (netHost, trackerPort)
UnboundLocalError: local variable 'trackerPort'
referenced before assignment

However, it works fine if I supply <my own ip>:7970 as
kenosis boot-node, or if I run my tracker/node at port
6969/6970.

I tried having Azureus download the file for a while
(while my tracker is t port 6969/6970, and this worked
fine.
Then I quit the seed and my tracker, and restarted the
tracker at port 7969/7970. When I now start the seed
again, it want to connect to port 7969 at
67.164.12.28:7969... and it gives a connection refused
error. I think it doesn't crash anymore with the above
trace because now there is another tracker serving the
torrent.

If you need any more info, please let me know.

[malcolm handley]

Logged In: YES
user_id=655047

Interesting. The code is certainly broken because it does not cover the
case where we do not find any nodes.

The only case that I can think of that would cause this (and I guess that
we only need one) is where we become unable to communicate with the
bootstrap node after bootstrapping (loss of connectivity, the node went
down, etc) and have no other nodes in our routing table.

To fix this we should detect the case where findNearestNodes returns an
empty list and either fall back to using the dns or raise an error
immediately.