[GNUnet-SVN] [gnunet-texinfo] branch master updated: developer.texi: Chapters NSE + HOSTLIST subsystem.

[gnunet]

This is an automated email from the git hooks/post-receive script.

ng0 pushed a commit to branch master
in repository gnunet-texinfo.

The following commit(s) were added to refs/heads/master by this push:
     new 6fb8d82  developer.texi: Chapters NSE + HOSTLIST subsystem.
6fb8d82 is described below

commit 6fb8d8234b13c06fb44498ddec30394c8e9c2092
Author: ng0 <address@hidden>
AuthorDate: Fri Feb 17 16:58:13 2017 +0000

    developer.texi: Chapters NSE + HOSTLIST subsystem.
---
 developer.texi | 35 +++++++++++++++++++++++++++++------
 1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/developer.texi b/developer.texi
index 2e3c8dc..8f36558 100644
--- a/developer.texi
+++ b/developer.texi
@@ -4156,7 +4156,7 @@ of [2/3 estimate, 3/2 estimate]. We will now give an 
overview of the algorithm
 used to calcualte the estimate; all of the details can be found in this
 technical report.
 
address@hidden Motivation
address@hidden Motivation
 @node Motivation
 
 Some subsytems, like DHT, need to know the size of the GNUnet network to
@@ -4168,7 +4168,7 @@ protocols may allow any malicious peer to manipulate the 
final result or to
 take advantage of the system to perform DoS (Denial of Service) attacks against
 the network. GNUnet's NSE protocol avoids these drawbacks.
 
address@hidden Security
address@hidden Security
 @node Security
 
 The NSE subsystem is designed to be resilient against these attacks. It uses
@@ -4180,9 +4180,8 @@ calculated periodically and out-of-time traffic is either 
ignored or stored for
 later retransmission by benign peers. In particular, peers cannot trigger
 global network communication at will.
 
address@hidden Principle
address@hidden Principle
 @node Principle
address@hidden %**end of header
 
 The algorithm calculates the estimate by finding the globally closest peer ID
 to a random, time-based value.
@@ -4190,8 +4189,8 @@ to a random, time-based value.
 The idea is that the closer the ID is to the random value, the more "densely
 packed" the ID space is, and therefore, more peers are in the network.
 
address@hidden Example
 @node Example
address@hidden %**end of header
 
 Suppose all peers have IDs between 0 and 100 (our ID space), and the random
 value is 42. If the closest peer has the ID 70 we can imagine that the average
@@ -4202,13 +4201,14 @@ them. Naturally, we could have been rather unlucky, and 
there is only one peer
 and happens to have the ID 44. Thus, the current estimate is calculated as the
 average over multiple rounds, and not just a single sample.
 
address@hidden Algorithm
 @node Algorithm
address@hidden %**end of header
 
 Given that example, one can imagine that the job of the subsystem is to
 efficiently communicate the ID of the closest peer to the target value to all
 the other peers, who will calculate the estimate from it.
 
address@hidden Target value
 @node Target value
 @c %**end of header
 
@@ -4218,6 +4218,7 @@ to an agreed value. If the rounding amount is 1h 
(default) and the time is
 rouning amount (in this example would be every hour). Every repetition is
 called a round.
 
address@hidden Timing
 @node Timing
 @c %**end of header
 
@@ -4232,6 +4233,7 @@ the middle of the round. If its bigger it will be earlier 
and if its smaler
 (the most likely case) it will be later. This ensures that the peers closests
 to the target value start broadcasting their ID the first.
 
address@hidden Controlled Flooding
 @node Controlled Flooding
 @c %**end of header
 
@@ -4248,6 +4250,7 @@ values, since a better value can come before the 
broadcast time, rendering the
 previous one obsolete and saving the traffic that would have been used to
 broadcast it to the neighbors.
 
address@hidden Calculating the estimate
 @node Calculating the estimate
 @c %**end of header
 
@@ -4263,6 +4266,7 @@ size could be half of the estimate or twice as much). 
Note that the actual
 network size is calculated in powers of two of the raw input, thus one bit of
 uncertainty means a factor of two in the size estimate.
 
address@hidden libgnunetnse
 @node libgnunetnse
 @c %**end of header
 
@@ -4279,6 +4283,7 @@ the first. The default round time is set to 1 hour.
 The disconnect call disconnects from the NSE subsystem and the callback is no
 longer called with new estimates.
 
address@hidden Results
 @node Results
 @c %**end of header
 
@@ -4314,6 +4319,7 @@ standard deviation value, not only the average (in 
particular, if the standard
 veriation is very high, the average maybe meaningless: the network size is
 changing rapidly).
 
address@hidden Examples
 @node Examples
 @c %**end of header
 
@@ -4335,6 +4341,7 @@ To put this in perspective, if someone remembers the LHC 
Higgs boson results,
 were announced with "5 sigma" and "6 sigma" certainties. In this case a 5 sigma
 minimum would be 2 million and a 6 sigma minimum, 1.8 million.
 
address@hidden The NSE Client-Service Protocol
 @node The NSE Client-Service Protocol
 @c %**end of header
 
@@ -4353,6 +4360,7 @@ respective round.
 When the @code{GNUNET_NSE_disconnect} API call is executed, the client simply
 disconnects from the service, with no message involved.
 
address@hidden The NSE Peer-to-Peer Protocol
 @node The NSE Peer-to-Peer Protocol
 @c %**end of header
 
@@ -4404,6 +4412,7 @@ Finally, when it comes to send the stored message for the 
current round to the
 neighbors there is a random delay added for each neighbor, to avoid traffic
 spikes and minimize cross-messages.
 
address@hidden GNUnet's HOSTLIST subsystem
 @node GNUnet's HOSTLIST subsystem
 @c %**end of header
 
@@ -4429,6 +4438,7 @@ outdated set of HELLO messages from the distribution. In 
this case, getting new
 peers to connect to the network requires either manual effort or the use of a
 HOSTLIST to obtain HELLOs.
 
address@hidden HELLOs
 @node HELLOs
 @c %**end of header
 
@@ -4438,6 +4448,7 @@ identity of the peer (based on the cryptographic public 
key) a HELLO message
 may contain address information that specifies ways to contact a peer. By
 obtaining HELLO messages, a peer can learn how to contact other peers.
 
address@hidden Overview for the HOSTLIST subsystem
 @node Overview for the HOSTLIST subsystem
 @c %**end of header
 
@@ -4454,6 +4465,7 @@ hostlist format is a binary blob containing a sequence of 
HELLO messages. Note
 that any HTTP server can theoretically serve a hostlist, the build-in hostlist
 server makes it simply convenient to offer this service.
 
address@hidden Features
 @node Features
 @c %**end of header
 
@@ -4469,6 +4481,7 @@ gossip
 @item automatically learn about hostlist servers from the gossip of other peers
 @end itemize
 
address@hidden Limitations
 @node Limitations
 @c %**end of header
 
@@ -4479,6 +4492,7 @@ The HOSTLIST daemon does not:
 @item verify the address information in the HELLO messages
 @end itemize
 
address@hidden Interacting with the HOSTLIST daemon
 @node Interacting with the HOSTLIST daemon
 @c %**end of header
 
@@ -4502,6 +4516,7 @@ shutdown if changes to this value are to have any effect 
on the daemon (as
 HOSTLIST does not monitor STATISTICS for changes to the download
 frequency).
 
address@hidden Hostlist security: address validation
 @node Hostlist security: address validation
 @c %**end of header
 
@@ -4519,6 +4534,7 @@ HOSTLIST servers specified in the configuration, 
downloads the (unvalidated)
 list of HELLO messages and forwards these information to the TRANSPORT server
 to validate the addresses.
 
address@hidden The HOSTLIST daemon
 @node The HOSTLIST daemon
 @c %**end of header
 
@@ -4545,6 +4561,7 @@ events.
 To clean up on shutdown, the daemon has a cleaning task, shutting down all
 subsystems and disconnecting from CORE.
 
address@hidden The HOSTLIST server
 @node The HOSTLIST server
 @c %**end of header
 
@@ -4553,6 +4570,7 @@ small web server other peers can connect to and download 
a list of HELLOs using
 standard HTTP; it may also advertise the URL of the hostlist to other peers
 connecting on CORE level.
 
address@hidden The HTTP Server
 @node The HTTP Server
 @c %**end of header
 
@@ -4575,6 +4593,7 @@ as a HTTP response and the the server will terminate the 
connection with the
 result code HTTP 200 OK. The connection will be closed immediately if no
 hostlist is available.
 
address@hidden Advertising the URL
 @node Advertising the URL
 @c %**end of header
 
@@ -4583,6 +4602,7 @@ hostlist advertisement is enabled. When a new peer 
connects and has hostlist
 learning enabled, the server sends a GNUNET_MESSAGE_TYPE_HOSTLIST_ADVERTISEMENT
 message to this peer using the CORE service.
 
address@hidden The HOSTLIST client
 @node The HOSTLIST client
 @c %**end of header
 
@@ -4595,6 +4615,7 @@ validation.
 The client supports two modes of operation: download of HELLOs (bootstrapping)
 and learning of URLs.
 
address@hidden Bootstrapping
 @node Bootstrapping
 @c %**end of header
 
@@ -4616,6 +4637,7 @@ full HELLO was downloaded, the HOSTLIST client offers 
this HELLO message to the
 TRANSPORT service for validation. When the download is finished or failed,
 statistical information about the quality of this URL is updated.
 
address@hidden Learning
 @node Learning
 @c %**end of header
 
@@ -4631,6 +4653,7 @@ through successful downloads and number of HELLOs e.g.) 
is discarded. During
 shutdown the list of URLs is saved to a file for persistance and loaded on
 startup. URLs from the configuration file are never discarded.
 
address@hidden Usage
 @node Usage
 @c %**end of header
 

-- 
To stop receiving notification emails like this one, please contact
address@hidden