Announce to all trackers if IP changed

[zhuangzi926]

Update

2021.05.22

• Try to squash all commits into one but failed, and the original PR accidentally closed Announce to all trackers if IP changed #14650.
• Relocate m_isReannouncdWhenAddressChangedEnabled init in session.cpp

2021.05.20

• Remove redundant codes and fix coding style
• Rename *ReannounceWhenAddressChanged to *ReannounceWhenAddressChangedEnabled

2021.05.18

• Relocate methods in session.h and session.cpp
• Fix coding styles in session.cpp
• Change m_lastExternalIP from QHostname to QString
• Extract duplicated reannounce loops into a single class method
• Relocate declarations in advancedsettings.h, advancedsettings.cpp and appcontroller.cpp
• Remove redundant urls in appcontroller.cpp

Motivation

Try to implement this feature request: issue #14545.

Considering many users run qbt behind NATs, it's quiet cumbersome for them to tolerate frequent torrent not available issue because of public IP change.

So I came up with this direct idea to regularly detect public ip catch external IP change alert from libtorrent, and announce it to all trackers if change happens.

Brief of this PR

• Add a timer in BitTorrent::Session to send a public ip address request to http://api64.ipify.org every 30 mins.
• Once public ip address change is detected, force announce to all trackers.
• Once external IP change alert is captured or our user deliberately sets a new listening port, reannounce to all trackers without delay.
• This new feature is optional, and can be toggled during running time, default is false.
• GUI checkboxes in advanced setting on both desktop and web ui are included.
• Update dyndns service register url to the latest one.

About external/public IP detection

Although it's known that libtorrent can get extern ip through communications with trackers and peers, it seems that libtorrent only catches this ip change alert but not try to reannounce to improve efficiency. Moreover, the interval of external ip detection behavior by libtorrent is uncertain and unpredicatable(to some extent) for downstream apps like qbt, it would probably be better to implement this logic by qbt itself.

I have found identical codes in src/base/net/dnsupdater.cpp, which uses a timer to ask public dns provider to update domain-ip binding if ip changed. Reimplemention of this logic in BitTorrent::Session might introduce incompatibility problems, which may need assistance from professional reviewers.

It is now known that libtorrent catches external IP change alert in an interval of 5 minutes, and qbt regularly reannounce(if ignore tracker settings) every 30 minutes. So it would be better if we implement this feature request by adding an option to force reannounce when external IP or listening port changes(before this PR qbt just catches these alerts but sends nothing). There is no need to introduce a new QTimer or external IP request from another third party.

Control this feature by GUI users

GUI control to set ip detection interval and switch on/off this new feature are needed for our end-users.

I'm not good at coping with codes in src/gui, hoping other contributors might help with this new feature.

GUI checkboxes for both desktop and web ui are implemented following 5161758.

[zhuangzi926]

@Chocobo1 @thalieht @glassez I reopened #14650 in this new PR.

I tried to git rebase to squash all commits, but accidentally closed the old PR...

[glassez]

Last comment from me.

[glassez]

I would rewrite it as the following :

if (m_lastExternalIP != externalIP)
{
    if (!m_lastExternalIP.isEmpty() && isReannounceWhenAddressChangedEnabled())
        reannounceToAllTrackers();
    m_lastExternalIP = externalIP;
}

[zhuangzi926]

Fixed

[FranciscoPombal]

Shouldn't some of these commits be squashed @glassez @Chocobo1? Otherwise, LGTM.

[glassez]

Shouldn't some of these commits be squashed @glassez @Chocobo1?

Of course, it makes sense to have only one commit here. But as I understand it, the author has a problem with this. Fortunately, we recently changed the merge policy so that it can/will be squashed when merged.

[FranciscoPombal]

Of course, it makes sense to have only one commit here. But as I understand it, the author has a problem with this. Fortunately, we recently changed the merge policy so that it can/will be squashed when merged.

Cool, just checking. I got a little scared after seeing your approval already, but now it makes sense :)

[Chocobo1]

@zhuangzi926
Thank you!