2

This behavior of eMule is almost idiotic, unless if there is a better reason -- the download speed was 200 kbytes/s, and the whole file is near finish.

But when it is about 10 seconds before finish, it dropped connections intentionally, one by one, except the slowest one, which is about 1kb/s.

Usually, the slowest connection is very unreliable -- it can degrade to 332 byte/s, or get disconnected completely.

The result: the last 3 seconds can now become another 20 minutes, or more. I don't know how the saving of "3 seconds" can benefit other people? But I do know the my 3 seconds becoming 20 minutes happens to everybody and it affects each person by a lot. Is there a way to solve this?

Improve this question
1
  • Yes, I have seen this far too many times. One thing to check is the Log tab of the Servers pane. See what it says; particularly check to see if eMule is hashing the completed file. It could be that one or more of the chunks are corrupt, so the file is not actually finished and eMule has to re-downloading them. This is common with anything that is copyrighted (or even believed to be copyrighted) because there are companies whose job it is to spread corrupt files, and they can often get overzealous.
    – Synetech
    Dec 27, 2012 at 1:49

1 Answer 1

Reset to default
2

This is because you're downloading the file in parts. A bunch of people all have the file you want, so you download from all of them at the same time. Then when you get done with a chunk you request the next chunk.

What's happening when you near the end of the download, let's say you have 5 chunks left, and you're downloading them all at the same time from different people. They complete one by one until only the slowest connection is left.

I can suggest if this bothers you to disconnect and reconnect and hope you request the chunk from someone faster. Otherwise, your P2P program is functioning as intended.

Improve this answer
2
  • you mean each chunk is only by 1 person? so the slowest chunk is there while the fastest chunk all got done and "they go away"... that looks like a possible reason, but shouldn't the program improve by switching the "fast" guy to help the "slowest guy"? (especially near the end)
    – the searcher
    Apr 17, 2011 at 23:37
  • Let's say that the file is broken up into 20 chunks and you're downloading them from 2 people. One with a connection speed at 200 kB/s and the other with 2 kB/s. You request a chunk from both of them. You start downloading both chunks at the same time. When you finish a chunk you request another chunk. What winds up happening is that 19 chunks are requested from the 200kB/s guy and only 1 from the 2kB/s guy. The program has no way of knowing if the 200kB/s guy is going to disconnect after 1 chunk or 20, and canceling the chunk from the slow guy just wastes his bandwidth.
    – OmnipotentEntity
    Apr 18, 2011 at 7:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .