docs(minhton): Add further esearch info (fix #93)

docs/daisi/minhton-ns3/scenariofile.md

@@ -377,7 +377,7 @@ Waits the specificed amount (miliseconds).
 ## Examples
 ### Adding Nodes
 
-The following `scenarioSequence` let 100 nodes join the network. The following `scenarioSequence` let 100 nodes join the network.
+The following `scenarioSequence` lets 100 nodes join the network.
 
 ```yaml
 scenarioSequence:
@@ -389,7 +389,7 @@ scenarioSequence:
 
 ### Removing Nodes
 
-The following `scenarioSequence` let 100 nodes join the network, and than 100 nodes are leaving the network.
+The following `scenarioSequence` lets 100 nodes join the network, and than 100 nodes are leaving the network.
 
 ```yaml
 scenarioSequence:
@@ -405,7 +405,8 @@ scenarioSequence:
 
 ### Searching Nodes
 
-The following `scenarioSequence` let 100 nodes join the network, and than 100 search-exact queries are executed. After 100 search-exact queries are executed, "search-all" is executed.
+The following `scenarioSequence` lets 100 nodes join the network, and than 100 search-exact queries are executed.
+After 100 search-exact queries are executed, "search-all" is executed (Warning: search-all can congest the network quickly).
 
 ```yaml
 scenarioSequence:
@@ -422,7 +423,7 @@ scenarioSequence:
 
 ### Static P2P Build
 
-Building a network statically of 100 + 1 nodes without needing join.
+Building a network statically of 100 nodes + 1 root node without needing join.
 It is only possible to execute this command once right in the beginning.
 The event timestamp cannot be 0 - therefore you need to increase the time by a little bit.
 
@@ -436,7 +437,7 @@ The event timestamp cannot be 0 - therefore you need to increase the time by a l
 
 ### Peer Discovery
 
-Inside the scenario sequence, ESearch find queries can be specified.
+Inside the scenario sequence, [ESearch](../../management_overlay/using.md#peer-discovery-entity-search-esearch) find queries can be specified, after you have created a network as [shown above](#adding-nodes).
 You initiate a find query with the requesting node (level:number).
 The scope can be `all` or `some` and the query must be a valid expression.
 In the following example we define a find query from the requesting node 100:100 with an unrestricted scope and query the attribute `a01` and `a02` with a value over 5.
@@ -453,7 +454,8 @@ scenarioSequence:
         validity-threshold: 10000
 ```
 
-Periodically repeated requests are being counted down. After the countdown value has been reached, the simulation will wait until the last request has been processed and the simulation stop time will be set accordingly.
+Periodically repeated requests are being counted down.
+After the countdown value has been reached, the simulation will wait until the last request has been processed and the simulation stop time will be set accordingly.
 
 ```yaml
 - request-countdown: 1000
@@ -467,19 +469,15 @@ peerDiscoveryEnvironment:
     requests: off
 ```
 
-#### Attributes / Values
-
 The name of an attribute (here a01, a02...) can be chosen arbitrarily, but must be unique.
-Each attribute needs a presence, content and update behavior.
-Presence behavior describes which nodes posses the attribute and which not.
-Content behavior describes the kinds of values an attribute can have.
-Update behavior describes how often the value of an attribute will be updated.
+
+Each attribute needs a presence, content and update behavior like this:
 
 ```yaml
 attributes:
     a01:
         presenceBehavior:
-            ...
+            percentage: 0.8
         contentBehavior:
             ...
         updateBehavior:
@@ -493,20 +491,16 @@ attributes:
             ...
 ```
 
-##### Presence Behavior
+**Presence Behavior:**
 
-Presence Behavior is simply described by the percentage of nodes who posses this attribute. The percentage has to be given as a float (100 % -> 1.0).
+Presence behavior describes the percentage of nodes who posses this attribute.
+The percentage has to be given as a float (100% -> 1.0).
 
-```yaml
-presenceBehavior:
-    percentage: 0.8
-```
-
-##### Content Behavior
+**Content Behavior:**
 
-Content behavior can be specified as Uniform, Gaussian, Choice or Constant.
-Uniform and Gaussian are only numerical values.
-Choice and constant can be either integers, floats, booleans or strings.
+Content behavior describes the kinds of values an attribute can have.
+With the types `uniform` and `gaussian` you can only use numerical values.
+With the types `choice` and `constant` the values can be either integers, floats, booleans or strings.
 
 Uniform:
 
@@ -548,8 +542,9 @@ contentBehavior:
             prob: 0.6
 ```
 
-##### Update Behavior
+**Update Behavior:**
 
+Update behavior describes how often the value of an attribute will be updated.
 The update behavior is either dynamic or static.
 If its static, the value will never be updated.
 If its dynamic, values will be updated periodically.

minhton/docs/using.md

@@ -144,13 +144,37 @@ Since the node that was previously located at 2:1 moved to 1:1 to replace it, bo
   <figcaption markdown>**Figure 4:** The entries in the routing information of the 4 nodes in the network. The updated entries after the node, which was previously at 1:1 left, are highlighted in blue.</figcaption>
 </figure>
 
-## Entity Search / Peer Discovery
+## Peer Discovery / Entity Search (ESearch)
 
 Each node in the constructed peer-to-peer network may have different capabilities and properties.
 To find peers with specific capabilities and properties, we use a practical solution to the problem of peer discovery, which is finding peers in the network according to a specified query.
 We contribute a peer discovery for an m-ary tree-structured P2P network by utilizing a connected dominating set (CDS), a technique that is typically used in unstructured networks.
+Our solution is also known as Entity Search (ESearch).
 Our approach to constructing the CDS requires no additional communication cost, while nodes can insert, update and remove data within O(1).
 
+Each CDS maintains up to two levels at the same time and consists of a number of dominating set nodes (DSNs).
+Furthermore, each DSN is responsible for several nodes and their KVPs within its cover area (CA) as seen in [Figure 5](#fig_peer_discovery).
+A CA includes, if present, the DSN itself, its *m* RT neighbors to the left and right, its own *m* children, and the routing table children.
+If a DSN has a neighboring DSN to its left, only *m − 1* in-level neighbors to the left are included in the CA.
+It concludes that the CAs of all DSNs are disjoint sets, including up to *(2m + 1) · m* nodes.
+
+<figure markdown>
+  <a id="fig_peer_discovery"></a>
+  ![Routing links example](./img/peer_discovery_forwarding.svg)
+  <figcaption markdown>**Figure 5:** Peer Discovery example where Node (2:1) sends the peer discovery request φ to one dominating set node (DSN) on each level, where at least one DSN exists.
+  Each DSN forwards the request to other DSNs on the same level and returns the discovery result to the requesting node.</figcaption>
+</figure>
+
+The peer discovery consists of two phases.
+In the first phase of the example from [Figure 5](#fig_peer_discovery), node (2:1) sends its discovery request φ to one DSN on each even level, e.g., (0:0), (2:2), and (4:6).
+Any node p can estimate the tree’s height with its adjacent links since at least one adjacent of p is located either on the highest level h − 1 or one level below the highest level, h − 2.
+However, after sending the discovery request to one DSN per level, these DSNs are responsible for forwarding φ among each DSN on their level.
+For example, the DSN (4:6) forwards the request to the other DSNs on level 4, i.e., (4:2) and (4:10).
+This request gets forwarded until all DSNs of the CDS have received it.
+The second phase includes an evaluation of the peer discovery query φ.
+Each DSN evaluates the maintained CA either by using its stored or requesting new information from the nodes assigned to it.
+Any result is returned by each DSN to the requester node (2:1).
+
 A peer discovery query description is given according to boolean algebra consisting of logical *and*-, *or*- and *not*-operators.
 Literals are comparisons with the key-value pairs (KVPs).
 The peer discovery query result is expected to contain information about each peer whose KVPs satisfy the peer discovery query.
@@ -160,7 +184,7 @@ The peer discovery query result is expected to contain information about each pe
 <figure markdown>
   <a id="fig_routing_links"></a>
   ![Routing links example](./img/minhton_links.svg)
-  <figcaption markdown>**Figure 5:** The node 3:4 in the example tree with fanout 2 maintains several types of links.</figcaption>
+  <figcaption markdown>**Figure 6:** The node 3:4 in the example tree with fanout 2 maintains several types of links.</figcaption>
 </figure>
 
 Each MINHTON node individually maintains links to selected nodes in the network based on the tree structure and its position in the tree for its local view as follows: