Re: [Mldonkey-users] Open to paches for a more complete overnet support ?

[Pierre Etchemaite]

Le 04 Dec 2002 01:28:35 +0100, Norbert LATAILLE <address@hidden> a
écrit :

> I am looking at the overnet protocol since a few days, and I am working
> on patches for :
> a/ an improved peer discovery
> b/ correct upload support
> c/ mldonkey integration as an overnet peer (accepting publish opcodes
> and peer searches)

That would be great! (drooling)

> - why has overnet support stopped in mldonkey ? Is there a political
> reason behind this (apart from the lack of answers) ? What could be the
> overnet-community reaction to a "more complete" overnet support in
> mldonkey (which means more or less creating a bridge between the two
> networks) ?

I already posted here the URL of the thread where mldonkey asked for help.
You can go read it, and if doesn't enlighten you, you'll have to ask
mldonkey directly.

(searching)
http://forums.edonkey2000.com/phpBBovr/viewtopic.php?t=42310

> - I think that it would be wise to release such patches only when they
> are protocol-correct and tuned. It could avoid being "banned" for having
> disturbed the overnet protocol.

That's one of the reasons why mldonkey stopped the Overnet support.

> There is one point which still bother me in the current implementation :
> the ability for a user to choose his MD4 peer address. As overnet is
> "stateless" (important information, like routing tables and hash tables
> are volatile and replicated between neighbours), there is no use being
> able to restart with the same MD4 address. This is one big weakness of
> the overnet protocol, and leaving this parameter could only lead some
> malicous mldonkey users to choose their address (an for example being
> responsible for the "DIVX" search).

Even in the official client, the client MD4 is not well hidden in the
pref.met file, I've seen some 31337000000000000000000000000000 client md4s a
looooong time ago ;)

Nothing new there, it's definitely a weakness in the protocol, even if
usually more than one peer is responsible for a given key.