Discussion:
[libtorrent] Accurate peer list based on alerts
Bedeho Mender
2017-05-16 13:18:11 UTC
Permalink
It seems there is no way to maintain an accurate list of connected peers on
a torrent, using only events?

One can of course use torrent_handle::get_peer_info, however that is a
polling operation.

One does have the alert peer_connected_alert, however it is only triggered
for outgoing connections. For incoming connections one does
have incoming_connection_alert, however it is not a peer_alert, hence one
cannot associate it with a particular endpoint and swarm.

Is it indeed not possible to do this?

Bedeho
ᐧ
Arvid Norberg
2017-05-17 00:13:19 UTC
Permalink
Post by Bedeho Mender
It seems there is no way to maintain an accurate list of connected peers on
a torrent, using only events?
One can of course use torrent_handle::get_peer_info, however that is a
polling operation.
One does have the alert peer_connected_alert, however it is only triggered
for outgoing connections. For incoming connections one does
have incoming_connection_alert, however it is not a peer_alert, hence one
cannot associate it with a particular endpoint and swarm.
Is it indeed not possible to do this?
That sounds correct. There is no technical reason to not have a peer_alert
for when a peer connects to a swarm. It's just a matter of capturing the
edge of attach_to_torrent() on the peer. I'd be happy to apply a patch that
adds such alert.

Ideally the naming conventions would be such that it's obvious which alerts
go together (i.e. which one adds a peer and which one removes a peer)
--
Arvid Norberg
Bedeho Mender
2017-05-17 07:59:30 UTC
Permalink
Arvid,

Thank you for the prompt response and gracious offer.

We are trying to work around it for now, but we may reconsider this
approach, so it would be nice to have this option.

Perhaps more importantly, we had for a long time assumed this one alert
covered all established connections on a swarm, so we saw a lot of strange
behaviour.
The subtle point of distinguishing when a connection is established, and
when we know what swarm a connection corresponds to, had not occurred to us.
This is of course our fault for not reading the docs properly on this
alert, but its an easy mistake to make with the current name.

Perhaps this could make things clearer

* connection_established_alert (rather than, or in addition
to, peer_connected_alert)
- add field which indicates whether a connection is inbound or outbound
- is triggered whenever any type of connection is established, prior to
any handshake, hence it would no longer be a peer_alert, since this
requires knowing the torrent swarm.
This is unlike peer_connected_alert, which is only sent when an outbound
connection is established, and hence we know what swarm we are trying to
join.

* connection_closed_alert (rather than, or in addition to, old
peer_disconnected_alert)
- is triggered whenever a connection is closed, for whatever reason. This
is unlike peer_disconnected_alert, which
is not triggered when a peer is disconnected due to a wire protocol error,
which instead triggers peer_error_alert.

* connection_joined_swarm
- is triggered whenever we receive a valid handshake from peer

This approach is quite different to what is currently in place, however it
seems easier to work with, and less likely to lead to misunderstandings.

Bedeho
ᐧ
Post by Bedeho Mender
Post by Bedeho Mender
It seems there is no way to maintain an accurate list of connected peers
on
Post by Bedeho Mender
a torrent, using only events?
One can of course use torrent_handle::get_peer_info, however that is a
polling operation.
One does have the alert peer_connected_alert, however it is only
triggered
Post by Bedeho Mender
for outgoing connections. For incoming connections one does
have incoming_connection_alert, however it is not a peer_alert, hence one
cannot associate it with a particular endpoint and swarm.
Is it indeed not possible to do this?
That sounds correct. There is no technical reason to not have a peer_alert
for when a peer connects to a swarm. It's just a matter of capturing the
edge of attach_to_torrent() on the peer. I'd be happy to apply a patch that
adds such alert.
Ideally the naming conventions would be such that it's obvious which alerts
go together (i.e. which one adds a peer and which one removes a peer)
--
Arvid Norberg
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
Murray S. Kucherawy
2017-06-09 21:37:13 UTC
Permalink
Post by Bedeho Mender
Post by Bedeho Mender
It seems there is no way to maintain an accurate list of connected peers
on
Post by Bedeho Mender
a torrent, using only events?
One can of course use torrent_handle::get_peer_info, however that is a
polling operation.
One does have the alert peer_connected_alert, however it is only
triggered
Post by Bedeho Mender
for outgoing connections. For incoming connections one does
have incoming_connection_alert, however it is not a peer_alert, hence one
cannot associate it with a particular endpoint and swarm.
Is it indeed not possible to do this?
That sounds correct. There is no technical reason to not have a peer_alert
for when a peer connects to a swarm. It's just a matter of capturing the
edge of attach_to_torrent() on the peer. I'd be happy to apply a patch that
adds such alert.
Ideally the naming conventions would be such that it's obvious which alerts
go together (i.e. which one adds a peer and which one removes a peer)
That would let you identify any peer that ever participated in any part of
the swarm, but is there (or could there be) a definitive way to extract the
subset of those that have all pieces? It seems that even for the torrent
finished alert, some of the peers that are full seeds might have
disconnected, so the set wouldn't be complete there.

-MSK
Bedeho Mender
2017-06-16 10:15:30 UTC
Permalink
I guess libtorrent::peer_info::pieces would tell you that for each peer?
ᐧ
Post by Bedeho Mender
Post by Bedeho Mender
Post by Bedeho Mender
It seems there is no way to maintain an accurate list of connected
peers
Post by Bedeho Mender
on
Post by Bedeho Mender
a torrent, using only events?
One can of course use torrent_handle::get_peer_info, however that is a
polling operation.
One does have the alert peer_connected_alert, however it is only
triggered
Post by Bedeho Mender
for outgoing connections. For incoming connections one does
have incoming_connection_alert, however it is not a peer_alert, hence
one
Post by Bedeho Mender
Post by Bedeho Mender
cannot associate it with a particular endpoint and swarm.
Is it indeed not possible to do this?
That sounds correct. There is no technical reason to not have a
peer_alert
Post by Bedeho Mender
for when a peer connects to a swarm. It's just a matter of capturing the
edge of attach_to_torrent() on the peer. I'd be happy to apply a patch
that
Post by Bedeho Mender
adds such alert.
Ideally the naming conventions would be such that it's obvious which
alerts
Post by Bedeho Mender
go together (i.e. which one adds a peer and which one removes a peer)
That would let you identify any peer that ever participated in any part of
the swarm, but is there (or could there be) a definitive way to extract the
subset of those that have all pieces? It seems that even for the torrent
finished alert, some of the peers that are full seeds might have
disconnected, so the set wouldn't be complete there.
-MSK
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
Loading...