RE: [Mldonkey-users] Sharing for rare files....suggestion

[João Correia]

Hello all

        Let me try and defend my idea.

        Why I prefer mldonkey controlling the rare_file_threshold? Bias.
Human
options are biased. You may think the file is rare, but guess what?,
another
300 users out there have the same Uncle_Sam_In_The_Wild.avi shared.
        But not just for that. Imagine a file is well spread. Suddenly
two or 
three of the mammoth servers go down. The file goes from 400+ sources to
10
or 20 sources. An automatic control would notice this and prioritize
this 
file over others.

        I agree my suggestion has more "bandwith overhead" than yours,
but its
just a matter of checking for available sources every now and then.
(Doesn’t need to be anything like the files you are downloading. Maybe
once or twice per hour I think would do it - maybe an option?)

        Still, the rare_file_threshold would be an option. You would
still have "some" control over it. Although I must insist that any such
system
mainly controlled by us and not the mldonkey program are less than
optimal.
Please don't understand this as a machines-are-better-than-us thing, its
just that the program would be faster to analyze and maintain and adapt
to 
source number changes in the network.

        By stopping the sharing, I was just merely suggesting an
alternative to prioritization. I admit stopping shares when they are too
spread is a bad
idea. They should just have fewer upload slots available.

        My two cents,
        Thank you for your time,
        Joao Correia



-----Mensagem original-----
De: address@hidden
[mailto:address@hidden Em nome de
Marc
Enviada: quarta-feira, 18 de Dezembro de 2002 9:34
Para: address@hidden
Assunto: Re: [Mldonkey-users] Sharing for rare files....suggestion

yup the idea is nice.
although i agree with Martin that removing other files from being shared
is
quite dangerous..

as i said in my sharing priority post, a manual priority setting for
shared
files, already makes a great difference.. i tested it on an emule client
a
few days ago and it works perfect...

what could be done with your Rare_file_threshold is that mldonkey
modifies
the priority of the files on its own..

but that would only be fair if each client had an accurate idea of the
network status for each file at any time..
When downloading files the client keeps asking for more source to
download
from and thereby knows the popularity of files but what happens when the
file is downloaded ? does it keep asking the network how many sources
are
available or can it only count the number of requests each file gets ?

anyway the requests counts could be usefull as well..
a ratio could be set using the requests counts of each file like this..

file 1 gets 500 requests per hour (16%)
file 2 gets 100 requests per hour (4%)
file 3 gets 2500 requests per hour (80%)

with a 20% level threshold (level 1 <20%, level2 <40% and so on), after
one
hour
file 1 and file 2 would get priority level 1
file 3, priority level 4

using a slot ratio
file 1 & file 2 would get the same number of slots and file 3 would get
4
times less slots than 1 & 2

unfortunaltely that kind of statistics is greatly altered by the clients
behaviours as shown below with my current client_stats..

Total seens:               8259
                    eDonkey:               1961 (23.74 %)
               old mldonkey:                406 (4.92 %)
               new mldonkey:                288 (3.49 %)
                    Overnet:                 11 (0.13 %)
                  old eMule:                  0 (0.00 %)
                  new eMule:               5593 (67.72 %)
                     server:                  0 (0.00 %)

Total filerequests received:             174101
                    eDonkey:               3958 (2.27 %)
               old mldonkey:              78885 (45.31 %)
               new mldonkey:               9020 (5.18 %)
                    Overnet:                 37 (0.02 %)
                  old eMule:                  0 (0.00 %)
                  new eMule:              82201 (47.21 %)
                     server:                  0 (0.00 %)

5 % of the mld clients send 45% of the requests.. so another ratio
should be
applied to have a fair figure of the actual number of clients requesting
a
file...

this short on the fly analysis conforts me in the idea that a manual
priority setting for shared files is not such a bad idea and would be
much
more easier to implement :)

Marc