fix(communities)_: delay starting torrent client until connection is established #5125
Conversation
friofry
force-pushed
the
ab/issue-14510-fix-torrent-start
branch
from
8c4682f
to
76538ee
Compare
Jenkins BuildsClick to see older builds (12)
|
| err := m.StartTorrentClient() | ||
| if err != nil { | ||
| m.LogStdout("couldn't start torrent client", zap.Error(err)) | ||
| } |
There was a problem hiding this comment.
Should this also stop the client if !online ?
There was a problem hiding this comment.
Hey @0x-r4bbit,
yeah, I have thought about stopping the client when !online. But I have 2 concerns:
-
StartTorrentClientcreates a new instance ofTorrentClient. This means that any previous calls totorrentClient.AddTorrentmay be lost (e.g. it's called fromSeedHistoryArchiveTorrent). And the same forAddMagnet. Is it okay to rebuildtorrentClientwithout restoring torrents/magents?
To be on the safe side I only use thesetOnlinemethod to delay the creation of theTorrentClient. -
There is also an api call
EnableCommunityHistoryArchiveProtocol (and Disable)that starts/stops thetorrentClient(which could currently be called from the Desktop Settings). And I thought that the behaviour ofsetOnlineandEnableCommunityHistoryArchiveProtocolmight be inconsistent.
Maybe I'm missing other problems.
There was a problem hiding this comment.
There is also an api call EnableCommunityHistoryArchiveProtocol (and Disable) that starts/stops the torrentClient (which could currently be called from the Desktop Settings). And I thought that the behaviour of setOnline and EnableCommunityHistoryArchiveProtocol might be inconsistent.
Yes, as a matter of fact, back then, it was a requirement for the torrent to always be bootstrapped when using desktop clients. The setting to enable/disable the protocol was more of a thing for development (this might have changed by now).
Considering that, it indeed makes sense to keep the client running once it has started (unless the protocol is disabled entirely).
The reason I brought this up here is because I thought, when !online, the torrent client might cause high CPU usage again, but maybe that's not the case?
There was a problem hiding this comment.
Yes, as a matter of fact, back then, it was a requirement for the torrent to always be bootstrapped when using desktop clients. The setting to enable/disable the protocol was more of a thing for development (this might have changed by now).
Considering that, it indeed makes sense to keep the client running once it has started (unless the protocol is disabled entirely).
I see, thank you for clarifying that.
The reason I brought this up here is because I thought, when !online, the torrent client might cause high CPU usage again, but maybe that's not the case?
Yes, the torrent client only uses a lot of CPU when it's started while offline.
Here I'm enabling and disabling the network, but the CPU usage remains low:
torrent_goes_offline.mp4
friofry
force-pushed
the
ab/issue-14510-fix-torrent-start
branch
from
76538ee
to
7a16a96
Compare
…established Fixes # 14510
friofry
force-pushed
the
ab/issue-14510-fix-torrent-start
branch
from
7a16a96
to
5a76c98
Compare
Messengeris subscribed to connectivity status updates. Whenever status is updated,MessengercallsManager.setOnlineManagerlaunches TorrentClient on first connectionCloses status-im/status-desktop#14510