diff options
Diffstat (limited to 'draft-schanzen-r5n.xml')
-rw-r--r-- | draft-schanzen-r5n.xml | 34 |
1 files changed, 32 insertions, 2 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml index 52637b7..a30663a 100644 --- a/draft-schanzen-r5n.xml +++ b/draft-schanzen-r5n.xml | |||
@@ -323,6 +323,7 @@ peer-public-key := [A-HJ-NP-Z1-9]+ | |||
323 | The following is a non-normative example of a HELLO containing three | 323 | The following is a non-normative example of a HELLO containing three |
324 | HELLO URIs: | 324 | HELLO URIs: |
325 | </t> | 325 | </t> |
326 | <!-- FIXME peer id type | length | id payload | 0-terminated strings for addresses --> | ||
326 | <figure> | 327 | <figure> |
327 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 328 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
328 | Y924NSHMMZ1N1SQCE5TXF93ED6S6JY311K0QT86G9WJC68F6XVZ0 \ | 329 | Y924NSHMMZ1N1SQCE5TXF93ED6S6JY311K0QT86G9WJC68F6XVZ0 \ |
@@ -469,6 +470,35 @@ PEER-SELECT(key, bloomfilter) | |||
469 | END | 470 | END |
470 | ]]></artwork> | 471 | ]]></artwork> |
471 | </figure> | 472 | </figure> |
473 | <t> | ||
474 | The procedure to determine if we are the closest know peer for a given | ||
475 | message key and bloomfilter is defined as follows: | ||
476 | </t> | ||
477 | <figure> | ||
478 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
479 | FIND-BUCKET(peerID, key, buckets) | ||
480 | N := MATCHING-BITS (peerID, key) | ||
481 | return Nth bucket FROM buckets | ||
482 | END | ||
483 | AM-CLOSEST-PEER(key, myPeerID, bloomfilter, buckets) | ||
484 | closestPeersBucket := FIND-BUCKET (myPeerID, key, buckets) | ||
485 | IF key == myPeerID | ||
486 | return TRUE | ||
487 | END | ||
488 | myDistance := XOR(myPeerID, key) | ||
489 | FOR EACH p IN closestPeersBucket | ||
490 | IF XOR(p, key) < myDistance | ||
491 | return FALSE | ||
492 | END | ||
493 | XOR(p, key) == myDistance | ||
494 | return TRUE | ||
495 | END | ||
496 | END | ||
497 | return TRUE | ||
498 | END | ||
499 | ]]></artwork> | ||
500 | </figure> | ||
501 | |||
472 | 502 | ||
473 | </section> | 503 | </section> |
474 | </section> | 504 | </section> |
@@ -811,10 +841,10 @@ END | |||
811 | implementation MUST periodically send HELLO GET queries for its own | 841 | implementation MUST periodically send HELLO GET queries for its own |
812 | peer ID. | 842 | peer ID. |
813 | </t> | 843 | </t> |
814 | <t>FIXME: Periodically -> more specific</t> | 844 | <t>FIXME: Periodically -> more specific? No. Frequency may be adapted depending on network conditions, known peers, busy/idle etc.</t> |
815 | <t> | 845 | <t> |
816 | Any implementation encountering a HELLO GET request initially | 846 | Any implementation encountering a HELLO GET request initially |
817 | considers sending its own peer ID (FIXME: What does this mean?). | 847 | sends its own peer ID if it. |
818 | </t> | 848 | </t> |
819 | </section> | 849 | </section> |
820 | <section anchor="security" numbered="true" toc="default"> | 850 | <section anchor="security" numbered="true" toc="default"> |