Discussion: how to distinguish between +end (lookup) and +end (distribute)?

As I’m implementing a simple chat client I’m finding some holes in the clj-telehash implementation.

A blocking problem at this point is how to distinguish between +end (lookup) and +end (distribute). This problem occurs when a switch sends an +end that is not its own IP:PORT but an application-specific end (e.g. user@chat).

The fundamental problem is that the receiving switch cannot know if the +end is for lookup purposes or for distribution purposes. The +end would be for lookup purposes if the counterparty application wants to find one of its chat contacts (e.g. jer@chat). The +end would be for distribution purposes if the counterparty application wants to distribute its own chat id (e.g. steven@chat).

If the +end is for distribution purposes it should be added to the kbuckets since when another +end arrives for lookup purposes the counterparty’s IP:PORT must be returned in .see . If the +end is for lookup purposes it should not be added to the kbuckets since we don’t want to send out an IP:PORT with .see for a switch that’s guaranteed not to know about the +end it is looking for. Moreover, there is only one slot per end in the kbuckets. If we add each end-for-lookup-purposes to the kbuckets we’ll have multiple switches per end. Is this as intended?

Am I missing something here?

I’m pretty sure the only hashes you’re supposed to add to your kbuckets are the hashes of the other nodes’ IP:port. +end is always a lookup. The reason you send a +end with your own node’s hash is to find and connect to the nodes closest to your own.

Comment: Mon Apr 11 19:13:42 NZST 2011

[commenting here due to lack of mailing list] I think this is a symptom of the brevity of the protocol and documentation, and the decision to not to keep the PING, STORE, FIND_NODE, FIND_VALUE (from the original Kademlia paper) as obvious parts of the messages (Telexes?!?). I am also trying to create a TeleHash application and the new-to-me terminology used (Signal/Command/End/Tap) is definately lacking points for obviousness.