Extra torrent handle piece and file functions

[YakoYakoYokuYoku]

This PR contains extra functionality regarding piece and file ranges. My gst-libtorrent module requests many pieces at time for buffering during multimedia streaming, but having to do so requires loop boilerplate which could be simplified. I could write my own methods, but part of them cannot be done in my project so I have no to implement them in this library. This could be handy for other projects as well.

[arvidn]

are adding the following functions to torrent_handle:

• read_piece_range()
• have_piece_range()
• set_piece_range_deadline()
• get_piece_priorities()

All of those can be implemented outside of libtorrent. I think you need a strong argument why it should be part of libtorrent in order to include it.

I would prefer to land new features like these either in RC_2_1 or `master.

get_piece_priorities() duplicates existing functionality already.

[YakoYakoYokuYoku]

All of those can be implemented outside of libtorrent. I think you need a strong argument why it should be part of libtorrent in order to include it.

Due to the code performing synchronous and asynchronous calls, which the methods to do so are private in the torrent_handle class, I have to implement these functions here to avoid doing lots of unnecessary invocations. This is more apparent in the case of reading contiguous pieces. If I were to do so in my code, for each and every piece an async call has to be done and their disk IO jobs have to be submitted individually, whereas with this PR a single async call is done and it can submit many jobs at once. The case of setting and clearing deadlines is also a similar situation with the additional constraint of timing.

I would prefer to land new features like these either in RC_2_1 or master.

Sure, I can change the target branch of this PR.

get_piece_priorities() duplicates existing functionality already.

I know, but this library also provides methods which either return or modify a vector, examples of it are the torrent_handle::get_download_queue and torrent_handle::file_progress functions. If the code looks duplicate I can fix it.

[arvidn]

you prefer to have the loop live in libtorrent instead of your client code. It sounds like you're saying it's for performance reasons, but it's not obvious. Do you have any measurements?

disk I/O jobs being submitted individually is the case regardless. The disk I/O subsystem reads 16kiB blocks.

Even if you move the loop into libtorrent, your client code would need to pipeline those requests, so I don't think you can get rid of all accounting on your side. I suppose requesting larger ranges obscures the problems that you have in the seams, because you'll have fewer of them.