Re: [Mldonkey-users] mldonkey agressiveness (resend)

[Goswin Brederlow]

Pierre Etchemaite <address@hidden> writes:

> Le 07 Jan 2003 16:00:10 +0100, Peter Schuller <address@hidden>
> a écrit :
> 
> > Firstly, is mldonkey supposed to be in a "connected" state to sources
> > for extended periods of time? I was under the impression that it would
> > connect, get queued, and then disconnect. In my client I see a *lot* of
> > sources in the "connected" state.
> 
> It doesn't look like mldonkey tries to quickly close connections (certainly
> because closing/reopening connection has a high cost, and Unixen usually
> don't have problems with many connections open at once ?). Instead, after
> asking for a slot, if it doesn't get a response, it waits queued_timeout
> seconds and disconnect, or restart dialog with the other peer after
> min_reask_delay (or more), or get disconnected by the other peer, whichever
> come first.

Ok, consider the following: 2 mldonkey clients, both clients want the
same file and have the same blocks. Nothing to do here.

Do the clients stay conected forever aksing each other for that one
file every min_reask_delay seconds?

Clients that don't have anything intresting should get disconnected
and not retried for a long time. Let them catch up. They will probably
end up connecting to us from time to time anyway to get our blocks.

> > I'm consistently
> > uploading more than I'm downloading (I always do). Yet mldonkey refuses
> > to become more "agressive". 
> 
> If you ask faster than the ban delay implemented in many peers, you get
> banned. There's no (lawful) way to ask faster than once every 10 mins.
> 
> > Even on files with an absolute minimum of availability (only valid
> > source seemingly), mldonkey lingers in "connected" states and doesn't
> > connect to other un-used sources.
> 
> Check in /proc/$mldonkey_pid$/fd how many file descriptors are in use. If
> you don't run out of file descriptors, I don't think what you're seeing is
> caused by too many connections left open.
> 
> That doesn't mean there's no problem.

I run out of FDs the other day. It failed to connect new clients for a
few seconds before enough connects had a timeout.

My max_clients_per_second * timeout was probably more than the number
of FDs mldonkey could get.



As I see it the aggressivenes of mldonkey can be changed easily by
changing max_clients_per_second. That does not affect the normaly
retry delays each source has anyway so it shouldn't get you banned.
But if the max_clients_per_second is too low new sources will never be
tested and you will try the same old not working sources again and
again.

MfG
        Goswin