Discussion:
[libtorrent] Sending data to choked peer
Ardhi Putra Pratama
2016-11-02 15:36:46 UTC
Permalink
Hello,

I confused with the peer_info flags and attribute interpretation.

When I invoked get_peer_info(), I got a list of peer connected
(+connecting) to a particular swarm. One of the peer (called X), is
flagged as 'choked'. In the documentation, it means : "we have choked
this peer.". However, I got non-zero value on up_speed and
payload_up_speed. As far as I know, if we choked someone, we wont
upload any data to them. Is this a bug?


Btw, I also notice that my previous questions haven't been answered
yet. Can someone take a look at it? Those are :
1. https://sourceforge.net/p/libtorrent/mailman/message/35419928/
2. https://sourceforge.net/p/libtorrent/mailman/message/35419873/


Kind regards,
ardhi
Arvid Norberg
2016-11-02 21:45:33 UTC
Permalink
Post by Ardhi Putra Pratama
Hello,
I confused with the peer_info flags and attribute interpretation.
When I invoked get_peer_info(), I got a list of peer connected
(+connecting) to a particular swarm. One of the peer (called X), is
flagged as 'choked'. In the documentation, it means : "we have choked
this peer.". However, I got non-zero value on up_speed and
payload_up_speed. As far as I know, if we choked someone, we wont
upload any data to them. Is this a bug?
up_speed includes protocol chatter, like HAVE and REQUEST messages. This is
not expected to always be zero for choked peers.

With the FAST excention (from 2006 or so), choked peers are allowed to
request a small number of pieces allocated to them based on their IP
address.

see ALLOW_FAST.
Post by Ardhi Putra Pratama
Btw, I also notice that my previous questions haven't been answered
1. https://sourceforge.net/p/libtorrent/mailman/message/35419928/
What's left is measure the swarm. I call get_peer_info periodically.
However, none of the peers have any 'interest' in me. (which is
understandable as I don't have any piece). Is there any way to 'fake'
this, so I can report to other peer like I have 'complete' file? The
purpose is to know which peer that has interest in each of my piece. I
just need the number, though. Is there any way to know which is the
rarest piece from the public API?


You can disable hash checking and call add_piece with garbage data to make
it look like you have those pieces. You should probably disable uploading
as well in that case, otherwise you'll be banned and disconnected from
peers.
Post by Ardhi Putra Pratama
2. https://sourceforge.net/p/libtorrent/mailman/message/35419873/
I noticed that, peer tends to disconnect because of time out in very
small period. In the documentation, it should be 15 seconds (look
"peer_connect_timeout"). However, in my case, it around 4.5 second,
somehow.


There are some cases where the timeout is shorter, specifically when the
peer is expected to respond right away.

The handshake is one such case, another is unchoking a peer that is
interested, if it doesn't request anything within a certain time it may
also time out.
The easiest way to debug this is probably to set a break point in
peer_connection::disconnect and see where it's getting called from
--
Arvid Norberg
Ardhi Putra Pratama
2016-11-07 07:41:44 UTC
Permalink
Thanks for the answers, Arvid.

If I disabled FAST extension, theoretically it won't send any payload
piece, right?

A bit out of topic, the 'rtt' value is 0 for most of the peers. It may
be because they connect to me instead of tried to connect to them
(based on the http://libtorrent.org/reference-Core.html#peer_info). I
want to get the rtt for all the peer I connected to. What I have done
is disconnecting each of them with 0 rtt, and call connect_peer to
those addresses. However, I still found the rtt with 0 value. Did I
miss something here?

For the 'add_piece', I wonder if it stores the pieces in the memory. I
tried to use that with a large number of torrents and my program
eventually will be killed by the OS because of OOM (out of memory)

Regards,
ardhi
--
Ardhi Putra Pratama
@ardhipoetra

Delft University of Technology
Post by Arvid Norberg
Post by Ardhi Putra Pratama
Hello,
I confused with the peer_info flags and attribute interpretation.
When I invoked get_peer_info(), I got a list of peer connected
(+connecting) to a particular swarm. One of the peer (called X), is
flagged as 'choked'. In the documentation, it means : "we have choked
this peer.". However, I got non-zero value on up_speed and
payload_up_speed. As far as I know, if we choked someone, we wont
upload any data to them. Is this a bug?
up_speed includes protocol chatter, like HAVE and REQUEST messages. This is
not expected to always be zero for choked peers.
With the FAST excention (from 2006 or so), choked peers are allowed to
request a small number of pieces allocated to them based on their IP
address.
see ALLOW_FAST.
Post by Ardhi Putra Pratama
Btw, I also notice that my previous questions haven't been answered
1. https://sourceforge.net/p/libtorrent/mailman/message/35419928/
What's left is measure the swarm. I call get_peer_info periodically.
However, none of the peers have any 'interest' in me. (which is
understandable as I don't have any piece). Is there any way to 'fake'
this, so I can report to other peer like I have 'complete' file? The
purpose is to know which peer that has interest in each of my piece. I
just need the number, though. Is there any way to know which is the
rarest piece from the public API?
You can disable hash checking and call add_piece with garbage data to make
it look like you have those pieces. You should probably disable uploading
as well in that case, otherwise you'll be banned and disconnected from
peers.
Post by Ardhi Putra Pratama
2. https://sourceforge.net/p/libtorrent/mailman/message/35419873/
I noticed that, peer tends to disconnect because of time out in very
small period. In the documentation, it should be 15 seconds (look
"peer_connect_timeout"). However, in my case, it around 4.5 second,
somehow.
There are some cases where the timeout is shorter, specifically when the
peer is expected to respond right away.
The handshake is one such case, another is unchoking a peer that is
interested, if it doesn't request anything within a certain time it may
also time out.
The easiest way to debug this is probably to set a break point in
peer_connection::disconnect and see where it's getting called from
--
Arvid Norberg
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
Arvid Norberg
2016-11-14 01:44:10 UTC
Permalink
Post by Ardhi Putra Pratama
Thanks for the answers, Arvid.
If I disabled FAST extension, theoretically it won't send any payload
piece, right?
as far as I can tell, yes, that's correct.
Post by Ardhi Putra Pratama
A bit out of topic, the 'rtt' value is 0 for most of the peers. It may
be because they connect to me instead of tried to connect to them
(based on the http://libtorrent.org/reference-Core.html#peer_info). I
want to get the rtt for all the peer I connected to. What I have done
is disconnecting each of them with 0 rtt, and call connect_peer to
those addresses. However, I still found the rtt with 0 value. Did I
miss something here?
You may not be able to connect back to the peers. They may be behind NAT.
If they reconnect to you, you'll still see them show up with RTT 0. There's
a field in the peer_info about whether it's an incoming connection or not
though.
Post by Ardhi Putra Pratama
For the 'add_piece', I wonder if it stores the pieces in the memory. I
tried to use that with a large number of torrents and my program
eventually will be killed by the OS because of OOM (out of memory)
Yes, it allocates memory for the piece and posts a job to the disk thread
which will write it out. If you try to write all pieces back-to-back, the
disk may not be able to keep up and you'll get essentially all pieces sit
in RAM while waiting.

You could solve that by throttling the calls to add_piece to only have some
fixed number in-flight at any given time. When you see a piece_finished
alert you can replenish the queue.
--
Arvid Norberg
Loading...