aMule Forum
English => Feature requests => Topic started by: Morse on December 27, 2010, 06:54:49 PM
-
And again I am going to ask the possibility to switch off the core without actually shutting it down. Although Kry already told once that he "doesnt see the point of making the option 'not to down-/up- load' for the app the sole purpose of which is down-/-up load" (do not remember where), but I still think that at least for amuled it's a good idea.
Now, I'm faced with the problem to teach my mother to use several p2p clients. And if amuleGUI is something she can comprehend, ssh console and other stuff is far from that. Not to say that i DO NOT want to give her sudo privileges.
There are some reasons why i don't want always to run amuled with 1/1 limits, most important being the shitting in NAT port forwarding table and ntop statistics.
Finally, if you decide that this is something that shouldn't be implemented, than may be you just will do automatic setting of limits to minimum values on hitting the "disconnect" button (with automatic restore on "connect" of course).
-
Kry has a point here (tautology or not).
Finally, if you decide that this is something that shouldn't be implemented, than may be you just will do automatic setting of limits to minimum values on hitting the "disconnect" button (with automatic restore on "connect" of course).
You can accomplish that yourself by calling amulegui from a batch sandwiched between two calls to amulecmd setting the bandwidth limits to whatever you like. (Not below 1k/s however.)
Oh, and P2P apps are not exactly what I'd give innocent mothers to play with... :-\
-
You can accomplish that yourself by calling amulegui from a batch sandwiched between two calls to amulecmd setting the bandwidth limits to whatever you like. (Not below 1k/s however.)
No, i can't. I don't want to disconnect/reset limits every time amuleGUI is disconnected. I want to make "almost shut down"-state easier accessible.
-
(moved this to feature requests where it belongs)
OK, I misunderstood you. Hm. So you don't want the sleeping period related to activity of amulegui. But you still can set it through amulecmd - same way you would trigger your "core inactivity" feature. SO I really don't see the point.
-
You remember the othher thread about the long shutdown? If you need your resources for an hour or so, it would be easier to just tell the core "go for breakfast, till I call you" instead of letting it all write to disk, just to read it all back an hour later.
-
just tell the core "go for breakfast, till I call you
Isn't that exactly what capping the rates to 1k/s does?
-
1 > 0 isn't it. Plus overhead.
-
OK. Not exactly of course, but for all practical purpose.
And I'd rather get to the source of the problem of the long shutdown than make a messy workaround.
-
actually even 1/1 is good enough if there was an easy option of reducing/restoring speed if not in one, then at least in two-three clicks. For now the only way is to call an option window and type the needed values by hand both for reducing and restoring. For instance toggable tray icon context menu item "reduce to minimum", that can be switched on and off.
-
I've been thinking about an option to toogle bw-limit on/off some time ago. Maybe this would be a solution. Setting limits to 1/1 (or whatever else someone wants), and then just a button switching between fullspeed and limited. Maybe in addition something like "amulecmd -c toogle bw-limit on"
-
If you are using amulecmd anyway you can already do it, so I don't see an advantage.
-
I thought about an gui option, and as it makes sense to include it in remotegui and web, too, there'll be an handler in the ec-code anyways, so it's just logical to make in useable in cmd, too.
-
So you need settings dialog for "alternate" up/down speed, and a "convenient" place in the gui to toggle them.
I'd say this clutters up the interface and increases the risk of misbehavior due to erroneous configuration. I'm against that.
-
No alternative. The settings as they are, and somewhere on the downloads page, or beside the connections globe say on or off. It's just a switch deciding if the usual bw-limits are applied or ignored.
-
This is wrong in many ways.
- Whenever somebody whines "aMule is not downloading!!!" we will have to ask "did you accidentally click on that 'off'-thingy in the status line?". I don't need that, thank you.
- People will still queue up at you. Since the number of sources they ask is limited, their chance of downloading (and then sharing) is diminished with a dud source like you. So it hurts the network.
- You clutter up other Kad nodes publishing files you don't actually share.
Kry already told once that he "doesnt see the point of making the option 'not to down-/up- load' for the app the sole purpose of which is down-/-up load"
This sums it up pretty well.
Shut down your core when you don't want it to be active, and be done with it.
-
Now you got me wrong.
- Whenever somebody whines "aMule is not downloading!!!" we will have to ask "did you accidentally click on that 'off'-thingy in the status line?". I don't need that, thank you.
This would only apply if he already enterred limits into the boxes that are already there. Do you ask todays, if he enabled bw-limit? If yes: nothing changes, if no: Why should you start?.
- People will still queue up at you. Since the number of sources they ask is limited, their chance of downloading (and then sharing) is diminished with a dud source like you. So it hurts the network.
Nope, or better only if current bw-limit has the same effect. In that case this has to be removed.
Maybed you overlooked it, but I'm only talking about a shortcut to the existing options. Instead of going to preferences, set the bw-limit you want, clicking apply, do what you need it for, go again to preferences, set bw-limit to 0/0 (unlimited), clicking apply, and do the same the next time you need it again, you would have just have to click bw-limit on, do what you need it for, and click bw-limit off. Not more or less I'm talking about.
But if I would talk about shutting down the core, I would shutdown all connections. I don't know if you use ICQ, but if you click on disconnect in any of these apps, you won't have any network activity at all. That's how I understand this op here. If all network connections are closed, I don't publish any nodes, I don't collect clients on the queue, I'm just not there.
-
Stu, you just becoming stubborn. Moreover, you became self-contradictous: when you are asked about the option of temporary-shutdown, you are telling "use 1/1-limits", when you are asked about option to toggle to 1/1-limits, you tell "use shutdown".
I can't use shutdown - it requires ssh access and root privileges. Using limits is messy too - it requires digging up in preferences. And for christsake, please stop telling me about amulecmd. Who uses it anyway? Some console geeks with boxes without X?
-
Maybed you overlooked it, but I'm only talking about a shortcut to the existing options.
What I'm trying to tell you is, I'm regarding fiddling the bandwidth options to create inactivity as a bad thing to do, and I don't want to encourage it with an easy-to-use gui option.
Stu, you just becoming stubborn.
Nice pun. :) (Bad attempt at trying to convince somebody to do something for you though.)
Moreover, you became self-contradictous: when you are asked about the option of temporary-shutdown, you are telling "use 1/1-limits", when you are asked about option to toggle to 1/1-limits, you tell "use shutdown".
Well, 1/1-limits is a possible solution, but I explained in my last post why it's not a good idea and shutting down is better. That's not "self-contradicting".
I can't use shutdown - it requires ssh access and root privileges.
Your faulty setup if you run amuled as root. Run it as a user and set up a remote shell script to start it and shut it down (you can use amulecmd for the latter), and you can do it by clicking on an icon on your desktop.
stop telling me about amulecmd. Who uses it anyway? Some console geeks with boxes without X?
Everybody who wants to automate something.
-
And for christsake, please stop telling me about amulecmd. Who uses it anyway
Me.
What I'm trying to tell you is, I'm regarding fiddling the bandwidth options to create inactivity as a bad thing to do, and I don't want to encourage it with an easy-to-use gui option.
Limiting can't cause inactivity. As stated before: 0<1. But beside that, limiting is usefull for let's say people that leave amule running for days, but want to check something on the web in between. Shutting down and restarting it again can take longer in some ways, than the action that's planned. If bw-limits are harmfull to the net, they have to be removed. If they are not, but shouldn't be used, they have to be removed, too. Hiding options deep in the config isn't a solution. And even if I would limit my bw to 1/1, my mule still answers for i.e. searches, so some peer of my limited donkey get's told about another of my peers to find the missing parts. If I shutdown the whole app (or disconnect in my understanding of disconnect), this peer wouldn't get any part frokm me, and maybe get told about the other peer later, maybe to late. So if I have a simple to use option to limit my bw-usage, I have a benefit over shutting down the app, and this can be considerred useful to the net.
This about the limit. About the disconnect button: If I shutdown the app for some task, any traffic will be stopped, right. What if let's say after the disconect click, finish (not stoping) all active uploading, but stop downloading and stop answering any requests except related to a running upload. For all wating clients it'll look like we shutted down the client, so no harm to the net. As we don't download any bit: no leech. And as we don't abort the upload, the peer get's his part he wouldn't get completed if we would really shutdown. This is a benefit for the net.
So why do you think it's a bad idea. In older threads I always had the feeling Kry doesn't really read the posts, points and suggestions. Is that now your part? All I' read in points to not implement was "Kry told...." and "There are alternatives". No really point.
I remember I talked to someone (Kry or Gono, can't remember) about exactly that feature, and he told me that he had the same idea some time ago, and just a lack of time prevented it from being implemented. He encouraged me to do it, but I had some timing problems, too.
-
So why do you think it's a bad idea. In older threads I always had the feeling Kry doesn't really read the posts, points and suggestions. Is that now your part? All I' read in points to not implement was "Kry told...." and "There are alternatives". No really point.
Hey, fuck you too.
-
Hey, fuck you too.
Good to see you're in a happy mood again. :D
In older threads I always had the feeling Kry doesn't really read the posts, points and suggestions. Is that now your part?
I'm totally innocent, it's just Kry's bad influence as you observed correctly. :P
You can set speeds with a click from the tray icon. IIRC the speeds there available for selection are hardwired. Would it help if we made them configurable? We could even allow pairs of speeds (up+down) to be set from there.
I accept throttling upload speed to do some other things on your computer and put it up to mac during inactivity as a valid usecase. If you want it all inactive for a longer time you better shut it down however.
-
The last time I used the tray icon, I was really pissed. I limited upload, and download got instandly limited, too. Correct behaviour, but the other way it didn't work. As I've finished, I set down to unlimited, but instead of raising upload, too, I've been ignored. So for limiting we already have pairs.
If we make it configurable, it's almost the same as the limit-on/off button, it's just not reachable for guys like me, that don't use the icon. For me, I try implement most functionality into plasnamule, but bw-limits is only reachable over EC from there, and EC will not be implemented before lib-ec is a real lib, which I won't send in before the 2.3.
@Kry: I love you, too. Have a lovely new year.
-
I wouldn't call that "pairs". It's just the usual settings check, which reduces dl bandwidth according to ul bandwidth to prevent leeching.
What I would make is configurable real pairs, like
[TRAYICON_SPEEDSETTINGS]
Max:U50D100
Limit:U10D20
And if you want that feature and we decide to implement it through the tray icon, you can start using it, or keep living without it. :)
-
It would have been easier, if it just recognizes: "Oh, he has increased download, I'll aadjust upload accordingly" instead of ignoring me. But if this will be implemented, a shortcut to this in the gui shouldn't be that hard and would be preferred by me, as there are some problems with ther tray icon reported. I didn't follow these threads, but an alternative to the icon wouldn't be that bad.
Anyways I'll rely on the lib and plasma.
-
Most file-sharing applications which implement bandwidth limiting have a (usually one-click) option to turn limiting on/off.