Artem Petrov
2015-12-11 10:23:05 UTC
Hi! Arvid, thank you for fast reply.
I'm using libtorrent 1.0.7, and it is released from RC_1_0 branch.
Behavior, which you had described in previous mail is valid for master
branch, however for RC_1_0 piece picker works in a different way: in case
when almost all pieces are downloaded and the other parts are in
downloading state piece picker will return some random block from list of
downloading blocks, which was already requested by some other connection.
As result, this single block will be requested from web seed.
Do you have plan and when is it supposed to release desired behaviour?
P.S. The previous private mails are below separated with lines.
Best Regards,
Artem
----------------------------------------------------
The short answer is, that is a good idea and I would expect it to already
be the case. I assume you have some empirical experience of it not being
the case, which probably means there's a bug.
from memory, this is how I recall it to work:
when prefer whole pieces is enabled, and the preferred size is greater than
a piece, the piece picker will primarily look for pieces that have no
requests to them. If it finds one, it will then try to expand to pieces
before it and pieces after it, and requests those.
If all pieces have requests to them, it will start looking for the highest
priority piece and pick as many contiguous blocks as possible from it.
Once the piece picker is done, the actual coalescing of adjacent block
requests happens in web_peer_connection::write_request().
If you'd like to look into the case you have in mind, I would strongly
encourage you to take a look at test/test_piece_picker.cpp. There's a
section that exercises the contiguous block logic, but I'm sure there are
cases not covered there. Having a test case that expose the problem you're
seeing is the best way of having it fixed and stay fixed.
--------------------------------------------------------
Hello,
I'm interesting in optimizing block sizes which are requested
from web seeds. I took a look at the thread
https://sourceforge.net/p/libtorrent/mailman/message/34373739/.
<https://sourceforge.net/p/libtorrent/mailman/message/34373739/>
prefer_whole_pieces
logic really gives a nice advantage by requesting all pieces at once, but
in case when one 16Kb block from a piece was obtained from other peer type
all the remaining piece will be downloaded via 16Kb blocks, no matter from
what peer.
So the question is: is it good idea to modify piece picker to request the
largest possible block of partially downloaded piece from peer with
prefer_whole_pieces=1?
E.g. if the first 16 Kb block of 2 Mb piece was downloaded from any peer we
can make range request for downloading remaining 2032 Kb at once
from web peer.
Do you see some side effects of this "improvement"?
------------------------------------------------------------------------------
I'm using libtorrent 1.0.7, and it is released from RC_1_0 branch.
Behavior, which you had described in previous mail is valid for master
branch, however for RC_1_0 piece picker works in a different way: in case
when almost all pieces are downloaded and the other parts are in
downloading state piece picker will return some random block from list of
downloading blocks, which was already requested by some other connection.
As result, this single block will be requested from web seed.
Do you have plan and when is it supposed to release desired behaviour?
P.S. The previous private mails are below separated with lines.
Best Regards,
Artem
----------------------------------------------------
The short answer is, that is a good idea and I would expect it to already
be the case. I assume you have some empirical experience of it not being
the case, which probably means there's a bug.
from memory, this is how I recall it to work:
when prefer whole pieces is enabled, and the preferred size is greater than
a piece, the piece picker will primarily look for pieces that have no
requests to them. If it finds one, it will then try to expand to pieces
before it and pieces after it, and requests those.
If all pieces have requests to them, it will start looking for the highest
priority piece and pick as many contiguous blocks as possible from it.
Once the piece picker is done, the actual coalescing of adjacent block
requests happens in web_peer_connection::write_request().
If you'd like to look into the case you have in mind, I would strongly
encourage you to take a look at test/test_piece_picker.cpp. There's a
section that exercises the contiguous block logic, but I'm sure there are
cases not covered there. Having a test case that expose the problem you're
seeing is the best way of having it fixed and stay fixed.
--------------------------------------------------------
Hello,
I'm interesting in optimizing block sizes which are requested
from web seeds. I took a look at the thread
https://sourceforge.net/p/libtorrent/mailman/message/34373739/.
<https://sourceforge.net/p/libtorrent/mailman/message/34373739/>
prefer_whole_pieces
logic really gives a nice advantage by requesting all pieces at once, but
in case when one 16Kb block from a piece was obtained from other peer type
all the remaining piece will be downloaded via 16Kb blocks, no matter from
what peer.
So the question is: is it good idea to modify piece picker to request the
largest possible block of partially downloaded piece from peer with
prefer_whole_pieces=1?
E.g. if the first 16 Kb block of 2 Mb piece was downloaded from any peer we
can make range request for downloading remaining 2032 Kb at once
from web peer.
Do you see some side effects of this "improvement"?
------------------------------------------------------------------------------