[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [gnunet] branch master updated: doc: typos
|
From: |
gnunet |
|
Subject: |
[GNUnet-SVN] [gnunet] branch master updated: doc: typos |
|
Date: |
Tue, 26 Jun 2018 22:40:39 +0200 |
This is an automated email from the git hooks/post-receive script.
hernani pushed a commit to branch master
in repository gnunet.
The following commit(s) were added to refs/heads/master by this push:
new d27f60b94 doc: typos
d27f60b94 is described below
commit d27f60b94b3a062877da25cdf7a6b93c4c9cda5a
Author: Hernani Marques <address@hidden>
AuthorDate: Tue Jun 26 22:40:30 2018 +0200
doc: typos
---
doc/documentation/chapters/developer.texi | 174 +++++++++++++++---------------
1 file changed, 87 insertions(+), 87 deletions(-)
diff --git a/doc/documentation/chapters/developer.texi
b/doc/documentation/chapters/developer.texi
index 22b175a3f..f6dd10c7f 100644
--- a/doc/documentation/chapters/developer.texi
+++ b/doc/documentation/chapters/developer.texi
@@ -352,7 +352,7 @@ The DHT and other components of GNUnet
store information in units called 'blocks'. Each block has a type and the
type defines a particular format and how that binary format is to be
linked to a hash code (the key for the DHT and for databases). The block
-library is a wapper around block plugins which provide the necessary
+library is a wrapper around block plugins which provide the necessary
functions for each block type.
@item @file{statistics/} --- statistics service
The statistics service enables associating
@@ -400,7 +400,7 @@ external service to test the local configuration.
Some transports (UDP and WLAN, mostly) have restrictions on the maximum
transfer unit (MTU) for packets. The fragmentation library can be used to
break larger packets into chunks of at most 1k and transmit the resulting
-fragments reliabily (with acknowledgement, retransmission, timeouts,
+fragments reliably (with acknowledgment, retransmission, timeouts,
etc.).
@item @file{transport/} --- transport service
The transport service is responsible for managing the
@@ -425,8 +425,8 @@ the foundation for the testbed service
@item @file{testbed/} --- testbed service
The testbed service is used for creating small or large scale deployments
of GNUnet peers for evaluation of protocols.
-It facilitates peer depolyments on multiple
-hosts (for example, in a cluster) and establishing varous network
+It facilitates peer deployments on multiple
+hosts (for example, in a cluster) and establishing various network
topologies (both underlay and overlay).
@item @file{nse/} --- Network Size Estimation
The network size estimation (NSE) service
@@ -1038,7 +1038,7 @@ if (0 == bar && x != y)
@end example
@noindent
-Note that splitting the @code{if} statement above is debateable as the
+Note that splitting the @code{if} statement above is debatable as the
@code{return x} is a very trivial statement. However, once the logic after
the branch becomes more complicated (and is still identical), the "or"
formulation should be used for sure.
@@ -1173,12 +1173,12 @@ for building applications under UNIX-like systems.
Furthermore we
assume that the build environment is sane and that you are aware of
any implications actions in this process could have.
Instructions here can be seen as notes for developers (an extension to
-the 'HACKING' section in README) as well as package mantainers.
+the 'HACKING' section in README) as well as package maintainers.
@b{Users should rely on the available binary packages.}
We will use Debian as an example Operating System environment. Substitute
-accordingly with your own Ooperating System environment.
+accordingly with your own Operating System environment.
-For the full list of depenendencies, consult the appropriate, up-to-date
+For the full list of dependencies, consult the appropriate, up-to-date
section in the @file{README} file.
First, we need to build or install (depending on your OS) the following
@@ -1442,7 +1442,7 @@ $ gnunet-gns-proxy-setup-ca
@end example
@noindent
-The first generates the default zones, wheras the second setups the GNS
+The first generates the default zones, whereas the second setups the GNS
Certificate Authority with the user's browser. Now, to activate GNS in the
normal DNS resolution process, you need to edit your
@file{/etc/nsswitch.conf} where you should find a line like this:
@@ -1536,7 +1536,7 @@ This range can be customised with the function
similar to @code{GNUNET_TESTING_system_create()} except that it take 2
additional parameters --- the start and end of the port range to use.
-A TESTING system is destroyed with the funciton
+A TESTING system is destroyed with the function
@code{GNUNET_TESTING_system_destory()}. This function takes the handle of
the system and a flag to remove the files created in the directory used
to generate configurations.
@@ -1545,7 +1545,7 @@ A peer is created with the function
@code{GNUNET_TESTING_peer_configure()}. This functions takes the system
handle, a configuration template from which the configuration for the peer
is auto-generated and the index from where the hostkey for the peer has to
-be copied from. When successfull, this function returs a handle to the
+be copied from. When successful, this function returns a handle to the
peer which can be used to start and stop it and to obtain the identity of
the peer. If unsuccessful, a NULL pointer is returned with an error
message. This function handles the generated configuration to have
@@ -1579,7 +1579,7 @@ to the handle to the peer to stop. The callback function
is called with
the given closure when the peer is stopped. Using this function
eliminates blocking while waiting for the peer to terminate.
-An asynchronous peer stop can be cancelled by calling the function
+An asynchronous peer stop can be canceled by calling the function
@code{GNUNET_TESTING_peer_stop_async_cancel()}. Note that calling this
function does not prevent the peer from terminating if the termination
signal has already been sent to it. It does, however, cancels the
@@ -1660,12 +1660,12 @@ simply load the plugin directly.
To help avoid performance regressions, GNUnet uses Gauger. Gauger is a
simple logging tool that allows remote hosts to send performance data to
a central server, where this data can be analyzed and visualized. Gauger
-shows graphs of the repository revisions and the performace data recorded
+shows graphs of the repository revisions and the performance data recorded
for each revision, so sudden performance peaks or drops can be identified
and linked to a specific revision number.
In the case of GNUnet, the buildbots log the performance data obtained
-during the tests after each build. The data can be accesed on GNUnet's
+during the tests after each build. The data can be accessed on GNUnet's
Gauger page.
The menu on the left allows to select either the results of just one
@@ -1678,7 +1678,7 @@ performance evolution across all hosts.
Using Gauger in GNUnet and having the performance of a module tracked over
time is very easy. First of course, the testcase must generate some
consistent metric, which makes sense to have logged. Highly volatile or
-random dependant metrics probably are not ideal candidates for meaningful
+random dependent metrics probably are not ideal candidates for meaningful
regression detection.
To start logging any value, just include @code{gauger.h} in your testcase
@@ -1890,7 +1890,7 @@ random links are to be given
@item @code{GNUNET_TESTBED_TOPOLOGY_SCALE_FREE}: Connects peers in a
topology where peer connectivity follows power law - new peers are
-connected with high probabililty to well connected peers.
+connected with high probability to well connected peers.
@footnote{See Emergence of Scaling in Random Networks. Science 286,
509-512, 1999
(@uref{https://gnunet.org/git/bibliography.git/plain/docs/emergence_of_scaling_in_random_networks__barabasi_albert_science_286__1999.pdf,
pdf})}
@@ -1931,7 +1931,7 @@ ignored for the rest of the topologies.
Topology @code{SCALE_FREE} requires the options
@code{SCALE_FREE_TOPOLOGY_CAP} to be set to the maximum number of peers
which can connect to a peer and @code{SCALE_FREE_TOPOLOGY_M} to be set to
-how many peers a peer should be atleast connected to.
+how many peers a peer should be at least connected to.
Similarly, the topology @code{FROM_FILE} requires the option
@code{OVERLAY_TOPOLOGY_FILE} to contain the path of the file containing
@@ -1977,7 +1977,7 @@ A topology file describes how peers are to be connected.
It should adhere
to the following format for testbed to parse it correctly.
Each line should begin with the target peer id. This should be followed by
-a colon(`:') and origin peer ids seperated by `|'. All spaces except for
+a colon(`:') and origin peer ids separated by `|'. All spaces except for
newline characters are ignored. The API will then try to connect each
origin peer to the target peer.
@@ -2003,9 +2003,9 @@ deemed as crossed after all the peers waiting on it are
notified.
The barriers API provides the following functions:
@itemize @bullet
@item @address@hidden()}:} function to
-initialse a barrier in the experiment
+initialize a barrier in the experiment
@item @address@hidden()}:} function to cancel
-a barrier which has been initialised before
+a barrier which has been initialized before
@item @address@hidden()}:} function to signal
barrier service that the caller has reached a barrier and is waiting for
it to be crossed
@@ -2122,7 +2122,7 @@ the large-scale deployment. We provide you a set of
scripts you can use
to deploy GNUnet on a set of nodes and manage your installation.
Please also check @uref{https://gnunet.org/installation-fedora8-svn} and
address@hidden://gnunet.org/installation-fedora12-svn} to find detailled
address@hidden://gnunet.org/installation-fedora12-svn} to find detailed
instructions how to install GNUnet on a PlanetLab node.
@@ -2148,7 +2148,7 @@ image, installing the buildslave software is quite some
pain. For our
PlanetLab testbed we figured out how to install the buildslave software
best.
address@hidden This is a vvery terrible way to suggest installing software.
address@hidden This is a very terrible way to suggest installing software.
@c FIXME: Is there an official, safer way instead of blind-piping a
@c script?
@c FIXME: Use newer pypi URLs below.
@@ -2354,7 +2354,7 @@ for new developers):
@item CPS-style scheduling (scheduler.c)
@item Program initialization (program.c)
@item Networking (network.c, client.c, server*.c, service.c)
address@hidden message queueing (mq.c)
address@hidden message queuing (mq.c)
@item bandwidth calculations (bandwidth.c)
@item Other OS-related (os*.c, plugin.c, signal.c)
@item Pseudonym management (pseudonym.c)
@@ -2425,7 +2425,7 @@ level to "loglevel". Thus it is possible to run some
processes
with -L DEBUG, for example, and others with -L ERROR to enable specific
settings to diagnose problems with a particular process.
@item Configuration files. Because GNUnet
-service and deamon processes are usually launched by gnunet-arm, it is not
+service and daemon processes are usually launched by gnunet-arm, it is not
possible to pass different custom command line options directly to every
one of them. The options passed to @code{gnunet-arm} only affect
gnunet-arm and not the rest of GNUnet. However, one can specify a
@@ -2717,7 +2717,7 @@ will have
no effect. Other messages (ERROR, WARNING, INFO, etc) will be included.
@item If @code{--enable-logging} is set to @code{verbose}, or
@code{veryverbose} the binary will contain DEBUG messages (still, it will
-be neccessary to run with @command{-L DEBUG} or set the DEBUG config option
+be necessary to run with @command{-L DEBUG} or set the DEBUG config option
to show
them).
@end itemize
@@ -2728,7 +2728,7 @@ If you are a developer:
@item please make sure that you @code{./configure
address@hidden,address@hidden, so you can see DEBUG messages.
@item please remove the @code{#if} statements around @code{GNUNET_log
-(GNUNET_ERROR_TYPE_DEBUG, ...)} lines, to improve the readibility of your
+(GNUNET_ERROR_TYPE_DEBUG, ...)} lines, to improve the readability of your
code.
@end itemize
@@ -2741,7 +2741,7 @@ A suitable configuration could be:
$ export GNUNET_FORCE_LOG="^YOUR_SUBSYSTEM$;;;;DEBUG/;;;;WARNING"
@end example
-Which will behave almost like enabling DEBUG in that subsytem before the
+Which will behave almost like enabling DEBUG in that subsystem before the
change. Of course you can adapt it to your particular needs, this is only
a quick example.
@@ -2952,7 +2952,7 @@ function, which is set to @code{NULL} in most cases, and
the last
parameter is the expected size of the message of this type, usually we
set it to 0 to accept variable size, for special cases the exact size of
the specified message also can be set. In addition, the terminator sign
-depicted as @address@hidden, NULL, 0, address@hidden is set in the last aera.
+depicted as @address@hidden, NULL, 0, address@hidden is set in the last area.
@c ***********************************************************************
@node Server - Process request message
@@ -3002,7 +3002,7 @@ understand the request message, and the processing of
this request would
be terminated.
In comparison to the aforementioned situation, when the argument is equal
-to @code{GNUNET_OK}, the service would continue to process the requst
+to @code{GNUNET_OK}, the service would continue to process the request
message.
@c ***********************************************************************
@@ -3151,7 +3151,7 @@ GNUnet uses SHA-512 for computing one-way hash codes. The
API provides
functions to compute a hash over a block in memory or over a file on disk.
The crypto API also provides functions for randomizing a block of memory,
-obtaining a single random number and for generating a permuation of the
+obtaining a single random number and for generating a permutation of the
numbers 0 to n-1. Random number generation distinguishes between WEAK and
STRONG random number quality; WEAK random numbers are pseudo-random
whereas STRONG random numbers use entropy gathered from the operating
@@ -3230,7 +3230,7 @@ message.
Consider the following simple message, with the body consisting of a
single number value.
address@hidden why the empy code function?
address@hidden why the empty code function?
@code{}
@example
@@ -3505,7 +3505,7 @@ or in some other transient data structure and thus having
the hash map
keep a pointer to @code{key} would not work. Only the key inside of
@code{val} has the same lifetime as the entry in the map (this must of
course be checked as well). Naturally, @code{val->key} must be
-intiialized before the @code{put} call. Once all @code{put} calls have
+initialized before the @code{put} call. Once all @code{put} calls have
been converted and double-checked, you can change the call to create the
hash map from
@@ -3893,7 +3893,7 @@ The goal of transport-level address validation is to
minimize the chances
of a successful man-in-the-middle attack against GNUnet peers on the
transport level. Such an attack would not allow the adversary to decrypt
the P2P transmissions, but a successful attacker could at least measure
-traffic volumes and latencies (raising the adversaries capablities by
+traffic volumes and latencies (raising the adversaries capabilities by
those of a global passive adversary in the worst case). The scenarios we
are concerned about is an attacker, Mallory, giving a @code{HELLO} to
Alice that claims to be for Bob, but contains Mallory's IP address
@@ -4019,7 +4019,7 @@ connected peers, but they are sent about other knowns
peers within the
to each other about their appropriate other neighbors. They also gossip
about the newly connected peer to previously
connected neighbors. In order to keep the routing tables up to date,
-disconnect notifications are propogated as gossip as well (because
+disconnect notifications are propagated as gossip as well (because
disconnects may not be sent/received, timeouts are also used remove
stagnant routing table entries).
@@ -4210,7 +4210,7 @@ to send and receive messages.
We have measured the performance of the UDP, TCP and SMTP transport layer
directly and when used from an application using the GNUnet core.
-Measureing just the transport layer gives the better view of the actual
+Measuring just the transport layer gives the better view of the actual
overhead of the protocol, whereas evaluating the transport from the
application puts the overhead into perspective from a practical point of
view.
@@ -4230,7 +4230,7 @@ wire have no impact on the timings. n messages were sent
sequentially over
the transport layer, sending message i+1 after the i-th message was
received. All messages were sent over the same connection and the time to
establish the connection was not taken into account since this overhead is
-miniscule in practice --- as long as a connection is used for a
+minuscule in practice --- as long as a connection is used for a
significant number of messages.
@multitable @columnfractions .20 .15 .15 .15 .15 .15
@@ -4261,9 +4261,9 @@ given time-bounds. For this benchmark we report the
message loss after
allowing t time for sending m messages. If messages were not sent (or
received) after an overall timeout of t, they were considered lost. The
benchmark was performed using two Xeon 2 GHZ machines running RedHat 8.0
-with sendmail. The machines were connected with a direct 100 MBit ethernet
+with sendmail. The machines were connected with a direct 100 MBit Ethernet
connection.@ Figures udp1200, tcp1200 and smtp-MTUs show that the
-throughput for messages of size 1,200 octects is 2,343 kbps, 3,310 kbps
+throughput for messages of size 1,200 octets is 2,343 kbps, 3,310 kbps
and 6 kbps for UDP, TCP and SMTP respectively. The high per-message
overhead of SMTP can be improved by increasing the MTU, for example, an
MTU of 12,000 octets improves the throughput to 13 kbps as figure
@@ -4308,7 +4308,7 @@ installed).
For instructions about how to install the libraries you should
check out the BlueZ site
(@uref{http://www.bluez.org/, http://www.bluez.org}). If you don't know if
-you have the necesarry libraries, don't worry, just run the GNUnet
+you have the necessary libraries, don't worry, just run the GNUnet
configure script and you will be able to see a notification at the end
which will warn you if you don't have the necessary libraries.
@@ -4336,7 +4336,7 @@ helper binary used on GNU/Linux:
@itemize @bullet
@item it verifies if the name corresponds to a Bluetooth interface name
address@hidden it verifies if the iterface is up (if it is not, it tries to
bring
address@hidden it verifies if the interface is up (if it is not, it tries to
bring
it up)
@item it tries to enable the page and inquiry scan in order to make the
device discoverable and to accept incoming connection requests
@@ -4377,7 +4377,7 @@ Bluetooth address has the form 00:00:00:00:00:00 it means
that there is
something wrong with the D-Bus daemon or with the Bluetooth daemon. Use
@code{bluetoothd} tool to see the logs
address@hidden @code{sdptool} can be used to control and interogate SDP servers.
address@hidden @code{sdptool} can be used to control and interrogate SDP
servers.
If you encounter problems regarding the SDP server (like the SDP server is
down) you should check out if the D-Bus daemon is running correctly and to
see if the Bluetooth daemon started correctly(use @code{bluetoothd} tool).
@@ -4464,11 +4464,11 @@ then start sending data for benchmarking.
On Windows you cannot test the plugin functionality using two Bluetooth
devices from the same machine because after you install the drivers there
will occur some conflicts between the Bluetooth stacks. (At least that is
-what happend on my machine : I wasn't able to use the Bluesoleil stack and
+what happened on my machine : I wasn't able to use the Bluesoleil stack and
the WINDCOMM one in the same time).
If you have two different machines and your configuration files are good
-you can use the same scenario presented on the begining of this section.
+you can use the same scenario presented on the beginning of this section.
Another way to test the plugin functionality is to create your own
application which will use the GNUnet framework with the Bluetooth
@@ -4483,8 +4483,8 @@ This page describes the implementation of the Bluetooth
transport plugin.
First I want to remind you that the Bluetooth transport plugin uses
virtually the same code as the WLAN plugin and only the helper binary is
different. Also the scope of the helper binary from the Bluetooth
-transport plugin is the same as the one used for the wlan transport
-plugin: it acceses the interface and then it forwards traffic in both
+transport plugin is the same as the one used for the WLAN transport
+plugin: it accesses the interface and then it forwards traffic in both
directions between the Bluetooth interface and stdin/stdout of the
process involved.
@@ -4525,8 +4525,8 @@ Bluetooth interface) and is separated in two stages:
@subsubsection THE INITIALIZATION
@itemize @bullet
address@hidden first, it checks if we have root privilegies
-(@emph{Remember that we need to have root privilegies in order to be able
address@hidden first, it checks if we have root privileges
+(@emph{Remember that we need to have root privileges in order to be able
to bring the interface up if it is down or to change its state.}).
@item second, it verifies if the interface with the given name exists.
@@ -4551,7 +4551,7 @@ discoverable
devices to get the port on which this device is listening on)
@end itemize
address@hidden drops the root privilegies
address@hidden drops the root privileges
@strong{If the interface is not a Bluetooth interface the helper exits
with a suitable error}
@@ -4596,7 +4596,7 @@ the STDOUT file descriptor, then we write to STDOUT the
message from the
@emph{write_std} buffer.
To find out on which port a device is listening on we connect to the local
-SDP server and searche the registered service for that device.
+SDP server and search the registered service for that device.
@emph{You should be aware of the fact that if the device fails to connect
to another one when trying to send a message it will attempt one more
@@ -4659,17 +4659,17 @@ For Windows I decided to use the Microsoft Bluetooth
stack which has the
advantage of coming standard from Windows XP SP2. The main disadvantage is
that it only supports the RFCOMM protocol so we will not be able to have
a low level control over the Bluetooth device. Therefore it is the user
-responsability to check if the device is up and in the discoverable mode.
+responsibility to check if the device is up and in the discoverable mode.
Also there are no tools which could be used for debugging in order to read
the data coming from and going to a Bluetooth device, which obviously
hindered my work. Another thing that slowed down the implementation of the
-plugin (besides that I wasn't too accomodated with the win32 API) was that
+plugin (besides that I wasn't too accommodated with the win32 API) was that
there were some bugs on MinGW regarding the Bluetooth. Now they are solved
but you should keep in mind that you should have the latest updates
(especially the @emph{ws2bth} header).
Besides the fact that it uses the Windows Sockets, the Windows
-implemenation follows the same principles as the GNU/Linux one:
+implementation follows the same principles as the GNU/Linux one:
@itemize @bullet
@item It has a initalization part where it initializes the
@@ -4714,7 +4714,7 @@ broadcast messages. When it receives a broadcast message
it will skip it.
@item Implement the broadcast functionality on Windows @emph{(currently
working on)}
@item Implement a testcase for the helper :@ @emph{The testcase
-consists of a program which emaluates the plugin and uses the helper. It
+consists of a program which emulates the plugin and uses the helper. It
will simulate connections, disconnections and data transfers.}
@end itemize
@@ -4902,7 +4902,7 @@ peers connecting, peers disconnecting and incoming
messages) and send
messages to connected peers using
@code{GNUNET_CORE_notify_transmit_ready}. Note that applications must
cancel pending transmission requests if they receive a disconnect event
-for a peer that had a transmission pending; furthermore, queueing more
+for a peer that had a transmission pending; furthermore, queuing more
than one transmission request per peer per application using the
service is not permitted.
@@ -5197,11 +5197,11 @@ The API is heavily base on the CORE API.
CADET delivers messages to other peers in "channels".
A channel is a permanent connection defined by a destination peer
(identified by its public key) and a port number.
-Internally, CADET tunnels all channels towards a destiantion peer
+Internally, CADET tunnels all channels towards a destination peer
using one session key and relays the data on multiple "connections",
independent from the channels.
-Each channel has optional paramenters, the most important being the
+Each channel has optional parameters, the most important being the
reliability flag.
Should a message get lost on TRANSPORT/CORE level, if a channel is
created with as reliable, CADET will retransmit the lost message and
@@ -5242,15 +5242,15 @@ case. To be alerted when a channel is online, a client
can call
@code{GNUNET_CADET_notify_transmit_ready} immediately after
@code{GNUNET_CADET_create_channel}. When the callback is activated, it
means that the channel is online. The callback can give 0 bytes to CADET
-if no message is to be sent, this is ok.
+if no message is to be sent, this is OK.
If a transmission was requested but before the callback fires it is no
-longer needed, it can be cancelled with
+longer needed, it can be canceled with
@code{GNUNET_CADET_notify_transmit_ready_cancel}, which uses the handle
given back by @code{GNUNET_CADET_notify_transmit_ready}.
As in the case of CORE, only one message can be requested at a time: a
client must not call @code{GNUNET_CADET_notify_transmit_ready} again until
-the callback is called or the request is cancelled.
+the callback is called or the request is canceled.
When a channel is no longer needed, a client can call
@code{GNUNET_CADET_channel_destroy} to get rid of it.
@@ -5298,10 +5298,10 @@ all of the details can be found in this technical
report.
@subsection Motivation
-Some subsytems, like DHT, need to know the size of the GNUnet network to
+Some subsystems, like DHT, need to know the size of the GNUnet network to
optimize some parameters of their own protocol. The decentralized nature
of GNUnet makes efficient and securely counting the exact number of peers
-infeasable. Although there are several decentralized algorithms to count
+infeasible. Although there are several decentralized algorithms to count
the number of peers in a system, so far there is none to do so securely.
Other protocols may allow any malicious peer to manipulate the final
result or to take advantage of the system to perform
@@ -5323,7 +5323,7 @@ GNUnet's NSE protocol avoids these drawbacks.
The NSE subsystem is designed to be resilient against these attacks.
It uses @uref{http://en.wikipedia.org/wiki/Proof-of-work_system, proofs of
work}
to prevent one peer from impersonating a large number of participants,
-which would otherwise allow an adversary to artifically inflate the
+which would otherwise allow an adversary to artificially inflate the
estimate.
The DoS protection comes from the time-based nature of the protocol:
the estimates are calculated periodically and out-of-time traffic is
@@ -5385,7 +5385,7 @@ to all the other peers, who will calculate the estimate
from it.
The target value itself is generated by hashing the current time, rounded
down to an agreed value. If the rounding amount is 1h (default) and the
time is 12:34:56, the time to hash would be 12:00:00. The process is
-repeated each rouning amount (in this example would be every hour).
+repeated each rounding amount (in this example would be every hour).
Every repetition is called a round.
@node Timing
@@ -5397,12 +5397,12 @@ its ID all at one. Once each peer has the target random
value, it
compares its own ID to the target and calculates the hypothetical size of
the network if that peer were to be the closest.
Then it compares the hypothetical size with the estimate from the previous
-rounds. For each value there is an assiciated point in the period,
+rounds. For each value there is an associated point in the period,
let's call it "broadcast time". If its own hypothetical estimate
is the same as the previous global estimate, its "broadcast time" will be
in the middle of the round. If its bigger it will be earlier and if its
smaller (the most likely case) it will be later. This ensures that the
-peers closests to the target value start broadcasting their ID the first.
+peers closest to the target value start broadcasting their ID the first.
@node Controlled Flooding
@subsubsection Controlled Flooding
@@ -5415,7 +5415,7 @@ with a message containing the better value. Then it
checks a proof of
work that must be included in the incoming message, to ensure that the
other peer's ID is not made up (otherwise a malicious peer could claim to
have an ID of exactly the target value every round). Once validated, it
-compares the brodcast time of the received value with the current time
+compares the broadcast time of the received value with the current time
and if it's not too early, sends the received value to its neighbors.
Otherwise it stores the value until the correct broadcast time comes.
This prevents unnecessary traffic of sub-optimal values, since a better
@@ -5429,7 +5429,7 @@ to the neighbors.
@c %**end of header
Once the closest ID has been spread across the network each peer gets the
-exact distance betweed this ID and the target value of the round and
+exact distance between this ID and the target value of the round and
calculates the estimate with a mathematical formula described in the tech
report. The estimate generated with this method for a single round is not
very precise. Remember the case of the example, where the only peer is the
@@ -5477,7 +5477,7 @@ The callback provides two values: the average and the
@uref{http://en.wikipedia.org/wiki/Standard_deviation, standard deviation}
of the last 64 rounds. The values provided by the callback function are
logarithmic, this means that the real estimate numbers can be obtained by
-calculating 2 to the power of the given value (2average). From a
+calculating 2 to the power of the given value (average). From a
statistics point of view this means that:
@itemize @bullet
@@ -5503,7 +5503,7 @@ size is between one third and three times the estimate.
This can of
course vary with network conditions.
Thus, applications may want to also consider the provided standard
deviation value, not only the average (in particular, if the standard
-veriation is very high, the average maybe meaningless: the network size is
+variation is very high, the average maybe meaningless: the network size is
changing rapidly).
@node libgnunetnse - Examples
@@ -5584,7 +5584,7 @@ At the beginning of each round the peer does the
following:
it has a better message in the "next round" slot which came early in the
previous round)
@item calculates, based on the stored round message (own or received) when
-to stard flooding it to its neighbors
+to start flooding it to its neighbors
@end itemize
Upon receiving a message the peer checks the validity of the message
@@ -6085,7 +6085,7 @@ convenience API to do just that. Use
@code{GNUNET_IDENTITY_ego_lookup} to
lookup a single ego by name. Note that this is the user's name for the
ego, not the service function. The resulting ego will be returned via a
callback and will only be valid during that callback. The operation can
-be cancelled via @code{GNUNET_IDENTITY_ego_lookup_cancel}
+be canceled via @code{GNUNET_IDENTITY_ego_lookup_cancel}
(cancellation is only legal before the callback is invoked).
@node Associating egos with service functions
@@ -6658,7 +6658,7 @@ The size of an element's data is limited to around 62 KB.
Sets created by a local client can be modified and reused for multiple
operations. As each set operation requires potentially expensive special
-auxilliary data to be computed for each element of a set, a set can only
+auxiliary data to be computed for each element of a set, a set can only
participate in one type of set operation (i.e. union or intersection).
The type of a set is determined upon its creation.
If a the elements of a set are needed for an operation of a different
@@ -6778,7 +6778,7 @@ until the client calls @code{GNUNET_SET_commit}
@c %**end of header
To create symmetry between the two ways of starting a set operation
-(accepting and nitiating it), the operation handles returned by
+(accepting and initiating it), the operation handles returned by
@code{GNUNET_SET_accept} and @code{GNUNET_SET_prepare} do not yet have a
set to operate on, thus they can not do any work yet.
@@ -6938,7 +6938,7 @@ It then checks if the set size of the sender and the XOR
over the keys
match what is left of his own set. If they do, he sends a
@code{GNUNET_MESSAGE_TYPE_SET_INTERSECTION_P2P_DONE} back to indicate
that the latest set is the final result.
-Otherwise, the receiver starts another Bloom fitler exchange, except
+Otherwise, the receiver starts another Bloom filter exchange, except
this time as the sender.
@node Salt
@@ -6946,7 +6946,7 @@ this time as the sender.
@c %**end of header
-Bloomfilter operations are probablistic: With some non-zero probability
+Bloomfilter operations are probabilistic: With some non-zero probability
the test may incorrectly say an element is in the set, even though it is
not.
@@ -6999,7 +6999,7 @@ message. If the IBF fully decodes, the peer responds with
a
GNUNET_MESSAGE_TYPE_SET_UNION_P2P_DONE message instead of another
GNUNET_MESSAGE_TYPE_SET_UNION_P2P_IBF.
-All Bloom filter operations use a salt to mingle keys before hasing them
+All Bloom filter operations use a salt to mingle keys before hashing them
into buckets, such that future iterations have a fresh chance of
succeeding if they failed due to collisions before.
@@ -7557,7 +7557,7 @@ already knows more than about a thousand blocks may need
to send
several of these messages. Naturally, the client should transmit these
messages as quickly as possible after the original GET request such that
the DHT can filter those results in the network early on. Naturally, as
-these messages are sent after the original request, it is conceivalbe
+these messages are sent after the original request, it is conceivable
that the DHT service may return blocks that match those already known
to the client anyway.
@@ -7670,7 +7670,7 @@ duplicate results) and when they obtain a matching,
non-filtered response
a @code{struct PeerResultMessage} of type
@code{GNUNET_MESSAGE_TYPE_DHT_P2P_RESULT} is forwarded to the previous
hop.
-Whenver a result is forwarded, the block plugin is used to update the
+Whenever a result is forwarded, the block plugin is used to update the
Bloom filter accordingly, to ensure that the same result is never
forwarded more than once.
The DHT service may also cache forwarded results locally if the
@@ -7737,7 +7737,7 @@ record types.
@c %**end of header
-The GNS API itself is extremely simple. Clients first connec to the
+The GNS API itself is extremely simple. Clients first connect to the
GNS service using @code{GNUNET_GNS_connect}.
They can then perform lookups using @code{GNUNET_GNS_lookup} or cancel
pending lookups using @code{GNUNET_GNS_lookup_cancel}.
@@ -7786,9 +7786,9 @@ their respective zones can automatically be learned and
added to the
the shorten zone. If NULL is passed, shortening is disabled.
@item proc This argument identifies
the function to call with the result. It is given proc_cls, the number of
-records found (possilby zero) and the array of the records as arguments.
+records found (possibly zero) and the array of the records as arguments.
proc will only be called once. After proc,> has been called, the lookup
-must no longer be cancelled.
+must no longer be canceled.
@item proc_cls The closure for proc.
@end table
@@ -7943,7 +7943,7 @@ This is merely one method for how we can obtain GNS
queries.
It is also possible to change @code{resolv.conf} to point to a machine
running @code{gnunet-dns2gns} or to modify libc's name system switch
(NSS) configuration to include a GNS resolution plugin.
-The method described in this chaper is more of a last-ditch catch-all
+The method described in this chapter is more of a last-ditch catch-all
approach.
@code{gnunet-service-dns} enables intercepting DNS traffic using policy
@@ -8111,8 +8111,8 @@ This returns the handle required for all other operations
on the
NAMECACHE. Using @code{GNUNET_NAMECACHE_block_cache} clients can insert a
block into the cache.
@code{GNUNET_NAMECACHE_lookup_block} can be used to lookup blocks that
-were stored in the NAMECACHE. Both operations can be cancelled using
address@hidden Note that cancelling a
+were stored in the NAMECACHE. Both operations can be canceled using
address@hidden Note that canceling a
@code{GNUNET_NAMECACHE_block_cache} operation can result in the block
being stored in the NAMECACHE --- or not. Cancellation primarily ensures
that the continuation function with the result of the operation will no
@@ -8299,7 +8299,7 @@ revocations.
@code{GNUNET_REVOCATION_query} is used to check if a given ECDSA public
key has been revoked.
The given callback will be invoked with the result of the check.
-The query can be cancelled using @code{GNUNET_REVOCATION_query_cancel} on
+The query can be canceled using @code{GNUNET_REVOCATION_query_cancel} on
the return value.
@node Preparing revocations
@@ -8477,7 +8477,7 @@ metadata describing the content of the namespace.
Instead of the name of the identifier for a potential update, it contains
the identifier for the root of the namespace.
The URI should always be empty. The @code{SBlock} is signed with the
-content provder's RSA private key (just like any other SBlock). Peers
+content provider's RSA private key (just like any other SBlock). Peers
can search for @code{SBlock}s in order to find out more about a namespace.
@node KSBlocks
@@ -8800,5 +8800,5 @@ so please make sure that endpoints are unambiguous.
@subsection Endpoint documentation
This is WIP. Endpoints should be documented appropriately.
-Perferably using annotations.
+Preferably using annotations.
--
To stop receiving notification emails like this one, please contact
address@hidden
- [GNUnet-SVN] [gnunet] branch master updated: doc: typos,
gnunet <=