[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0003] branch master updated: Added some more text
|
From: |
gnunet |
|
Subject: |
[lsd0003] branch master updated: Added some more text |
|
Date: |
Thu, 10 Dec 2020 15:59:28 +0100 |
This is an automated email from the git hooks/post-receive script.
elias-summermatter pushed a commit to branch master
in repository lsd0003.
The following commit(s) were added to refs/heads/master by this push:
new 665fd22 Added some more text
665fd22 is described below
commit 665fd221f3bc1e15eb8cb678a401059381764dc8
Author: Elias Summermatter <elias.summermatter@seccom.ch>
AuthorDate: Thu Dec 10 15:59:07 2020 +0100
Added some more text
---
draft-summermatter-set-union.xml | 90 +++++++++++++++++++++++++++++++---------
1 file changed, 71 insertions(+), 19 deletions(-)
diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index 67aacf6..57dd1eb 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -34,7 +34,7 @@
</title>
<seriesInfo name="Internet-Draft"
value="draft-summermatter-set-union-01"/>
<author fullname="Elias Summermatter" initials="E."
surname="Summermatter">
- <organization>.</organization>
+ <organization>Seccom GmbH</organization>
<address>
<postal>
<street>Brunnmattstrasse 44</street>
@@ -72,7 +72,24 @@
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>
- --- TEXT HERE ---
+ This document describes the Byzantine Fault Tolerant Set
Reconciliation used to efficient and securely
+ synchronize two sets of elements in a peer-to-peer network. It
provides strong cryptographic and
+ probabilistic proceedings to discover and ban dishonest and
bad behaving peers.
+ </t>
+ <t>
+ The Byzantine Fault Tolerant Set Reconciliation can be used in
a variety of different fields of application.
+ It is used in GNS to distribute revocations over the
peer-to-peer network and it can be used as a central
+ component in distributed E-Voting systems to securely
synchronize the votes between the peers.
+ </t>
+ <t>
+ The internal structure of the elements in the set is handheld
by the application using the protocol and is not
+ described more in detail than known limitations.
+ </t>
+ <t>
+ The protocol has been designed to minimize network round-trips
and bytes send over the network at the
+ expense of CPU operations and memory usage. Since CPU
operations are much cheaper than network round trips.
+ Due to certain parameters the protocol decides whatever either
sending the full set or just sending the elements
+ that differ is cheaper.
</t>
<t>
This document defines the normative wire format of resource
records, resolution processes,
@@ -91,6 +108,16 @@
</t>
</section>
+ <section anchor="contributors" numbered="true" toc="default">
+ <name>Contributors</name>
+ <t>
+ The major original contributors of this documents have been Elias
Summermatter and Christian Grothoff
+
+ The origianl GNU NET implementation of the Byzantine Fault
Tolerant Set Reconciliation has been mainly
+ written by Florian Dold and Christian Grothoff
+ </t>
+ </section>
+
<section anchor="ibv" numbered="true" toc="default">
<name>Invertible Bloom Filter</name>
<section anchor="ibv_description" numbered="true" toc="default">
@@ -191,29 +218,55 @@
The set union protocol uses the above discussed topics
Invertible Bloom Filter and Strata Estimators.
Depending on the state of the two sets there are different
strategies or operation modes how to efficiently
determinate missing elements in two sets of two peers.
+ </t>
+ <t>
+ The initiating peer starts in the "Expect SE" state and the
receiving peer starts in the "Expecting IBF" state.
+ In a first step of the protocol the initiating peer opens a
connection to the receiving peer, requests a Strata
+ Estimator from the receiving peer. The receiving peer answers
with the Strata Estimator.
+ After the initiating peer has received the Strata Estimator he
decides which sync mode is optimal for the
+ the estimated set difference.
+ To ensure that ...... the difference is multiplied by 1.5 if
there are more than 200 elements differences between the sets (WHY? line 1398).
+ The Full Synchronisation Mode is used if the flag to force
full sync is set, the estimated difference between the two sets is bigger
+ than 25% or the set size of the receiving peer is zero.
Otherwise the Individual Element Synchronisation Mode is used.
+
+
</t>
<section anchor="modeofoperation_full-sync-client-with-bigger-set"
numbered="true" toc="default">
- <name>Full sync mode</name>
+ <name>Full Synchronisation Mode</name>
+
<t>
The simples mode is the full sync mode. The idea is that
if the difference between the sets of the two
- peers exceeds a certain threshold the overhead of
determinate which elements are different overweight's
- the overhead of sending the complete set. In this case its
more efficient to just exchange the full set.
+ peers exceeds a certain threshold the overhead of
determinate which elements are different overweight
+ the overhead of sending the complete set. In this case its
more efficient to just exchange the full sets.
+ ############# IMAGE ##################
+ </t>
+ <t>
+ If the set of the initiating peer is bigger than the set
of the receiving peer, the initiating
+ peer sends a "Request Full" message and change from
"Expecting SE" in "Full Receiving" State.
+ In all other cases the initiating peer starts sending all
set elements to the other peer
+ followed by the "Full Done" message and changes into "Full
Sending" State.
+ </t>
+ <t>
+ <strong>Expecting IBF: </strong>
+ If a peer in the in state "Expecting IBF" receives a
"Request Full" message from the other peer, the
+ peer starts sending all the elements of the set followed
by a "Full Done" message and the change to the
+ "Full Sending" State. If the peer receives an "Full
Element" the peer changes to the state "Full Receiving".
</t>
<t>
- After the initiating peer (Client) opened a connection to
the other peer (Server) the Server answers
- with a SE(C) of his set and changes to the "Expecting IBF"
state. When the client receives the SE(C)
- from the server and the client set size is smaller or
equal to the set size of the server the client
- changes from the Expect SE State to Full Sending State and
starts sending Full element requests containing the set
- of the client.
- If the set size of the client is larger than the servers
set size the client changes into Full Receiving
- (HINT: EXPECT IBF in code) mode an sends a Request Full
message to the server.
+ <strong>Full Sending: </strong>
+ While a peer is in "Full Sending" state the peer expects
to continuously receiving elements from the other
+ peer. As soon as a the "Full Done" message is received the
peer changes into "Finished" state
</t>
<t>
- If the Server receives
+ <strong>Full Receiving (In code: Expecting IBF): </strong>
+ While a peer is in "Full Receiving" state the peer expects
to continuously receiving elements from the other
+ peer. As soon as a the "Full Done" message is received the
peer starts sending his complete set to the other
+ peer followed by a full done. After sending the last
message the peer changes into "Finished" state.
</t>
+
</section>
<section anchor="modeofoperation_individual-elements"
numbered="true" toc="default">
- <name>Individual element sync mode</name>
+ <name>Individual Element Synchronisation Mode</name>
<t>--- TEXT HERE ---</t>
</section>
<section anchor="modeofoperation_combined-mode" numbered="true"
toc="default">
@@ -261,8 +314,7 @@
</dd>
<dt>MSG TYPE</dt>
<dd>
- is a 16-bit unsigned integer of the GNUNET header
which contains a message number
- in the GNUNET Protocol. For this message the
number is 563.
+ is a 16-bit unsigned integer in network byte order
(BIG ENDIAN) with the value as registered in GANA ########### HERE
</dd>
<dt>OPERATION TYPE</dt>
@@ -275,7 +327,7 @@
</dd>
<dt>APX</dt>
<dd>
- is 512bit GNUNET hashcode that identifies the
application.
+ is SHA-512bit hash that identifies the application.
</dd>
</dl>
</section>
@@ -287,7 +339,7 @@
<section anchor="messages_ibf_description" numbered="true"
toc="default">
<name>Description</name>
<t>
- This message is send in the peer2peer protocol to
transmit the IBF to the other client
+ This message is send in the peer2peer protocol to
transmit the IBF to the other client ### Wann, in welchem state übergange
verschickt, was passiert wenn sie entfangen wird was passiert
</t>
</section>
<section anchor="messages_ibf_structure" numbered="true"
toc="default">
@@ -467,7 +519,7 @@
</dd>
<dt>GNUNET HASH</dt>
<dd>
- is a 512-bit GNUNET Hash of the element that is
requested with a inquiry message.
+ is a SHA-512bit hash of the element that is
requested with a inquiry message.
</dd>
</dl>
</section>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [lsd0003] branch master updated: Added some more text,
gnunet <=