[Mojito] EventListner

[lancelot666]

Hi everyone,

I'm searching for a possibility to get informed when a new ResponseMessage / Message received by a peer (which is not the last receiver in the chain). Is it possible to implement a method, where you can register an EventHandler, which is called when a new ResponseMessage is arrived?


public interface EventMessageReceived{

public eventMessageReceived(DHTMessage message);

}


public void registerEventHandler(EventMessageReceived eh){
if (eh != null){
this.eventVector.add(eh);
}
}


Or is it already implemented?

I need this to collect information which passes the peer. It's not directly a cache, like kademlia proposes, rather like a collection of information which will be offered outside the dht. Of course I could receive this information by a query, but since this a query is very expensive** this is not such a good idea. Particularly because the values which are send through the peer will be sufficient for my purpose.

**I have made some measurement where I have queried a value (2kb) from the dht. For this query I need approx. 42 kb of traffic (including a findValue Call, which fails) in the dht to resolv that value. (dht consists of 100 (non-firewalled) clients). I think a reason for this big overhead is the lack of the dht-caching.

Thx,
lance

[Sam]

Hi Lance,

Our resident Mojito expert has departed for other projects, so it might take a little time for us to find the answer for you. If you need an answer immediately, you're best off looking through the code yourself (which is what we'd end up doing, anyway). Please let us know if you find anything. We will also let you know when/if we find an answer.

[lancelot666]

Hi,

thank you for this information. I looked into the source and think I already found the right place to add an EventListner. :) When I have patched Mojito, where should I post the patch?

[roger]

May I point out that there's no such thing as a chain in Kademlia. Nodes communicate directly with each other and a lookup for a non-existent key is the worst possible case because you've to find all k-closest Nodes before you can make the decision whether or not a key-value tuple exists.

And regards listening for arriving ResponseMessages. The code is already there...


MojtoDHT dht = MojitoFactory.createDHT();
dht.getMessageDiapcther().addMessageDispatcherList ener(
new MessageDispatcherListener() {
public void handleMessageDispatcherEvent(MessageDispatcherEven t e) {
if (e.getMessage() instanceof ResponseMessage) {
System.out.println("Received a Response");
}
}
}

[lancelot666]

Hi,

And regards listening for arriving ResponseMessages. The code is already there...

thx, exactly what I need :-).

May I point out that there's no such thing as a chain in Kademlia. Nodes communicate directly with each other

Mhh, I think my description was very bad again ;-). As I have unterstood Kademlia (and Mojito), a Value is received like that:

Node 1 wants the value to Key 1 and asks its neighbors (for simplicity Node 2)
Node 2 does't know this value (asks the k-nearest neighbors (e.g. Node 3)
Node 3 knows about the value of Key 1, therefor Node 3 sends back the value to Node 2
Node 2 sends it back to Node 1

That is what I meant with chain.

a lookup for a non-existent key is the worst possible case because you've to find all k-closest Nodes before you can make the decision whether or not a key-value tuple exists.

I know this. At the moment I try to find a solution to get rid of this lookups.

Thx again for your help!

[roger]

Node 1 wants the value to Key 1 and asks its neighbors (for simplicity Node 2)
Node 2 does't know this value (asks the k-nearest neighbors (e.g. Node 3)
Node 3 knows about the value of Key 1, therefor Node 3 sends back the value to Node 2
Node 2 sends it back to Node 1


I'm sorry to say but that's not how Kademlia works. What you're describing is something like Chord except that Node 3 sends the result out-of-band back to Node 1.

Kademlia works as follows

1) Node 1 is looking for a Key and selects the k-nearest Nodes for the given Key from its RouteTable

2) It selects a subset (parallelism) of these Nodes and sends them FIND_VALUE requests

3) If one of these Nodes has the value they will return it and the lookup terminates immediately. If they don't they will return the k-nearest Nodes for the given Key instead. These Nodes are hopefully closer than the ones you selected initially from your own RouteTable.

4) Node 1 adds the returned k-nearest Nodes to its lookup list, it selects again a subset of them and sends FIND_VALUE requests to them

5) And the algorithm restarts at #3.

This continues until a value is either found or you've found the k-nestest possible Nodes and can say that the Key doesn't exist.

The parameter which controls the size of the subset has a direct impact on the lookup performance and the utilized bandwidth. A small subset will result in a slower lookup but much better bandwidth utilization, a big subset will result in a fast lookup but but also in a high bandwidth utilization.

The optimization you're looking for is called "caching along the path". There are unfortunately a large number of paths and your key-value tuples will end up at a bazillion places in the DHT. An another problem is that the cached values will get out of sync (Node 1 publishes something in the DHT, you start caching the Values, Node 1 publishes new values under the same Key and the cached values will be different).