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

[Goswin Brederlow]

Peter Schuller <address@hidden> writes:

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

In donkey/donkeyFiles.ml: 150:
(* Every second, try to connect to some clients *)          
let check_clients _ =
  decr remaining_seconds;
(*  Printf.printf "check_clients %d" !remaining_seconds; print_newline (); *)
...
(*            Printf.printf "client from list"; print_newline (); *)
...
(*                Printf.printf "client from new clients"; print_newline (); *)
...
(*                Printf.printf "no client"; print_newline (); *)

Include those code sniplets (remove the comment signs) and ry again.
mldonkey should then say something every time it reconnects. Watch for
new clients there. It might be that you have so many bad sources that
it never gets around to trying new sources. or you have not enough
sources and its not yet time to reconnect (unlikely).

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

How many sources are state new host and how many are state queued? And
how many are removed?

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

Looks to me that way too but just from watching the gui and download rates.

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

Whats the availability and last seen? Maybe noone actually has that
chunk. Then the last seen should be realy high (100d is maximum per
default and means never). If you downloaded the file for days and last
seen is still 100d it will probably never finsihed because some chunks
just don't exist.

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

MfG
        Goswin

PS: age and last seen colums must be added under file settings since they are 
not shown by default.