pezkuwichain/pezkuwi-fellows
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-fellows.git synced 2026-05-30 13:51:01 +00:00
Code Issues Packages Projects Releases Wiki Activity

deploy: 7410f5fc80

Browse Source
This commit is contained in:
bkchr
2024-07-06 00:54:44 +00:00
parent 6c383306c4
commit e90a4d136d
4 changed files with 6 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
print.html
+2 -1
View File
@@ -331,7 +331,8 @@ You can find a link to the specification <a href="https://github.com/libp2p/spec
+} +}
+ +
</code></pre> </code></pre>
<p>Each time a node wants to resolve an authorithy ID it will issue a query with a certain redundancy factor, and from all the results it receives it will decide to pick only the newest record. Additionally, the nodes that answer with old records will be updated with the newer record.</p> <p>Each time a node wants to resolve an authorithy ID it will issue a query with a certain redundancy factor, and from all the results it receives it will decide to pick only the newest record. Additionally,
in order to speed up the time until all nodes have the newest record, nodes can optionaly implement a logic where they send the new record to nodes that answered with the older record.</p>
<h2 id="drawbacks-1"><a class="header" href="#drawbacks-1">Drawbacks</a></h2> <h2 id="drawbacks-1"><a class="header" href="#drawbacks-1">Drawbacks</a></h2>
<p>In theory the new protocol creates a bit more traffic on the DHT network, because it waits for DHT records to be received from more than one node, while in the current implementation we just take the first record that we receive and cancel all in-flight requests to other peers. However, because the redundancy factor will be relatively small and this operation happens rarerly, every 10min, this cost is negligible.</p> <p>In theory the new protocol creates a bit more traffic on the DHT network, because it waits for DHT records to be received from more than one node, while in the current implementation we just take the first record that we receive and cancel all in-flight requests to other peers. However, because the redundancy factor will be relatively small and this operation happens rarerly, every 10min, this cost is negligible.</p>
<h2 id="testing-security-and-privacy-1"><a class="header" href="#testing-security-and-privacy-1">Testing, Security, and Privacy</a></h2> <h2 id="testing-security-and-privacy-1"><a class="header" href="#testing-security-and-privacy-1">Testing, Security, and Privacy</a></h2>
proposed/0091-dht-record-creation-time.html
+2 -1
View File
@@ -245,7 +245,8 @@ You can find a link to the specification <a href="https://github.com/libp2p/spec
+} +}
+ +
</code></pre> </code></pre>
<p>Each time a node wants to resolve an authorithy ID it will issue a query with a certain redundancy factor, and from all the results it receives it will decide to pick only the newest record. Additionally, the nodes that answer with old records will be updated with the newer record.</p> <p>Each time a node wants to resolve an authorithy ID it will issue a query with a certain redundancy factor, and from all the results it receives it will decide to pick only the newest record. Additionally,
in order to speed up the time until all nodes have the newest record, nodes can optionaly implement a logic where they send the new record to nodes that answered with the older record.</p>
<h2 id="drawbacks"><a class="header" href="#drawbacks">Drawbacks</a></h2> <h2 id="drawbacks"><a class="header" href="#drawbacks">Drawbacks</a></h2>
<p>In theory the new protocol creates a bit more traffic on the DHT network, because it waits for DHT records to be received from more than one node, while in the current implementation we just take the first record that we receive and cancel all in-flight requests to other peers. However, because the redundancy factor will be relatively small and this operation happens rarerly, every 10min, this cost is negligible.</p> <p>In theory the new protocol creates a bit more traffic on the DHT network, because it waits for DHT records to be received from more than one node, while in the current implementation we just take the first record that we receive and cancel all in-flight requests to other peers. However, because the redundancy factor will be relatively small and this operation happens rarerly, every 10min, this cost is negligible.</p>
<h2 id="testing-security-and-privacy"><a class="header" href="#testing-security-and-privacy">Testing, Security, and Privacy</a></h2> <h2 id="testing-security-and-privacy"><a class="header" href="#testing-security-and-privacy">Testing, Security, and Privacy</a></h2>
searchindex.js
+1 -1
View File
File diff suppressed because one or more lines are too long
searchindex.json
+1 -1
View File
File diff suppressed because one or more lines are too long