max_peerlist_size == 0 seems to actually mean "zero" peerlist size, not "unlimited"

[GoogleCodeExporter]

What steps will reproduce the problem?
1. set max_peerlist_zize=0 to session, via python bindings
2. start seeding on machine A
3a. try to download on machine B by infohash (using stock metadata transfer)
3b. try to download on machine B via full metadata available (e.g. with 
*.torrent file).
4. timeout in both 3a and 3b :-/

What is the expected output? What do you see instead?
as stated in manual - peer list should be unlimited in that case. At least new 
connections should be made :). But after starting libtorrent on two machines 
I'm expiriencing huge problems:

last alert from libtorrent says "libtorrent: 
[c74e265c19bafba40ce30e865bc642b82eca4c37] tracker_reply_alert: 
c74e265c19bafba40ce30e865bc642b82eca4c37 (udp://cmsearch01.yandex.ru:2399) 
received peers: 2". So, it get 1 more peer. Libtorrent even seem to make 
outbound connection (at least, I see it via sockstat in bsd on both machines). 
But it never downloads anything. Fails to dl metadata by infohash and also 
fails to dl full torrent if I'll provide *.torrent data.

But if I'll restart libtorrent on machine 1 (this is seeder) it will make 
connection to machine B (which is leecher) and B will download torrent.

What version of the product are you using? On what operating system?
0.15.3 (tried also 0.15.1, freebsd amd64 and linux amd64/x86)

Please provide any additional information below.

That was veeeeeeeeeeeery hard to find this. I'm so tired, cant go down into 
your sources and find "oops" piece of code, sorry.. :). Set max_peerlist_size 
to something huge (e.g. 9999999) works like a charm.

max_paused_peerlist_size == 0 does not affect downloading in my case as I see, 
but for safety I'll set it to 9999999 to. Is that ok?

Original issue reported on code.google.com by mocksoul on 15 Sep 2010 at 7:33

[GoogleCodeExporter]

I cannot reproduce this. Setting max_peerlist_size to 0 still lets me connect 
to peers and download. I went through the code to look for all the places where 
max_peerlist_size is used and I couldn't find a single place it was used 
incorrectly.

are you sure max_peerlist_size is the only difference between the runs that 
work and don't work for you?

Original comment by arvid.no...@gmail.com on 22 Sep 2010 at 5:13

[GoogleCodeExporter]

I'll make more research on this soon, ok. Dont close ticket.

Original comment by mocksoul on 22 Sep 2010 at 12:11

[GoogleCodeExporter]

Tried myself, and yes, everything works fine. Probably this issue was related 
to default small alert queue size and I just was not able to analyze alerts in 
python before queue overfilled and some of them were completely thrown away.

Close this. Not an issue.

Original comment by mocksoul on 15 Nov 2010 at 5:25

[GoogleCodeExporter]

Nope. Dont close :).

Actually it fails with max_peerlist_size = 0 to download metadata from torrent 
(I'm using ut_metadata plugin for that).

Last message I see from libtorrent is:
libtorrent : state_changed_alert: metadata: state changed to: dl metadata

and it stucks forever.

Original comment by mocksoul on 16 Nov 2010 at 11:08

[GoogleCodeExporter]

Futhermore. Mashine which having .torrent file seems to refuse others to dl 
metadata from it. Because, setting back to 999999 does not fixes problem. But 
if I set also 999999 on machine with full file -- dl metadata completes in one 
second :).

Original comment by mocksoul on 16 Nov 2010 at 11:17