It is impossible to match a tracker alert to a specific source
glassez opened this issue · comments
It is impossible to match an tracker alert to a specific source (i.e. announce_infohash) with which it is associated. Currently tracker_alert has only tracker_url and local_endpoint fields that aren't enough to determine exact source:
libtorrent/include/libtorrent/alert_types.hpp
Line 207 in beb9dbc
libtorrent/include/libtorrent/alert_types.hpp
Line 210 in beb9dbc
At least it has also contains
protocol_version. But even better it could contains the announce_infohash itself to allow receiver to obtain more info without the extra (blocking and wasteful) call to torrent_handle::trackers().@arvidn
If there is no reason for such changes to be discarded, I could implement them myself and provide PR.
I agree that would be useful information in the tracker alerts. It’s easy to add, however, it’s an ABI break on the C++ side.
it could be done with a new alert type.. or maybe some other trick
it’s an ABI break on the C++ side.
I'm not familiar with ABI compatibility issues, but would adding a couple of new methods to a tracker_alert class break it? Of course, we will have to keep the existing methods/constructors in order to maintain compatibility with the existing code.
Adding fields at the end of the class should be fine. Those objects are always allocated by libtorrent and only accessed through pointers. The risk is a client built against a new version but then run on a system with an older version, where those fields don’t exist, it will reference garbage memory, and possibly segfault
The risk is a client built against a new version but then run on a system with an older version, where those fields don’t exist, it will reference garbage memory, and possibly segfault
Isn't it just going to fail at startup without being able to find the necessary functions with which it is linked? This is exactly the behavior I observe on Windows if I try to run application with unsuitable DLLs.
@arvidn, so what's your answer? Do you prefer to leave such things unfixed for the sake of ABI compatibility? Then what about the idea of new alerts? I could implement it. But I'm not sure about their naming. Is there any good way to do this so as to simplify the future major update when you can get rid of the old alerts? Or is it not that important?
Also it would be really useful for to be notified when endpoint list of announce_entry is refreshed.
looking into this; the tracker_alert derives from torrent_alert which already has a handle member, which is the torrent_handle to the corresponding torrent.
As far as I can tell, the only missing piece of information is which version info-hash (v1 or v2) was announced, is that right?
how does this look? #6877
As far as I can tell, the only missing piece of information is which version info-hash (v1 or v2) was announced, is that right?
Yes, it looks like this is the minimum that needs to be fixed.
how does this look? #6877
It looks incomplete.
It looks incomplete.
You mean because I didn't add the field to the scrape alerts?
It looks incomplete.
You mean because I didn't add the field to the scrape alerts?
No, for some reason I didn't think about them.
I meant tracker_warning_alert, even though I care less about it. For my purposes, it is not particularly useful, since it is accompanied by tracker_reply_alert (I would even suggest merging them together).
I actually meant the changes in the torrent.cpp. They affect only tracker_error_alert.
I see. This is where the protocol version is added to the tracker_reply_alert: https://github.com/arvidn/libtorrent/pull/6877/files#diff-a17ad09f87450b4293a08e2811c13e572239db6a0bd378d22291a79fd1f5f072R3517
I see. This is where the protocol version is added to the
tracker_reply_alert: https://github.com/arvidn/libtorrent/pull/6877/files#diff-a17ad09f87450b4293a08e2811c13e572239db6a0bd378d22291a79fd1f5f072R3517
Ok.
But still, what about the rest of tracker alerts? They shouldn't be changed? Then why is your comment about moving protocol version field in base tracker_alert?
But still, what about the rest of tracker alerts? They shouldn't be changed? Then why is your comment about moving protocol version field in base tracker_alert?
That comment is a reminder to move the field to where it belongs in master, since it affects the ABI it can only be added to leaf classes in the hierarchy. So the patch is a bit of a hack, so I was thinking of limiting it to the most important alerts. It's not that big of a deal though, I should probably just add it to all of them.
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.