[YoThisBling]

When will the next Beta series begin?

[YoThisBling]

Oh and when will the new website be up?

[Sam]

I imagine when they're both ready.

As for the beta, my best guess would be two weeks or so before we have something that's worthy of a beta. No clue on the website, it's not my department.

[zab]

Originally Posted by YoThisBling

When will the next Beta series begin?

It can begin immediately if you're up to building from source. Quite a few of the people on this forum do so regularily.

[thommi]

Mojito should either connect to azureus torrent DHT (mafnet bith) and/or to the kademlia network (ed2k).

Sam, technical question:

is it in-dependent from the DHT, which protocol then is used?

So emule use DHT-A, Azureus use DHT-B and Limewire use DHT-C, would it then possible to let DHT-A and DHT-C use the emule-kad-protocol to connect each other ?

Think this should be independent, right?

So it would be possible to have DHT-C connecting to DHT-B to find torrent sources ?


So... can Mojito technically find sources on Azureus DHT or Kademlias DHT?

Thanks for an answer.

[Sam]

thommi --

The DHT will not connect to or use Azureus' DHT or the Kad DHT. Please stop asking for that, as it is not going to happen no matter how many times you ask.

[thommi]

sam, you get rough with me, i do not ask for a feature, i ask it technically if it is general possible because i do not have the knowledge to judge this, if it is not possible technically i would never ask, then mojito is mojiti, but if mojito can be hybird with azureus protocol (DHT finding sources) then I might ask for it. From a users view i never can understand why every brand makes an own system ? exeem was sha1 magnet as well and the changed, as I made it obvious, that it is sha1 and compatible with shareaza... so they changed, and there are some cases, in which a compatible system was aproved,... so why a different system for the azureus case.. well but this is not my concern, i just asked as I never will change from azureus to limewire personally... so i am jsut interested.
You know, the main question for me is downloading from kademlia in limewire.. and you sid maybe later maybe not. then we wait or azureus makes kademlia downloads with ed2k links possible to get the users back.
If you like, I would give feedback to the things wich will happen, so if there is a beta for the buddylist, let us know.

regards !

[roger]

Kademlia is the name of an algorithm to build Distributed Hash Tables (DHTs) which are a class of distributed systems. Besides Kademlia there exist many other algorithms to build DHTs such as Chord, Tapestry, Pastry or P-Grid to name a few. We chose Kademlia because it has proven to work on large scale, it has certain properties that are important for us and one of the inventors of Kademlia - Petar Maymounkov - is a good friend of us.

The heart of Kademlia is the routing algorithm based on the so called "XOR metric". Besides that it defines a minimum set of required operations, proposes some properties and that's pretty much it!

It is for example defined under the assumption that there are no hostiles out there who'd like to disrupt the DHT. So you have to come up with strategies to prevent certain attacks or at least limit the impact on the DHT. We have different concerns and strategies than lets say Azureus.

Yet another problem is that Kademlia is using the UDP protocol which is unreliable and becomes even more unreliable if you exceed a certain size limit for packets. In order to stay under this limit we have to decide what we want send over the wire. We have - again - different goals than Azureus.

There are many many other reasons why you can't simply mix DHT implementations just because they're using the same algorithm. Azureus' interpretation of Kademlia and goals they're trying to achieve are different from ours.

I've just taken a look at "Kad Network" (eMule's Kademlia implementation) and they're using 128bit IDs (Mojito will use 160bit IDs) and they cannot update contact informations in the DHT which is a very important feature of Mojito.

[thommi]

thanks for the hints and technical advice.
I see, i appreciate to make something better or somehting more customized.
The question is still open, kan a DHT with 128-ID implement a protocol (emule kad) which then downloads from clients, which organize itself in a DHT with 160-ID?
And I wanted to stress the common aspect, that e.g. azureus will download as well (from) torrent ... so here the question is the same, if nodes with 160-DHT can download or even forward sources from nodes using a 128-DHT.

DHT160A --->>> emule/torrent protocol --->>> DHT 128A
DHT160B
y
y
y
DHT 160C
DHT 160D

How the 160er organize and the 128er organize.. does not mean, that they can use the same protocol ? and forward as well sources

So the DHT128A can get the node DHT160C over the node DHT160A ????
As both (every) node uses the emule/torrent protocol....

so technical it is simple to get the azureue sources/nodes as well for downloading torrents and if limewire regards itself to be hybrid, the emule protocol could be implemented...

as torrent protocol makes limewire hybrid, there is no reason to say we do not want with the emule protocol to make it hybrid, as it is hybrid already.


:-))

[roger]

1) You can't mix 128bit and 160bit IDs in the same Route Table.

2) Many features depend on the protocol. We have no plans to give up any features in favor of to connect to AzDHT or Kad Network and comply with their limited feature set.

3) We have no plans to build a hybrid client.

4) The discussion is over. I'll answer no further questions on this topic.