Re: [Mldonkey-users] Still a few bugs

[René Gallati]

Hello,

> Please post your comments on these issues.
> 1) I have update_server_list set to false and added n servers I want to
> use. A few days later I have about 2000 servers. I have no web_infos added
> and the server list keeps increasing. I think this happens by received
> server IPs vom other mldonkeys (propagate_servers?).

You automatically get a server per client. Whenever two peers (regardless of
whether they are mldonkey, edonkey or emule peers) communicate with each
other, they do a handshake. In that handshake a peer tells the other to
which server it is currently connected. So you get one server with every
peer that you contact or from every peer that contacts you.

That's normal and is in the original eDonkey protocol. Maybe mldonkey should
not add these servers to its internal list when update_server_list is false.

Also, whenever you connect to a server, that server sends you a list of all
the servers it knows, so you additionally get some (more) servers there.

Note that both the servers you get from peers and from servers don't need to
be functional ones. They are not malicously giving you non-working IP's,
they don't know it better either.

> 2) The are plenty entries in my serverlist which doubled over time. Some
> exist there 30 times (I mean the description of the server, with 30
> different T-Online IPs). I have max_server_age set to 1, and they
> shouldn't be there. remove_old_servers doesn't help, too. These duplicate
> IPs can't be active, because their age is >1 day (and T-Online DSL
> forcefully disconnects after 24h. In the servers description it is even
> mentioned that they're based on T-DSL). Why are they still there? I think
> it's a bug in the serverlist management (like point 1 above)

That's most likely the result of the servers giving you a server list after
connect. Actually that's a thing that needs to be fixed on the servers, so
lugdunum would be the best contacted and asked if he could change it so,
that only verified and working servers are going to be announced.

> 3) The Upload management is still a mess. Without any download of mine and
> only sharing, the max_hard_upload_rate is perfectly at the value it should
> be. I tested 3,4,5,..10,..12. As soon as I add ONE download, the upstream
> collapses over time, regardless of the max_hard_upload_rate setting. I
> think the bytecounter of the upload management ignores any requests. This
> should be fixed. Many mldonkeys I know of decrease max_hard_upload_rate
> because mldonkey is killing their line. But this doesn't help so they
> decrease further and further. They still have 14k/s outgoing, but 12k/s of
> them are requests or answer to those. This sucks. We have to get this
> upload management fixed. Perhaps it's just called wrong. We should add an
> max_hard_upstream_rate which means every byte going up, not just the
> chunks.

As far as my observations go, this *only* happens when you add a
"high-source" file to your download list (ie a file with several houndred
sources). Outgoing traffic then raises up to 10KB over max_hard_up (it's a
bit better in 2.00+2 cvs but not much) Also backcoming non-transfer traffic
can raise up to about the same amount when this happens, as you correctly
noted.

This is clearly a bug and needs to be fixed because it has several quite
severe side-effects. (downstream collapses, very high memory usage, can
cause high cpu usage)

By the way, whenever this happens, mldonkey sends out houndreds of requests
for file info in a very short time. All these packets are around size 15-60
bytes so you can filter them quite easily using a traffic shaper for the
time being.

As I said, current cvs version is a bit less "greedy" but it has the same
problem. Until that is fixed, I'd consider mldonkey unable to properly
handle high-source files.

See also my bug report
http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=1555&group_id=1409

btw: If you do have the problem with the high-memory usage (100+MB instead
of 20MB etc.) try setting compaction_delay to 1 hr. Whatever compaction
exactly does, it frees lots of unused memory that gets blocked as soon as
mldonkey starts this behaviour.

> 4) Please re-implement a chunk display in the telnet interface. As you can
> see by many requests this is needed for third party frontends (e.g. php).

Ever tried mldonkeywatch? It has a chunk display although I am pretty sure
it is faulty (only showing the chunk availability to the currently connected
peers of that specific file)

--

C U

     - -- ---- ----- -----/\/  René Gallati  \/\---- ----- --- -- -