Closed GoogleCodeExporter closed 8 years ago
the map_file() function was intended to map to peer_requests (as the return
type indicates). A peer request may not be larger than 16 kiB. The reason to
not trivially extend the width of the return types is that the peer_requests
type is actually used internally as well, and widening would use more memory
and be less efficient (in fact, it should probably be shrunk).
I'm actually surprised python gave such a good error message. I imagine in c++
you would just get a wrapped signed integer.
The way examples/dump_torrent gets around this (really though, it isn't trying
to do the same thing as you do), is to call map_file() twice, once for the
first byte and once for the last. It's just looking to see which pieces they
fall into.
I'm inclined to improve the documentation and close this ticket, unless you
have some compelling argument for introducing a new type, different from
peer_request, with wider byte counters in it, as the return type for map_file().
Original comment by arvid.no...@gmail.com
on 8 Apr 2015 at 11:41
Thanks for quick response and explanation.
I agree - it was misunderstanding of map_file function, from my side, in fact
piece index and offset is enough for me, because size I already know.
So please if you can close this issue,
Ivan
Original comment by ivan.zde...@gmail.com
on 9 Apr 2015 at 8:35
Original comment by arvid.no...@gmail.com
on 10 Apr 2015 at 3:27
Original issue reported on code.google.com by
ivan.zde...@gmail.com
on 8 Apr 2015 at 8:48