Bug 377289 – net-p2p/mldonkey: use bw_toggle in the init.d script to control bandwidth

• Product: Gentoo Linux
• Status: RESOLVED OBSOLETE

[Description Dennis Nezic 2011-08-01 15:17:40 UTC]

Currently mldonkey's init.d script uses the web interface's "set max_hard_???_rate" to set it to run "fast" or "slow" (as defined in /etc/conf.d/mldonkey). But this overrides and conflicts with mldonkey's own way of controlling this -- currently it allows for two rate-settings (the variables max_hard_download_rate_2, max_hard_upload_rate_2 and max_opened_connections_2 controlling the second state.) Mldonkey's "bw_toggle" command swaps those two sets of state variables, instead of simply switching between them, so there is a risk that one of the settings will get lost if I run "/etc/init.d/mldonkey <fast|slow>" -- it will overwrite whatever is in max_hard_download_rate, max_..., without backing them/swapping them into the max_hard_download_rate_2, max_....

Also, "bw_toggle [<high|low>]" makes things simpler. (BTW, it "high" in here means the state with more max indirect connections -- not necessarily the faster state :\... and if that number is equal, I don't think it toggles.)

I've attached a patch for fun. It gets rid of gentoo's ability to explicitly configure the bandwidth, as well as the "info" init.d function -- I figured these things are better handled within mldonkey itself, rather than remaking an mldonkey interface in the init.d script :p -- although if we really want that additional control, we could stay with the old non-bw_toggle way, and add a bunch of additional wget's to properly read and swap those 3 bandwidth settings. (Ie. to be aware of whether the user bw_toggled the settings on his own via mldonkey's interface, rather than gentoo's.)

Reproducible: Always

[Comment 1 Dennis Nezic 2011-08-01 15:18:34 UTC]

Created attachment 281751 [details]
the simpler way using bw_toggle

[Comment 2 Dennis Nezic 2021-01-12 17:48:28 UTC]

I think it's been long enough that we can close this issue. I prefer doing it the gentoo way now.

[Comment 3 Sam James 2021-01-12 17:49:50 UTC]

(In reply to Dennis Nezic from comment #2)
> I think it's been long enough that we can close this issue. I prefer doing
> it the gentoo way now.

Understood, thank you for the update!