[DatHebIkWeer]

Some people will remove a file soon or a little while after they finished download. But a client will usually not remove a file he wants before that. So for continuity of the availability of a file it would be good if a large number of clients have parts available, as long as possible.

If available blocks are dispersed evenly and randomly over a number of clients (preferably every block on about the same number of clients), then continuity of the file would be most probable and chances of actually downloading all of it in the end would be highest for all.

I think a way to achieve this situation would be to favour upload to clients who have less of the file finished at the expense of clients who are near finishing it.

I am not really sure if this will increase or decrease the total time needed to get a file on eMule, but that may depend on the amount of bias you create.
Of course if you give absolute priority to starting downloaders the time to finish may be very long in some cases. But a good equilibrium that gives somebody who wants to finish it a sporting chance would be great.
The bias should not be so big that it will cause all downloads to finish at about the same time. That would be dangerous for continuity too.

How could this be done? I am not really sure what the possibilities of uploading clients are. If the uploader can assess the stage of the download on the requesters side there are several ways of doing this.
One way is manipulating the queue and putting newbie downloaders to the front and oldies to the back. I don’t like that option very much. I thought of something else.

What if you asses the requester when it’s his turn and then give the newbie’s a bigger quota? For instance if they have less than 20% of the file finished you give them 5 blocks, if they are past 20% but have less than 40 % you give them 4, less than 60 % you give them 3, less than 80%, 2 and if they are over 80% you give them only 1?

This post has been edited by DatHebIkWeer: 09 July 2012 - 02:47 PM

[Link64]

DatHebIkWeer, on 09 July 2012 - 04:37 PM, said:

I think a way to achieve this situation would be to favour upload to clients who have less of the file finished at the expense of clients who are near finishing it.

A client requesting a file could easily fake the amount of chunks he has completed, there are already clients, that hide chunks of complete files, so others can't request and download them.

I'm also not sure, if the clients send a list of completed chunks on each request or only when we start uploading to them.

It would also be quite unfair, everyone should have the same chance to make it thru the queue and get his chunk. Of course, if someone has uploaded something to me, a little payback isn't wrong (credit system), that should motivate others to upload as much as possible.

[DatHebIkWeer]

Link64, on 09 July 2012 - 04:27 PM, said:

A client requesting a file could easily fake the amount of chunks he has completed, there are already clients, that hide chunks of complete files, so others can't request and download them.

I'm also not sure, if the clients send a list of completed chunks on each request or only when we start uploading to them.

That would be a flaw in the system and if you cann’t work around that a reason not to do this.

Link64, on 09 July 2012 - 04:27 PM, said:

It would also be quite unfair, everyone should have the same chance to make it thru the queue and get his chunk.

That is exactly why I wouldn't want to mess with queue in this matter.
Before you can have a lot of chunks you have gone through a stage where you had not that many. So the disadvantage goes to the people who in an earlier stage had a benefit from it. I wouldn't be sure if the total pass through time of getting a file would actually increase in this way. Because the extra time people have to wait for their last chunks may be offset by the time they gained while getting their first chunks. It would increase the amount of data stored on the disk at any given point in the process though.

Link64, on 09 July 2012 - 04:27 PM, said:

Of course, if someone has uploaded something to me, a little payback isn't wrong (credit system), that should motivate others to upload as much as possible.

The quota system I propose is only a simplified suggestion. You can let it interact with the credit system, favouring the person who would be generous with his first chunks.
We work with computers here so a complex system of quotation calculation would not be a problem at all I would say. Why not favour people with high credit with some extra quota, AND favour people with less of the file downloaded?

This post has been edited by DatHebIkWeer: 09 July 2012 - 05:31 PM

[Link64]

DatHebIkWeer, on 09 July 2012 - 07:22 PM, said:

Link64, on 09 July 2012 - 04:27 PM, said:

A client requesting a file could easily fake the amount of chunks he has completed, there are already clients, that hide chunks of complete files, so others can't request and download them.

I'm also not sure, if the clients send a list of completed chunks on each request or only when we start uploading to them.

That would be a flaw in the system and if you cann’t work around that a reason not to do this.

You simply can't be sure, that the information send by another client is correct, the clients fakeing the chunk availability poove that. Also in case of a "good" client we see just the complete chunks and not what percentage of a file the client actually has.

DatHebIkWeer, on 09 July 2012 - 07:22 PM, said:

Before you can have a lot of chunks you have gone through a stage where you had not that many. So the disadvantage goes to the people who in an earlier stage had a benefit from it. I wouldn't be sure if the total pass through time of getting a file would actually increase in this way. Because the extra time people have to wait for their last chunks may be offset by the time they gained while getting their first chunks. It would increase the amount of data stored on the disk at any given point in the process though.

I doubt, that it would change anything (while opening a big opportunity for cheating). The amount of data stored on the clients does not increase their upload capabilities. Maybe in case of a client with just few files and high upload bandwidth it might change something simply by preventing him from sitting idle because everyone else already has the chunks he has. But in case of an avarage client with 100+ clients in his queue?

[coluche]

Hello and welcome, Dathebikweer!

What Link64 said.

Quote

Some people will remove a file soon or a little while after they finished download. But a client will usually not remove a file he wants before that. So for continuity of the availability of a file it would be good if a large number of clients have parts available, as long as possible.

Yup.
For popular files with a good source situation, all is well imo. - no changes needed.

But I am sharing mostly (groups of) files with low to very low number of sources, or even me (at least temporarily) being the only complete source. For these files there is say one or two new downloaders per week.

In the end I went for the "solution" to slow down my uploads* for these files, imo. this has two effects :
- I give downloaders more chance to force downloaders to exchange more parts among each other, so i do not upload all of it to downloader 1 (who then may un-share), then to downloader2, and so on.
me being the only source, reducing my upload for a group of files to say 50%, the downloaders still get the files maybe 25% later. (numbers made up, just to illustrate)
- from observing myself : a file that took longer to download is less likely to be un-shared soon than a file that finished in no-time. It kind of gains "worthiness" by having downloaded so slowly, resp. I feel more sympathy for fellow downloaders.

* for slowing down uploads, either :
- use upload priorities
- share more files
- share some/ more very popular files (e.g. I do have more UL capacity than harddisk-space)
- have more active downloads

Personally I use a mod of eMule that offers more UL-priority levels than the official eMule. Actually that is one of the main reasons I stay with that outdated Mod.

[DatHebIkWeer]

coluche, on 10 July 2012 - 12:54 PM, said:

I give downloaders more chance to force downloaders to exchange more parts among each other, so i do not upload all of it to downloader 1 (who then may un-share), then to downloader2, and so on.

Do you mean
I force downloaders to give downloaders more chance to exchange more parts among each other?

This post has been edited by DatHebIkWeer: 11 July 2012 - 12:11 PM