reqq question
=============
reqq:
An integer, the number of outstanding request messages this client supports
without dropping any. The default in in libtorrent is 250.
"handshake message" @ "Extension Protocol"
@ http://www.bittorrent.org/beps/bep_0010.html
TODO: maybe by requesting all pieces at once we are exceeding this limit? maybe
we should request as we receive pieces?
answer
======
almost every single peer I encountered (for brief 10 minutes... which I think
is enough) had 255 as reqq value and the number of metadata pieces we requested
very rarely exceeded 20... I think it's fair to assume that exceeding "that
limit" will never be a question, and requesting the next piece as we receive
the previous one might increase the latency, unnecessarily.
magneticod:
!!! disabled the gradual increase in congestion control, for some reason we still can't detect congestion...
- `*net.UDPAddr` in dht/mainline instead of `net.Addr`
- fixed a bug when a very small extension message received
- simplified how peer adress is handled in bittorrent/metadata/sink
- simplified TrawlingResult in dht/mainline
magneticow:
- use WAL for sqlite3
persistence:
- use URL.String() instead of url.Path in sql.Open() so that URL parameters are not lost...
