[Quezl]

I've been bothered by this for a long time now...

I have to shutdown eMule but there are still downloads going on of quite rare files. But I'm not that in a hurry, that closing eMule instantly is overly important.

So I thought that a delayed shutdown would be nice: eMule won't start any new downloads but it will finish any running downloads and uploads, so that I and the people connected to me can finish all pending chunks.

[Vahagn]

[cafebean]

Quote

eMule won't start any new downloads but it will finish any running downloads and uploads

Please explain. Won't there be always people in queue, and aren't shot down when downloads finish the #1 enemy of file sharers? Or just no new connection will be made, which means wasting some bandwidth?

And why turning off at all if you don't have to or don't have to yet?

[Quezl]

The idea is to let all chunks be completed (both directions) while not starting any new transfers (both directions) in order to minimize the amount of unfinished chunks left in your temporary downloads and in those of the people who were downloading from you at the time you decided to close eMule.

Think of it as a soft eMule shutdown, whereas the current exit is a hard eMule shutdown.

Again, the only goal is minimize the amount of failed transfers or unfinished chunks because of exiting eMule at the cost that it will take a few minutes until eMule actually closes (depending on your and the peers bandwidth).

[tHeWiZaRdOfDoS]

This already existed as "Smooth exit" in some mods... wait for the current up- and downloads to finish prior to exiting.

[Quezl]

Existed?

[CiccioBastardo]

However , it is a waste of bandwidth.

[Andu]

How is a smooth shutdown a "waste of bandwidth"? Or are you talking about the unfinished chunk being a waste of bandwidth?

[CiccioBastardo]

Quote

The idea is to let all chunks be completed (both directions) while not starting any new transfers (both directions) in order to minimize the amount of unfinished chunks left

My english is far from being perfect, but to me the statement above means that you "smoothly" stop uploading to new requests in order to avoid creating unfinished chunks. For the time your upload bandwidth is not fully used, you waste bandwidth. Wasting bandwidth is far worse than creating unfinished chunks on the network.
It is surely better to truncate all communications at the exact time you want to close your client than "smoothly" make it run out of upload requests wasting bandwidth.

I can clearly remember this argument has been discussed many time in the past.

[coluche]

For "friendly shutdown" on uploading chunks, would not the mule see it as if noone was in queue and thus dedicate all available upload to the remaining remote clients. -< no bandwidth wasted.

But with the original FR I understood it was about "finish DL chunks". That could take up to 50 minutes, with not accepting any more requests/ not putting anyone in upload slots, a whole lot of bandwidth can be wasted. (unsure)

[zz]

Better to use full bandwidth up to the very point you shut it down, than letting it taper down slowly. That just leaves unused bandwidth while still using the computer resource. I see no gain in that.

Sure, you may cut someone off in the middle off the chunk, but if you taper bw down slowly, someone else wouldn't even get to start a chunk. Which is a net loss in the end.

/zz

[EvolutionCrazy]

instead would be interesting waiting for a DOWNLOAD chunk, and keep uploading as usual

[cafebean]

What is the point of downloading a complete chunk, if you aren't going to upload it by shutting down?

[Andu]

You gain the waiting time it would take to finish the chunk when the client is fired up again.

[DeeEmmSee]

Sure, preventing new upload connections would go against eMule values by limiting the amount of sharing, so don't allow prevention of upload conn's. And sure, limiting new download connections might waste bandwidth but it's his bandwidth, so why not let him waste it? For all we know he could be using excess bandwidth for something else. I think his original point, though, was that he doesn't want to clog his machine with partially completed downloads, nor does he want to distribute bandwidth over many downloads that are unlikely to complete before he shuts down and would rather concentrate on finishing what he has started (especially if what has started is difficult to find). Some of us don't get the chance to connect every day, so would rather a complete 1 usable file than 1000 5-percent completed ones, even if it means a loss of efficiency overall.

This post has been edited by DeeEmmSee: 07 August 2007 - 02:53 PM

[CiccioBastardo]

Andu, on Aug 7 2007, 12:29 AM, said:

You gain the waiting time it would take to finish the chunk when the client is fired up again.

That is only an issue when downloading from mods that stop uploading at chunk completition

[Gowenna]

cafebean, on Aug 7 2007, 12:04 AM, said:

What is the point of downloading a complete chunk, if you aren't going to upload it by shutting down?

Hmm, everybody is thinking about downloading. How about the opposite direction, uploading a complete chunk before the shut down? ;)

[Famerlor]

Already discussed, gowenna, see above.

[Andu]

CiccioBastardo, on Aug 7 2007, 08:46 PM, said:

Andu, on Aug 7 2007, 12:29 AM, said:

You gain the waiting time it would take to finish the chunk when the client is fired up again.

That is only an issue when downloading from mods that stop uploading at chunk completition

How so? If you download half a chunk you still only have half a chunk. If you quit eMule you'll have half a chunk. If you start up eMule the next day you will have to wait in the queues of the peers until you get the other half of the chunk. Ergo you can't share it for all the time that you are waiting.
If you'd finish the chunk the day before you could share it right from the moment you fire the client up. If the remote client uploads till chunk barrier or beyond it unimportant in this context.

[CiccioBastardo]

Didn't get you there. I hope this is going to have any meaning, though I doubt it...

You obviously can share a chunk only when complete. If you manage to download half a chunk it means you will probably be able to complete it faster the next connection. This includes downloads from clients that do not upload full chunks (so you may need less upload slots to finish it) or those that do (so you will have a new half chunk ready to be finished soon restarting the game).

I can understand what is your aim. Having as less unfinished chunks spread as possible (thus increasing the number of finished chunks available for upload). However, the above behaviour is both unfair (I may have been waiting for a complete day just to get the latest 100KB to finish off the chunk) and still makes the download of the next new chunk slower (you have to wait from the start to get 9.28MB in the hope a full chunk is gained, or you have to wait in more than a single queue to get the chunk).

The general idea is that it takes time to get a chunk. The more you'll get, from whichever source, standing or closing down, the earlier you'll complete it and can share it, even if in different sessions from different sources. The average is what is important. What I can get from you now is something less I have to ask to someone else later.

In the end, the described wanted behaviour is as close as possible to the behaviour of a mod with full SlotFocus enabled (all bandwidth to a single client). If you are ever going to suddenly stop it, you'll just create a single unfinished chunk. And no bandwidth is wasted at all.