with the current endeavor to plug a distribted hash table below the open-search-client, here is the protocol used to for communication between the open-search core and the p2p-layer.

the p2p engine will run as separate process, and communication is done via a local TCP socket. for testing and develpment we use two simple perl-scripts (contrib/hatsim) and it will act as a p2p-db simulator.

the protocol is yet rather simple:

we use "++" as separator for ASCII-text encoded arguments. the format is COMMAND ++ opt-args ++ HASHED-KEY ++ XML-VALUE ++

example perl-printf's:

"STORE"."++"."<p2p-opt-args>"."++"."<HASH_FOR_KEYWORD:>"."++"."<XML-LIST-OF-URL_HASH>"."++";
"STORE"."++"."<p2p-opt-args>"."++"."<HASH_FOR_URL>"."++"."<XML-DATA_FOR-URLS>"."++";
"LOOKUP"."++"."<p2p-opt-args>"."++"."<HASH>"  # → returns either <XML-LIST-OF-URL_HASH> or <XML-DATA_FOR-URLS> 

this very simple protocol will be enough for a protptype test implementation. – the <p2p-opt-args> are yet unused but we forsee a couple of features that would need to pass extra information to the p2p-engine..

currently packets are gpg signed when they pass tru the p2p layer, using a host-key rather than individual crawler signature. – also the format of the xml-data is yet unknown to the the p2p layer. once search-filtering is optimized and parts of it can be done at network-layer, there'll be a new command STORE_IDX and a separate LOOKUP functions for different return types. – it remains to be discussed whether priotity-tags are implemented as optinal-argument or separate command.