aMule Forum
English => Feature requests => Topic started by: nikio on October 06, 2008, 10:53:26 AM
-
It often happens that during download some sources disappear in the middle of a chunk download. Same thing happens to my uploads when I shut down, I guess.
This is particularly annoying for files with scarse sources.
I'd like a "Polite" Shutdown Button, that would ask amule
1) don't accept any further uploads
2)finish upoloading the chunks that are currently uploading
3)close amule
possibly: 4) shutdown the computer
Please forgive my strange english, I've tryed to make it as clear as I could.
-
like the idea of that, but I'm guessing its going to be very low priority for the devs, because its a desirable not an essential feature request.
-
Well, the only difference between normal shutdown and "soft" is
2)finish upoloading the chunks that are currently uploading
.
What's an idea here?
-
Well, the only difference between normal shutdown and "soft" is 2)finish upoloading the chunks that are currently uploading
.
What's an idea here?
In case it is a rare chunk, at least someone got it, before you go, instead of leaving and let someone left with missing 16kb of the chunk where he have to stand 3 days in line the next time I'm back.
-
Well, you suggest I leave it on 15 min longer, finish some uploads but accept no more. If instead I leave it running at full for these 15 min, I could upload more in this time, maybe even finish someones gap in another rare chunk that in "soft shutdown mode" would have been rejected. So I think your logic is flawed. ;)
-
Well, you suggest I leave it on 15 min longer, finish some uploads but accept no more. If instead I leave it running at full for these 15 min, I could upload more in this time, maybe even finish someones gap in another rare chunk that in "soft shutdown mode" would have been rejected. So I think your logic is flawed. ;)
I think you make a small mistake there.
If I'm currenctly uploading to 100 different source and one is a rare chunk, than uploading 15 minutes more might result that you still haven't uploaded the full rare chunk, while stopping to accept new uploads and finishing only the chunks that are still uploading might result in 8 minutes more time and than everybody will get the full chunk.
But of course you upload more if you have it running longer and no one would like to wait 8 minutes when he is stoping aMule.
Beside the fact that there might be someone that allow only to download with 0.1kb - that would take hours till this chunk is finished.
All together I find this a nice idea, but I prefer to leave my aMule runing 24/7. :p
-
This "feature" will have no effect whatsoever. Author for some reason think that the moment he decided to click on "X" is somehow special. It is not. It doesn't matter if you close amule now or X minutes later.
-
Nice idea but I doubt they will add anything as most leecher may find this effective and finish downloading and then shutdown when source exchange begins as chunk is published in network.
But you can use the alternative just disconnect from the network it can be KAD or eD2k and you won't get new uploads then when upload is complete shutdown aMule. While you are disconnected it is possible to share still.
-
i think i get the author's idea.
it is to check before shutdown if there is some uploaders that "almost got" some chunk (say >90%, or <0,5 mb left), to close all other connections, to give all bandwidth to these, finish them, and to finally shutdown.
this would be helpful for those with hypertrophied conscience who takes every shutdown as a crime. this feature will lighten their guilt.
the simpler way to do it is to pop-up a text "it's okay to disconnect at will" every amule's start. may be such a therapy would be even more effective.
-
this would be helpful for those with hypertrophied conscience who takes every shutdown as a crime. this feature will lighten their guilt.
This is not a technical problem, you know.
the simpler way to do it is to pop-up a text ... every amule's start
extremely annoying way.
may be such a therapy
a therapy? amule deal with files, bytes, sockets, networks etc. Not with conscience or guilt or therapy.
-
that was a joke
smile
-
Facepalm, lfroen
-
Yea, one may never know ...
-
Sorry for my long absence!
And thank you all for the interest, I'd like to give some clarifications, I've relly made an effort to make my english and my thought understandable and (hopefully) clear.
Well, the only difference between normal shutdown and "soft" is 2)finish upoloading the chunks that are currently uploading
.
Actually I think that the possibility to shut down the computer too makes the difference...
when I have to go away and shut down the computer, I'd rather use a soft shutdown.
Well, you suggest I leave it on 15 min longer, finish some uploads but accept no more. If instead I leave it running at full for these 15 min, I could upload more in this time, maybe even finish someones gap in another rare chunk that in "soft shutdown mode" would have been rejected. So I think your logic is flawed. ;)
well, not accepting new downloads would concentrate the band on the remainders, but wont reduce it, so the bytes uploaded in those 15min would be the same "volume" but entirely dedicated to chunk completion. (AFAIK uncomplete chunks are not shared)
[...]
Beside the fact that there might be someone that allow only to download with 0.1kb - that would take hours till this chunk is finished.
I have never seen a stable connection that slow... but I see it's not impossible, I suppose that a time limit is the only way to handle slow downloaders
All together I find this a nice idea, but I prefer to leave my aMule runing 24/7. :p
Two times thankyou!!
Nice idea but I doubt they will add anything as most leecher may find this effective and finish downloading and then shutdown when source exchange begins as chunk is published in network.
I'm not sure that I've understood, all the point is about completing uploads before shutting down, not downloads...
But you can use the alternative just disconnect from the network it can be KAD or eD2k and you won't get new uploads then when upload is complete shutdown aMule. While you are disconnected it is possible to share still.
I've tried, this wont limit the downloads to the currently uploading chunks: after those the uploads continue, maybe until entire files are completed, I don't know.
Maybe a way to do it would be to rise the band per client to all the available band, and then shut down when the last client has finished with his chunck, but this would imply my presence, and of course I don't want that.
i think i get the author's idea.
it is to check before shutdown if there is some uploaders that "almost got" some chunk (say >90%, or <0,5 mb left), to close all other connections, to give all bandwidth to these, finish them, and to finally shutdown.
Actually my idea is (possibly) to complete all the uploading chunks, I don't think that spreading around the net loads of incomplete chunks is "healthy" for the net
this would be helpful for those with hypertrophied conscience who takes every shutdown as a crime. this feature will lighten their guilt.
the simpler way to do it is to pop-up a text "it's okay to disconnect at will" every amule's start. may be such a therapy would be even more effective.
My hypertrophic conscience is double faced... I'd like if YOU all used a "soft" shutdown ;D
More seriously I think that we all would benefit from this modification, if many of us used it.
-
Your idea (finish chunk before shutdown) makes no sense. Please please please take your time to understand following concept.
Case A - commonly available file.
Assumption #1 - file have many chunks.
Assumption #2 - there are many sources for given chunk.
Assumption #3 - average client-is-online time T >> t, where t is average time for one chunk under present conditions.
Given assumption #3 most of chunks are finished on schedule.
Given assumption #1 it doesn't matter if particular chunk <i> become corrupted (or unfinished), since it have little impact on overall completion time.
Now, considering #2 we see that there's no problem to replace dropped client.
Conclusion - no impact for any given client.
Case B - rare file (#2 doesn't hold)
Property #1 (file is rare) - there are many clients in queue
For rare files situation is different since dropped client will increase time in queue for . But, due to #1 it doesn't matter whether one of many waiting clients got the chunk - on average everyone is screwed.
Conclusion - no impact in average.
-
Your idea (finish chunk before shutdown) makes no sense. Please please please take your time to understand following concept.
Case A - commonly available file.
[...]
Conclusion - no impact for any given client.
no objecton - if a file is widely available, there's no real need concentrate on details...
Case B - rare file (#2 doesn't hold)
Property #1 (file is rare) - there are many clients in queue
For rare files situation is different since dropped client will increase time in queue for .
i'm confused, could you explain a little more the queue point?
But, due to #1 it doesn't matter whether one of many waiting clients got the chunk - on average everyone is screwed.
well if one or two of the clients got the full chunk they can continue spreading it until I'm back online
But, most important, both case A and B lay on the assumption #3 T>>t, there is a not irrelevant percentage of people that use file sharing programs (T) only one or two hours a day, not more tha four hours anyway, considering an average "t" about 30-40 minutes (that is absolutely sensible in Italy and, I think, in Europe), you can easily see that the impact is not irrelevant in these cases
-
But, most important, both case A and B lay on the assumption #3 T>>t, there is a not irrelevant percentage of people that use file sharing programs (T) only one or two hours a day, not more tha four hours anyway, considering an average "t" about 30-40 minutes (that is absolutely sensible in Italy and, I think, in Europe), you can easily see that the impact is not irrelevant in these cases
Read again:
average client-is-online time T
Not a "percentage of people ", which can't be compared with "t" in T >> t.
All P2P ideas based on fact that T >> t, since in opposite case clients will not be able to complete exchange of chunk (takes time t) before they go offline (T expired).
Rest of your post is meaningless. Do the math. Use right units on right variables.
-
lfroen has one irrefutable argument on his side: ed2k works! so it would be silly to prove that it couldn't work without this feature - it's working already.
besides, talking about averages: amule is very rare (no offense, this is the fact), so any feature like this (even if it would be VERY useful) will cause no impact on net at all.
-
Especially since nobody would use it. :P
-
lfroen has one irrefutable argument on his side: ed2k works
I guess math doesn't count as "argument"? Get a clue, it's free.