mldonkey-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mldonkey-users] rewritten upload in edonkey.


From: Goswin Brederlow
Subject: Re: [Mldonkey-users] rewritten upload in edonkey.
Date: 17 Oct 2002 18:45:55 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)

MLdonkey <address@hidden> writes:

> >  can you describe your rewritten upload a little bit more? 
> >  
> >  - fix: rewritten upload in edonkey. Old mode can be restaured with option 
> >  'new_upload_system' set to false
> 
> Previously, mldonkey used to send every second upload messages to
> edonkey clients for max_hard_upload_rate kB. Moreover, everything was
> rounded to kB, and not bytes. Then, the bandwidth management would
> only really send on the network max_hard_upload_rate kB, including
> other control messages.
> 
> Now, every byte is counted. Moreover, mldonkey will send only for
> (max_hard_upload_rate-1) kB, giving at least 1kB for control messages
> (I need to prevent setting max_hard_upload_rate to 1...).
> Moreover, messages are sent 10% per 1/10 second, not all at the same time.
> 
> There are still two new bugs that I have to fix as soon as possible:
> prevent sending more than the authorized rate in 1 second (this can
> happen if all the bandwidth is sent in the last 1/10 second of one
> second, and the bandwidth for the next second is sent in the first
> 1/10 second), and another bug that make remove new untested sources
> instead of old bad sources when new sources are added...
> 
> I will do that tonight.

At the moment (not quite that current cvs) you reset the remaining
bandwith to the allowedbandwith once a second.

You should add 1/10 of the allowed bandwith every 1/10 of a second
toping the bandwith of at the amount allowed per second (or 2/10 of
that or something to prevent to big spikes without disalowing all
spikes). That way the overall bandwith will average out at the wanted
value. But some spiking is allowed and overuse, for example because
some important control messages just had to be send anyway, will
burden the next timeslice instead of being forgotten.

What would also be an improvement would be a type_of_service flag
acompaning the actual data.

The type would be the priority of data and indicate data thats send
out of the niceness of our heart. For example sending out sources to
other clients is a realy nice thing to do but completly not vital. If
the bandwith is saturated and the buffers of sockets fill up those
messages can be savely forgotten. Requests for blocks on the other
hand are vital and should be send first and so on.

MfG
        Goswin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]