Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[whatever]

Hi,

when I am downloading a file and have files in my incoming directory
often the files that I download are not uploaded. Instead files
in my incoming directory are uploaded.

Because I dont upload the files I download I get fewer DL slots from
the people that share those files. This results that I DL files slower.

What I do to solve this is to move all files in my incoming directory to an other
directory. After I moved the incoming files I get much faster downloads.

But I think this is BAD since I am sharing less. A much better behaviour IMHO would
be that the files you download should have priority in the upload queue.

Cheers,

T

[Kry]

But I think this is BAD since I am sharing less. A much better behaviour IMHO would
be that the files you download should have priority in the upload queue.

Well. Then the files with less priority (those not downloading) would dissapear from the network in some time. And ed2k network would lose it's best feature: persistence of files. And we'll end up with a gnutella-like network.

And we can't do that

[Jacobo221]

You can select the priority type in the Shared Files window anyway. So that's the tool you're looking for. Trying to get more preference than that is leeching ;-)
Greetings!

[whatever]

Actually with the system today the files disappear faster, in my case anyway. Since I move files
away from the incoming folder so that I get better DL rate. I might not have explained it
properly though, the algorithm would be like this.

Priority on which file to upload:
1. If I downloaded from somebody
2. People who want a file I download.
3. Other ppl that want to DL files.

I think 1. is already implemented and 2. is an improvement since more file
stays in the system.


I dont think this has anything todo with leeching. Leeching is when you want to
put an limit on what to upload but still want to have great dl rate. This just let people
that have the file you want get priority in your upload queue. So you still upload with
the same rate.

I dont mind sharing, but yesterday evening I started to download a file and got 1-2kb/s
during the night. I removed all the files in my incoming directory and then after 5 min I got
5-10kb/s. I think the system should encourage sharing, but as it works today it doesnt.


Cheers,

/T

[deltaHF]

well, every *mule uses a credit system, means:

you upload -> you get credits
you dl -> remote gets credits

now you have a file that you finished to dl and a lot of ppl got credits from u cos they let you dl. now they want to use the credits and are downloading from you.. no matter what file it is.
and if the clients on your current dl file doesn't have any credits yet, its normal that the one with credits will get faster in your queue..

just play a bit with the priority like jacobo said above and everything should be fine

greets

[whatever]

Sorry for the long time since replying.

now you have a file that you finished to dl and a lot of ppl got credits from u cos they let you dl. now they want to use the credits and are downloading from you.. no matter what file it is.
an...

If they have credit they would have priority and fall in category 1 in my suggestion. So it would not destroy the credit system.


And again I had to remove all files in my incoming directory to be able to get a download rate. Since I am never able to create credit from the ppl that have the file that I want.  

If I understand it how it works now the scheduling is:

1. Let ppl download that have credit.
2. Give the slot to the next in queue

So assume you have 100 file in you incoming directory and only want to dl one file. Then you will have many more ppl in in queue that you dont want to dl from than that you want to dl from. Because of that it will take much longer to get credit for the file you want.

This means you get PUNISHED to have many files in your incoming directory. This is bad, methinks.

So please implement my idea. There is no negative effects from it.

/T

[Jacobo221]

Well, that's a suggestion you should ask eMule team about, not aMule ;-)
If every client acted in a different way, ed2k would die because of misconception, incompatibilities and wrong-managements...
Post at eMule's forum and let's see how t all goes on
Greetings!

[whatever]

Ok I'll do that.

But I still think amule could implement it by themself since it is only a client side thing. And also it s doesnt destroy anything.

For example emule implemented the credit system before they were the default client for the *mule network.

Cheers,

T

[Jacobo221]

But eMule is the protocol-designer and network head-leader so, any change which may affect the protocol or the network in _any_ way must be agreed with them first. The ed2k network is a friendly network, if it became into Anarchy I don't think it would be alive too long (this last sentenca has no political background ;-)).
Greets!

[whatever]

The thread over at the emule forum http://forum.emule-project.net/index.php?showtopic=53307.

But eMule is the protocol-designer and network head-leader so, any change which may affect the protocol or the network in _any_ way must be agreed with them first.

I agree, but still think this is outside of the protocol. But yes it would affect the network. So how does the process work on implement new features regarding changes like this?

[Jacobo221]

eMule agrees, implements, and other clients follow. Strait forward ;-)
Let's see what they think...
Greets!