Elaborate on streaming API and strategy #6293
Conversation
AllSeeingEyeTolledEweSew
force-pushed
the
asetes-streaming-doc-2
branch
from
e8425c7 to
4213ebb
Compare
| do with the "leftover" bandwidth once the critical window is fulfilled. One idea | ||
| is to use classic rarest-first picking to download the rest of the torrent, as | ||
| this can mitigate the problems of sequential downloading, and keeps request | ||
| queues full. |
There was a problem hiding this comment.
what's described as a "one idea is to" here is in fact what libtorrent does. I'm worried that phrasing it like this may suggest to the reader that this is not necessarily what libtorrent does.
There was a problem hiding this comment.
I suppose this is clarified further down
There was a problem hiding this comment.
I'm using a first-principles approach to documenting streaming logic and functions, because it seems to be a cutting-edge area. I think documenting our basis of understanding is crucial. In contrast, we don't need to document why libtorrent uses rarest-first picking, because there's plenty of information available on the topic.
I believe the lack of clarity has left users confused, and having wrong expectations of libtorrent.
Recent user discussions end up disregarding time-critical logic in favor of sequential_download ([1], [2]). Since time-critical logic is intended to be a better version of sequential_download, I conclude either these users don't understand it, or couldn't figure out how to make set_piece_deadline work in a context that lacks well-defined deadlines.
Code examples I can find in the wild which use set_piece_deadline ([1], [2], [3]) seem to use it wrong. Judging by that code, I suspect there's a prevailing belief that the intent of set_piece_deadline() is to download a piece within the next N milliseconds. Said another way, I think a lot of users are confused between deadline and timeout.
I think it would be really helpful to link to a project that uses set_piece_deadline in the intended way, where deadlines are well-defined, e.g. in a video player. I couldn't find any though.
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Unstale. I'd still like to figure this out. |
This comment has been minimized.
This comment has been minimized.
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
I've been reading a lot trying to get a handle on torrent streaming, how libtorrent supports it and how its support should be used.
I updated
streaming.rstwith my findings, both to validate them and to help anyone else in this space (it seems there are a couple people working actively on streaming right now).Please let me know if anything's inaccurate or incomplete.
In particular, I'm boldly assuming the best growth-friendly API usage is that users should call
set_piece_deadline()for a whole file, and use other mechanisms to dynamically constrain the time-critical set. I lean this way because I can think of some other such mechanisms to try, but I doubt I've thought of everything. Please let me know if you have different ideas.