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

[Peter Schuller]

> 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.

Right, it's not a file descriptor problem or anything. I was just
thinking that perhaps mldonkey isn't connecting because its internal
limit of is reached due to a bunch of idle connections.

> 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.

Well, it's difficult to know without some extensive monitoring, but I am
getting the impression it just sits there doing basically nothing for a
*realllly* long time.

For example, at the moment there is a file with zero availability
according to the mldonkey gui. But there are over 800 sources listed for
that file. mldonkey is connected to one of them and only because I just
cliked "retry" a few times to get it to do *something*.

Could it be a matter of mldonkey retaining old out-of-date sources for
too long?

There is also another file, with just one block missing. There are over
1100 sources, mldonkey is connected to 65 of them but nothing is being
downloaded, and upon cursory examination I don't find anything in state
"queued", just "connected" (might be missing some though; it's a bit
much to scroll through manually).

It just seems a bit weird.

> 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.

No shortage of those. 426 at the moment for example. The limit it set to
1024.

-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <address@hidden>'
Key retrival: Send an E-Mail to address@hidden
E-Mail: address@hidden Web: http://www.scode.org