diff options
author | Hernani Marques <hernani@ccc-ch.ch> | 2018-06-26 22:40:30 +0200 |
---|---|---|
committer | Hernani Marques <hernani@ccc-ch.ch> | 2018-06-26 22:40:30 +0200 |
commit | d27f60b94b3a062877da25cdf7a6b93c4c9cda5a (patch) | |
tree | 50bc609bae0a204c4e6f77ad10b47b60eb646afa | |
parent | 3bb2a26da20d649189acf255faf685f2f3ac79d6 (diff) | |
download | gnunet-d27f60b94b3a062877da25cdf7a6b93c4c9cda5a.tar.gz gnunet-d27f60b94b3a062877da25cdf7a6b93c4c9cda5a.zip |
doc: typos
-rw-r--r-- | doc/documentation/chapters/developer.texi | 174 |
1 files 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 | |||
352 | store information in units called 'blocks'. Each block has a type and the | 352 | store information in units called 'blocks'. Each block has a type and the |
353 | type defines a particular format and how that binary format is to be | 353 | type defines a particular format and how that binary format is to be |
354 | linked to a hash code (the key for the DHT and for databases). The block | 354 | linked to a hash code (the key for the DHT and for databases). The block |
355 | library is a wapper around block plugins which provide the necessary | 355 | library is a wrapper around block plugins which provide the necessary |
356 | functions for each block type. | 356 | functions for each block type. |
357 | @item @file{statistics/} --- statistics service | 357 | @item @file{statistics/} --- statistics service |
358 | The statistics service enables associating | 358 | The statistics service enables associating |
@@ -400,7 +400,7 @@ external service to test the local configuration. | |||
400 | Some transports (UDP and WLAN, mostly) have restrictions on the maximum | 400 | Some transports (UDP and WLAN, mostly) have restrictions on the maximum |
401 | transfer unit (MTU) for packets. The fragmentation library can be used to | 401 | transfer unit (MTU) for packets. The fragmentation library can be used to |
402 | break larger packets into chunks of at most 1k and transmit the resulting | 402 | break larger packets into chunks of at most 1k and transmit the resulting |
403 | fragments reliabily (with acknowledgement, retransmission, timeouts, | 403 | fragments reliably (with acknowledgment, retransmission, timeouts, |
404 | etc.). | 404 | etc.). |
405 | @item @file{transport/} --- transport service | 405 | @item @file{transport/} --- transport service |
406 | The transport service is responsible for managing the | 406 | The transport service is responsible for managing the |
@@ -425,8 +425,8 @@ the foundation for the testbed service | |||
425 | @item @file{testbed/} --- testbed service | 425 | @item @file{testbed/} --- testbed service |
426 | The testbed service is used for creating small or large scale deployments | 426 | The testbed service is used for creating small or large scale deployments |
427 | of GNUnet peers for evaluation of protocols. | 427 | of GNUnet peers for evaluation of protocols. |
428 | It facilitates peer depolyments on multiple | 428 | It facilitates peer deployments on multiple |
429 | hosts (for example, in a cluster) and establishing varous network | 429 | hosts (for example, in a cluster) and establishing various network |
430 | topologies (both underlay and overlay). | 430 | topologies (both underlay and overlay). |
431 | @item @file{nse/} --- Network Size Estimation | 431 | @item @file{nse/} --- Network Size Estimation |
432 | The network size estimation (NSE) service | 432 | The network size estimation (NSE) service |
@@ -1038,7 +1038,7 @@ if (0 == bar && x != y) | |||
1038 | @end example | 1038 | @end example |
1039 | 1039 | ||
1040 | @noindent | 1040 | @noindent |
1041 | Note that splitting the @code{if} statement above is debateable as the | 1041 | Note that splitting the @code{if} statement above is debatable as the |
1042 | @code{return x} is a very trivial statement. However, once the logic after | 1042 | @code{return x} is a very trivial statement. However, once the logic after |
1043 | the branch becomes more complicated (and is still identical), the "or" | 1043 | the branch becomes more complicated (and is still identical), the "or" |
1044 | formulation should be used for sure. | 1044 | formulation should be used for sure. |
@@ -1173,12 +1173,12 @@ for building applications under UNIX-like systems. Furthermore we | |||
1173 | assume that the build environment is sane and that you are aware of | 1173 | assume that the build environment is sane and that you are aware of |
1174 | any implications actions in this process could have. | 1174 | any implications actions in this process could have. |
1175 | Instructions here can be seen as notes for developers (an extension to | 1175 | Instructions here can be seen as notes for developers (an extension to |
1176 | the 'HACKING' section in README) as well as package mantainers. | 1176 | the 'HACKING' section in README) as well as package maintainers. |
1177 | @b{Users should rely on the available binary packages.} | 1177 | @b{Users should rely on the available binary packages.} |
1178 | We will use Debian as an example Operating System environment. Substitute | 1178 | We will use Debian as an example Operating System environment. Substitute |
1179 | accordingly with your own Ooperating System environment. | 1179 | accordingly with your own Operating System environment. |
1180 | 1180 | ||
1181 | For the full list of depenendencies, consult the appropriate, up-to-date | 1181 | For the full list of dependencies, consult the appropriate, up-to-date |
1182 | section in the @file{README} file. | 1182 | section in the @file{README} file. |
1183 | 1183 | ||
1184 | First, we need to build or install (depending on your OS) the following | 1184 | First, we need to build or install (depending on your OS) the following |
@@ -1442,7 +1442,7 @@ $ gnunet-gns-proxy-setup-ca | |||
1442 | @end example | 1442 | @end example |
1443 | 1443 | ||
1444 | @noindent | 1444 | @noindent |
1445 | The first generates the default zones, wheras the second setups the GNS | 1445 | The first generates the default zones, whereas the second setups the GNS |
1446 | Certificate Authority with the user's browser. Now, to activate GNS in the | 1446 | Certificate Authority with the user's browser. Now, to activate GNS in the |
1447 | normal DNS resolution process, you need to edit your | 1447 | normal DNS resolution process, you need to edit your |
1448 | @file{/etc/nsswitch.conf} where you should find a line like this: | 1448 | @file{/etc/nsswitch.conf} where you should find a line like this: |
@@ -1536,7 +1536,7 @@ This range can be customised with the function | |||
1536 | similar to @code{GNUNET_TESTING_system_create()} except that it take 2 | 1536 | similar to @code{GNUNET_TESTING_system_create()} except that it take 2 |
1537 | additional parameters --- the start and end of the port range to use. | 1537 | additional parameters --- the start and end of the port range to use. |
1538 | 1538 | ||
1539 | A TESTING system is destroyed with the funciton | 1539 | A TESTING system is destroyed with the function |
1540 | @code{GNUNET_TESTING_system_destory()}. This function takes the handle of | 1540 | @code{GNUNET_TESTING_system_destory()}. This function takes the handle of |
1541 | the system and a flag to remove the files created in the directory used | 1541 | the system and a flag to remove the files created in the directory used |
1542 | to generate configurations. | 1542 | to generate configurations. |
@@ -1545,7 +1545,7 @@ A peer is created with the function | |||
1545 | @code{GNUNET_TESTING_peer_configure()}. This functions takes the system | 1545 | @code{GNUNET_TESTING_peer_configure()}. This functions takes the system |
1546 | handle, a configuration template from which the configuration for the peer | 1546 | handle, a configuration template from which the configuration for the peer |
1547 | is auto-generated and the index from where the hostkey for the peer has to | 1547 | is auto-generated and the index from where the hostkey for the peer has to |
1548 | be copied from. When successfull, this function returs a handle to the | 1548 | be copied from. When successful, this function returns a handle to the |
1549 | peer which can be used to start and stop it and to obtain the identity of | 1549 | peer which can be used to start and stop it and to obtain the identity of |
1550 | the peer. If unsuccessful, a NULL pointer is returned with an error | 1550 | the peer. If unsuccessful, a NULL pointer is returned with an error |
1551 | message. This function handles the generated configuration to have | 1551 | 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 | |||
1579 | the given closure when the peer is stopped. Using this function | 1579 | the given closure when the peer is stopped. Using this function |
1580 | eliminates blocking while waiting for the peer to terminate. | 1580 | eliminates blocking while waiting for the peer to terminate. |
1581 | 1581 | ||
1582 | An asynchronous peer stop can be cancelled by calling the function | 1582 | An asynchronous peer stop can be canceled by calling the function |
1583 | @code{GNUNET_TESTING_peer_stop_async_cancel()}. Note that calling this | 1583 | @code{GNUNET_TESTING_peer_stop_async_cancel()}. Note that calling this |
1584 | function does not prevent the peer from terminating if the termination | 1584 | function does not prevent the peer from terminating if the termination |
1585 | signal has already been sent to it. It does, however, cancels the | 1585 | signal has already been sent to it. It does, however, cancels the |
@@ -1660,12 +1660,12 @@ simply load the plugin directly. | |||
1660 | To help avoid performance regressions, GNUnet uses Gauger. Gauger is a | 1660 | To help avoid performance regressions, GNUnet uses Gauger. Gauger is a |
1661 | simple logging tool that allows remote hosts to send performance data to | 1661 | simple logging tool that allows remote hosts to send performance data to |
1662 | a central server, where this data can be analyzed and visualized. Gauger | 1662 | a central server, where this data can be analyzed and visualized. Gauger |
1663 | shows graphs of the repository revisions and the performace data recorded | 1663 | shows graphs of the repository revisions and the performance data recorded |
1664 | for each revision, so sudden performance peaks or drops can be identified | 1664 | for each revision, so sudden performance peaks or drops can be identified |
1665 | and linked to a specific revision number. | 1665 | and linked to a specific revision number. |
1666 | 1666 | ||
1667 | In the case of GNUnet, the buildbots log the performance data obtained | 1667 | In the case of GNUnet, the buildbots log the performance data obtained |
1668 | during the tests after each build. The data can be accesed on GNUnet's | 1668 | during the tests after each build. The data can be accessed on GNUnet's |
1669 | Gauger page. | 1669 | Gauger page. |
1670 | 1670 | ||
1671 | The menu on the left allows to select either the results of just one | 1671 | The menu on the left allows to select either the results of just one |
@@ -1678,7 +1678,7 @@ performance evolution across all hosts. | |||
1678 | Using Gauger in GNUnet and having the performance of a module tracked over | 1678 | Using Gauger in GNUnet and having the performance of a module tracked over |
1679 | time is very easy. First of course, the testcase must generate some | 1679 | time is very easy. First of course, the testcase must generate some |
1680 | consistent metric, which makes sense to have logged. Highly volatile or | 1680 | consistent metric, which makes sense to have logged. Highly volatile or |
1681 | random dependant metrics probably are not ideal candidates for meaningful | 1681 | random dependent metrics probably are not ideal candidates for meaningful |
1682 | regression detection. | 1682 | regression detection. |
1683 | 1683 | ||
1684 | To start logging any value, just include @code{gauger.h} in your testcase | 1684 | To start logging any value, just include @code{gauger.h} in your testcase |
@@ -1890,7 +1890,7 @@ random links are to be given | |||
1890 | 1890 | ||
1891 | @item @code{GNUNET_TESTBED_TOPOLOGY_SCALE_FREE}: Connects peers in a | 1891 | @item @code{GNUNET_TESTBED_TOPOLOGY_SCALE_FREE}: Connects peers in a |
1892 | topology where peer connectivity follows power law - new peers are | 1892 | topology where peer connectivity follows power law - new peers are |
1893 | connected with high probabililty to well connected peers. | 1893 | connected with high probability to well connected peers. |
1894 | @footnote{See Emergence of Scaling in Random Networks. Science 286, | 1894 | @footnote{See Emergence of Scaling in Random Networks. Science 286, |
1895 | 509-512, 1999 | 1895 | 509-512, 1999 |
1896 | (@uref{https://gnunet.org/git/bibliography.git/plain/docs/emergence_of_scaling_in_random_networks__barabasi_albert_science_286__1999.pdf, pdf})} | 1896 | (@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. | |||
1931 | Topology @code{SCALE_FREE} requires the options | 1931 | Topology @code{SCALE_FREE} requires the options |
1932 | @code{SCALE_FREE_TOPOLOGY_CAP} to be set to the maximum number of peers | 1932 | @code{SCALE_FREE_TOPOLOGY_CAP} to be set to the maximum number of peers |
1933 | which can connect to a peer and @code{SCALE_FREE_TOPOLOGY_M} to be set to | 1933 | which can connect to a peer and @code{SCALE_FREE_TOPOLOGY_M} to be set to |
1934 | how many peers a peer should be atleast connected to. | 1934 | how many peers a peer should be at least connected to. |
1935 | 1935 | ||
1936 | Similarly, the topology @code{FROM_FILE} requires the option | 1936 | Similarly, the topology @code{FROM_FILE} requires the option |
1937 | @code{OVERLAY_TOPOLOGY_FILE} to contain the path of the file containing | 1937 | @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 | |||
1977 | to the following format for testbed to parse it correctly. | 1977 | to the following format for testbed to parse it correctly. |
1978 | 1978 | ||
1979 | Each line should begin with the target peer id. This should be followed by | 1979 | Each line should begin with the target peer id. This should be followed by |
1980 | a colon(`:') and origin peer ids seperated by `|'. All spaces except for | 1980 | a colon(`:') and origin peer ids separated by `|'. All spaces except for |
1981 | newline characters are ignored. The API will then try to connect each | 1981 | newline characters are ignored. The API will then try to connect each |
1982 | origin peer to the target peer. | 1982 | origin peer to the target peer. |
1983 | 1983 | ||
@@ -2003,9 +2003,9 @@ deemed as crossed after all the peers waiting on it are notified. | |||
2003 | The barriers API provides the following functions: | 2003 | The barriers API provides the following functions: |
2004 | @itemize @bullet | 2004 | @itemize @bullet |
2005 | @item @strong{@code{GNUNET_TESTBED_barrier_init()}:} function to | 2005 | @item @strong{@code{GNUNET_TESTBED_barrier_init()}:} function to |
2006 | initialse a barrier in the experiment | 2006 | initialize a barrier in the experiment |
2007 | @item @strong{@code{GNUNET_TESTBED_barrier_cancel()}:} function to cancel | 2007 | @item @strong{@code{GNUNET_TESTBED_barrier_cancel()}:} function to cancel |
2008 | a barrier which has been initialised before | 2008 | a barrier which has been initialized before |
2009 | @item @strong{@code{GNUNET_TESTBED_barrier_wait()}:} function to signal | 2009 | @item @strong{@code{GNUNET_TESTBED_barrier_wait()}:} function to signal |
2010 | barrier service that the caller has reached a barrier and is waiting for | 2010 | barrier service that the caller has reached a barrier and is waiting for |
2011 | it to be crossed | 2011 | it to be crossed |
@@ -2122,7 +2122,7 @@ the large-scale deployment. We provide you a set of scripts you can use | |||
2122 | to deploy GNUnet on a set of nodes and manage your installation. | 2122 | to deploy GNUnet on a set of nodes and manage your installation. |
2123 | 2123 | ||
2124 | Please also check @uref{https://gnunet.org/installation-fedora8-svn} and | 2124 | Please also check @uref{https://gnunet.org/installation-fedora8-svn} and |
2125 | @uref{https://gnunet.org/installation-fedora12-svn} to find detailled | 2125 | @uref{https://gnunet.org/installation-fedora12-svn} to find detailed |
2126 | instructions how to install GNUnet on a PlanetLab node. | 2126 | instructions how to install GNUnet on a PlanetLab node. |
2127 | 2127 | ||
2128 | 2128 | ||
@@ -2148,7 +2148,7 @@ image, installing the buildslave software is quite some pain. For our | |||
2148 | PlanetLab testbed we figured out how to install the buildslave software | 2148 | PlanetLab testbed we figured out how to install the buildslave software |
2149 | best. | 2149 | best. |
2150 | 2150 | ||
2151 | @c This is a vvery terrible way to suggest installing software. | 2151 | @c This is a very terrible way to suggest installing software. |
2152 | @c FIXME: Is there an official, safer way instead of blind-piping a | 2152 | @c FIXME: Is there an official, safer way instead of blind-piping a |
2153 | @c script? | 2153 | @c script? |
2154 | @c FIXME: Use newer pypi URLs below. | 2154 | @c FIXME: Use newer pypi URLs below. |
@@ -2354,7 +2354,7 @@ for new developers): | |||
2354 | @item CPS-style scheduling (scheduler.c) | 2354 | @item CPS-style scheduling (scheduler.c) |
2355 | @item Program initialization (program.c) | 2355 | @item Program initialization (program.c) |
2356 | @item Networking (network.c, client.c, server*.c, service.c) | 2356 | @item Networking (network.c, client.c, server*.c, service.c) |
2357 | @item message queueing (mq.c) | 2357 | @item message queuing (mq.c) |
2358 | @item bandwidth calculations (bandwidth.c) | 2358 | @item bandwidth calculations (bandwidth.c) |
2359 | @item Other OS-related (os*.c, plugin.c, signal.c) | 2359 | @item Other OS-related (os*.c, plugin.c, signal.c) |
2360 | @item Pseudonym management (pseudonym.c) | 2360 | @item Pseudonym management (pseudonym.c) |
@@ -2425,7 +2425,7 @@ level to "loglevel". Thus it is possible to run some processes | |||
2425 | with -L DEBUG, for example, and others with -L ERROR to enable specific | 2425 | with -L DEBUG, for example, and others with -L ERROR to enable specific |
2426 | settings to diagnose problems with a particular process. | 2426 | settings to diagnose problems with a particular process. |
2427 | @item Configuration files. Because GNUnet | 2427 | @item Configuration files. Because GNUnet |
2428 | service and deamon processes are usually launched by gnunet-arm, it is not | 2428 | service and daemon processes are usually launched by gnunet-arm, it is not |
2429 | possible to pass different custom command line options directly to every | 2429 | possible to pass different custom command line options directly to every |
2430 | one of them. The options passed to @code{gnunet-arm} only affect | 2430 | one of them. The options passed to @code{gnunet-arm} only affect |
2431 | gnunet-arm and not the rest of GNUnet. However, one can specify a | 2431 | gnunet-arm and not the rest of GNUnet. However, one can specify a |
@@ -2717,7 +2717,7 @@ will have | |||
2717 | no effect. Other messages (ERROR, WARNING, INFO, etc) will be included. | 2717 | no effect. Other messages (ERROR, WARNING, INFO, etc) will be included. |
2718 | @item If @code{--enable-logging} is set to @code{verbose}, or | 2718 | @item If @code{--enable-logging} is set to @code{verbose}, or |
2719 | @code{veryverbose} the binary will contain DEBUG messages (still, it will | 2719 | @code{veryverbose} the binary will contain DEBUG messages (still, it will |
2720 | be neccessary to run with @command{-L DEBUG} or set the DEBUG config option | 2720 | be necessary to run with @command{-L DEBUG} or set the DEBUG config option |
2721 | to show | 2721 | to show |
2722 | them). | 2722 | them). |
2723 | @end itemize | 2723 | @end itemize |
@@ -2728,7 +2728,7 @@ If you are a developer: | |||
2728 | @item please make sure that you @code{./configure | 2728 | @item please make sure that you @code{./configure |
2729 | --enable-logging=@{verbose,veryverbose@}}, so you can see DEBUG messages. | 2729 | --enable-logging=@{verbose,veryverbose@}}, so you can see DEBUG messages. |
2730 | @item please remove the @code{#if} statements around @code{GNUNET_log | 2730 | @item please remove the @code{#if} statements around @code{GNUNET_log |
2731 | (GNUNET_ERROR_TYPE_DEBUG, ...)} lines, to improve the readibility of your | 2731 | (GNUNET_ERROR_TYPE_DEBUG, ...)} lines, to improve the readability of your |
2732 | code. | 2732 | code. |
2733 | @end itemize | 2733 | @end itemize |
2734 | 2734 | ||
@@ -2741,7 +2741,7 @@ A suitable configuration could be: | |||
2741 | $ export GNUNET_FORCE_LOG="^YOUR_SUBSYSTEM$;;;;DEBUG/;;;;WARNING" | 2741 | $ export GNUNET_FORCE_LOG="^YOUR_SUBSYSTEM$;;;;DEBUG/;;;;WARNING" |
2742 | @end example | 2742 | @end example |
2743 | 2743 | ||
2744 | Which will behave almost like enabling DEBUG in that subsytem before the | 2744 | Which will behave almost like enabling DEBUG in that subsystem before the |
2745 | change. Of course you can adapt it to your particular needs, this is only | 2745 | change. Of course you can adapt it to your particular needs, this is only |
2746 | a quick example. | 2746 | a quick example. |
2747 | 2747 | ||
@@ -2952,7 +2952,7 @@ function, which is set to @code{NULL} in most cases, and the last | |||
2952 | parameter is the expected size of the message of this type, usually we | 2952 | parameter is the expected size of the message of this type, usually we |
2953 | set it to 0 to accept variable size, for special cases the exact size of | 2953 | set it to 0 to accept variable size, for special cases the exact size of |
2954 | the specified message also can be set. In addition, the terminator sign | 2954 | the specified message also can be set. In addition, the terminator sign |
2955 | depicted as @code{@{NULL, NULL, 0, 0@}} is set in the last aera. | 2955 | depicted as @code{@{NULL, NULL, 0, 0@}} is set in the last area. |
2956 | 2956 | ||
2957 | @c *********************************************************************** | 2957 | @c *********************************************************************** |
2958 | @node Server - Process request message | 2958 | @node Server - Process request message |
@@ -3002,7 +3002,7 @@ understand the request message, and the processing of this request would | |||
3002 | be terminated. | 3002 | be terminated. |
3003 | 3003 | ||
3004 | In comparison to the aforementioned situation, when the argument is equal | 3004 | In comparison to the aforementioned situation, when the argument is equal |
3005 | to @code{GNUNET_OK}, the service would continue to process the requst | 3005 | to @code{GNUNET_OK}, the service would continue to process the request |
3006 | message. | 3006 | message. |
3007 | 3007 | ||
3008 | @c *********************************************************************** | 3008 | @c *********************************************************************** |
@@ -3151,7 +3151,7 @@ GNUnet uses SHA-512 for computing one-way hash codes. The API provides | |||
3151 | functions to compute a hash over a block in memory or over a file on disk. | 3151 | functions to compute a hash over a block in memory or over a file on disk. |
3152 | 3152 | ||
3153 | The crypto API also provides functions for randomizing a block of memory, | 3153 | The crypto API also provides functions for randomizing a block of memory, |
3154 | obtaining a single random number and for generating a permuation of the | 3154 | obtaining a single random number and for generating a permutation of the |
3155 | numbers 0 to n-1. Random number generation distinguishes between WEAK and | 3155 | numbers 0 to n-1. Random number generation distinguishes between WEAK and |
3156 | STRONG random number quality; WEAK random numbers are pseudo-random | 3156 | STRONG random number quality; WEAK random numbers are pseudo-random |
3157 | whereas STRONG random numbers use entropy gathered from the operating | 3157 | whereas STRONG random numbers use entropy gathered from the operating |
@@ -3230,7 +3230,7 @@ message. | |||
3230 | 3230 | ||
3231 | Consider the following simple message, with the body consisting of a | 3231 | Consider the following simple message, with the body consisting of a |
3232 | single number value. | 3232 | single number value. |
3233 | @c why the empy code function? | 3233 | @c why the empty code function? |
3234 | @code{} | 3234 | @code{} |
3235 | 3235 | ||
3236 | @example | 3236 | @example |
@@ -3505,7 +3505,7 @@ or in some other transient data structure and thus having the hash map | |||
3505 | keep a pointer to @code{key} would not work. Only the key inside of | 3505 | keep a pointer to @code{key} would not work. Only the key inside of |
3506 | @code{val} has the same lifetime as the entry in the map (this must of | 3506 | @code{val} has the same lifetime as the entry in the map (this must of |
3507 | course be checked as well). Naturally, @code{val->key} must be | 3507 | course be checked as well). Naturally, @code{val->key} must be |
3508 | intiialized before the @code{put} call. Once all @code{put} calls have | 3508 | initialized before the @code{put} call. Once all @code{put} calls have |
3509 | been converted and double-checked, you can change the call to create the | 3509 | been converted and double-checked, you can change the call to create the |
3510 | hash map from | 3510 | hash map from |
3511 | 3511 | ||
@@ -3893,7 +3893,7 @@ The goal of transport-level address validation is to minimize the chances | |||
3893 | of a successful man-in-the-middle attack against GNUnet peers on the | 3893 | of a successful man-in-the-middle attack against GNUnet peers on the |
3894 | transport level. Such an attack would not allow the adversary to decrypt | 3894 | transport level. Such an attack would not allow the adversary to decrypt |
3895 | the P2P transmissions, but a successful attacker could at least measure | 3895 | the P2P transmissions, but a successful attacker could at least measure |
3896 | traffic volumes and latencies (raising the adversaries capablities by | 3896 | traffic volumes and latencies (raising the adversaries capabilities by |
3897 | those of a global passive adversary in the worst case). The scenarios we | 3897 | those of a global passive adversary in the worst case). The scenarios we |
3898 | are concerned about is an attacker, Mallory, giving a @code{HELLO} to | 3898 | are concerned about is an attacker, Mallory, giving a @code{HELLO} to |
3899 | Alice that claims to be for Bob, but contains Mallory's IP address | 3899 | 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 | |||
4019 | to each other about their appropriate other neighbors. They also gossip | 4019 | to each other about their appropriate other neighbors. They also gossip |
4020 | about the newly connected peer to previously | 4020 | about the newly connected peer to previously |
4021 | connected neighbors. In order to keep the routing tables up to date, | 4021 | connected neighbors. In order to keep the routing tables up to date, |
4022 | disconnect notifications are propogated as gossip as well (because | 4022 | disconnect notifications are propagated as gossip as well (because |
4023 | disconnects may not be sent/received, timeouts are also used remove | 4023 | disconnects may not be sent/received, timeouts are also used remove |
4024 | stagnant routing table entries). | 4024 | stagnant routing table entries). |
4025 | 4025 | ||
@@ -4210,7 +4210,7 @@ to send and receive messages. | |||
4210 | 4210 | ||
4211 | We have measured the performance of the UDP, TCP and SMTP transport layer | 4211 | We have measured the performance of the UDP, TCP and SMTP transport layer |
4212 | directly and when used from an application using the GNUnet core. | 4212 | directly and when used from an application using the GNUnet core. |
4213 | Measureing just the transport layer gives the better view of the actual | 4213 | Measuring just the transport layer gives the better view of the actual |
4214 | overhead of the protocol, whereas evaluating the transport from the | 4214 | overhead of the protocol, whereas evaluating the transport from the |
4215 | application puts the overhead into perspective from a practical point of | 4215 | application puts the overhead into perspective from a practical point of |
4216 | view. | 4216 | view. |
@@ -4230,7 +4230,7 @@ wire have no impact on the timings. n messages were sent sequentially over | |||
4230 | the transport layer, sending message i+1 after the i-th message was | 4230 | the transport layer, sending message i+1 after the i-th message was |
4231 | received. All messages were sent over the same connection and the time to | 4231 | received. All messages were sent over the same connection and the time to |
4232 | establish the connection was not taken into account since this overhead is | 4232 | establish the connection was not taken into account since this overhead is |
4233 | miniscule in practice --- as long as a connection is used for a | 4233 | minuscule in practice --- as long as a connection is used for a |
4234 | significant number of messages. | 4234 | significant number of messages. |
4235 | 4235 | ||
4236 | @multitable @columnfractions .20 .15 .15 .15 .15 .15 | 4236 | @multitable @columnfractions .20 .15 .15 .15 .15 .15 |
@@ -4261,9 +4261,9 @@ given time-bounds. For this benchmark we report the message loss after | |||
4261 | allowing t time for sending m messages. If messages were not sent (or | 4261 | allowing t time for sending m messages. If messages were not sent (or |
4262 | received) after an overall timeout of t, they were considered lost. The | 4262 | received) after an overall timeout of t, they were considered lost. The |
4263 | benchmark was performed using two Xeon 2 GHZ machines running RedHat 8.0 | 4263 | benchmark was performed using two Xeon 2 GHZ machines running RedHat 8.0 |
4264 | with sendmail. The machines were connected with a direct 100 MBit ethernet | 4264 | with sendmail. The machines were connected with a direct 100 MBit Ethernet |
4265 | connection.@ Figures udp1200, tcp1200 and smtp-MTUs show that the | 4265 | connection.@ Figures udp1200, tcp1200 and smtp-MTUs show that the |
4266 | throughput for messages of size 1,200 octects is 2,343 kbps, 3,310 kbps | 4266 | throughput for messages of size 1,200 octets is 2,343 kbps, 3,310 kbps |
4267 | and 6 kbps for UDP, TCP and SMTP respectively. The high per-message | 4267 | and 6 kbps for UDP, TCP and SMTP respectively. The high per-message |
4268 | overhead of SMTP can be improved by increasing the MTU, for example, an | 4268 | overhead of SMTP can be improved by increasing the MTU, for example, an |
4269 | MTU of 12,000 octets improves the throughput to 13 kbps as figure | 4269 | MTU of 12,000 octets improves the throughput to 13 kbps as figure |
@@ -4308,7 +4308,7 @@ installed). | |||
4308 | For instructions about how to install the libraries you should | 4308 | For instructions about how to install the libraries you should |
4309 | check out the BlueZ site | 4309 | check out the BlueZ site |
4310 | (@uref{http://www.bluez.org/, http://www.bluez.org}). If you don't know if | 4310 | (@uref{http://www.bluez.org/, http://www.bluez.org}). If you don't know if |
4311 | you have the necesarry libraries, don't worry, just run the GNUnet | 4311 | you have the necessary libraries, don't worry, just run the GNUnet |
4312 | configure script and you will be able to see a notification at the end | 4312 | configure script and you will be able to see a notification at the end |
4313 | which will warn you if you don't have the necessary libraries. | 4313 | which will warn you if you don't have the necessary libraries. |
4314 | 4314 | ||
@@ -4336,7 +4336,7 @@ helper binary used on GNU/Linux: | |||
4336 | 4336 | ||
4337 | @itemize @bullet | 4337 | @itemize @bullet |
4338 | @item it verifies if the name corresponds to a Bluetooth interface name | 4338 | @item it verifies if the name corresponds to a Bluetooth interface name |
4339 | @item it verifies if the iterface is up (if it is not, it tries to bring | 4339 | @item it verifies if the interface is up (if it is not, it tries to bring |
4340 | it up) | 4340 | it up) |
4341 | @item it tries to enable the page and inquiry scan in order to make the | 4341 | @item it tries to enable the page and inquiry scan in order to make the |
4342 | device discoverable and to accept incoming connection requests | 4342 | 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 | |||
4377 | something wrong with the D-Bus daemon or with the Bluetooth daemon. Use | 4377 | something wrong with the D-Bus daemon or with the Bluetooth daemon. Use |
4378 | @code{bluetoothd} tool to see the logs | 4378 | @code{bluetoothd} tool to see the logs |
4379 | 4379 | ||
4380 | @item @code{sdptool} can be used to control and interogate SDP servers. | 4380 | @item @code{sdptool} can be used to control and interrogate SDP servers. |
4381 | If you encounter problems regarding the SDP server (like the SDP server is | 4381 | If you encounter problems regarding the SDP server (like the SDP server is |
4382 | down) you should check out if the D-Bus daemon is running correctly and to | 4382 | down) you should check out if the D-Bus daemon is running correctly and to |
4383 | see if the Bluetooth daemon started correctly(use @code{bluetoothd} tool). | 4383 | see if the Bluetooth daemon started correctly(use @code{bluetoothd} tool). |
@@ -4464,11 +4464,11 @@ then start sending data for benchmarking. | |||
4464 | On Windows you cannot test the plugin functionality using two Bluetooth | 4464 | On Windows you cannot test the plugin functionality using two Bluetooth |
4465 | devices from the same machine because after you install the drivers there | 4465 | devices from the same machine because after you install the drivers there |
4466 | will occur some conflicts between the Bluetooth stacks. (At least that is | 4466 | will occur some conflicts between the Bluetooth stacks. (At least that is |
4467 | what happend on my machine : I wasn't able to use the Bluesoleil stack and | 4467 | what happened on my machine : I wasn't able to use the Bluesoleil stack and |
4468 | the WINDCOMM one in the same time). | 4468 | the WINDCOMM one in the same time). |
4469 | 4469 | ||
4470 | If you have two different machines and your configuration files are good | 4470 | If you have two different machines and your configuration files are good |
4471 | you can use the same scenario presented on the begining of this section. | 4471 | you can use the same scenario presented on the beginning of this section. |
4472 | 4472 | ||
4473 | Another way to test the plugin functionality is to create your own | 4473 | Another way to test the plugin functionality is to create your own |
4474 | application which will use the GNUnet framework with the Bluetooth | 4474 | application which will use the GNUnet framework with the Bluetooth |
@@ -4483,8 +4483,8 @@ This page describes the implementation of the Bluetooth transport plugin. | |||
4483 | First I want to remind you that the Bluetooth transport plugin uses | 4483 | First I want to remind you that the Bluetooth transport plugin uses |
4484 | virtually the same code as the WLAN plugin and only the helper binary is | 4484 | virtually the same code as the WLAN plugin and only the helper binary is |
4485 | different. Also the scope of the helper binary from the Bluetooth | 4485 | different. Also the scope of the helper binary from the Bluetooth |
4486 | transport plugin is the same as the one used for the wlan transport | 4486 | transport plugin is the same as the one used for the WLAN transport |
4487 | plugin: it acceses the interface and then it forwards traffic in both | 4487 | plugin: it accesses the interface and then it forwards traffic in both |
4488 | directions between the Bluetooth interface and stdin/stdout of the | 4488 | directions between the Bluetooth interface and stdin/stdout of the |
4489 | process involved. | 4489 | process involved. |
4490 | 4490 | ||
@@ -4525,8 +4525,8 @@ Bluetooth interface) and is separated in two stages: | |||
4525 | @subsubsection THE INITIALIZATION | 4525 | @subsubsection THE INITIALIZATION |
4526 | 4526 | ||
4527 | @itemize @bullet | 4527 | @itemize @bullet |
4528 | @item first, it checks if we have root privilegies | 4528 | @item first, it checks if we have root privileges |
4529 | (@emph{Remember that we need to have root privilegies in order to be able | 4529 | (@emph{Remember that we need to have root privileges in order to be able |
4530 | to bring the interface up if it is down or to change its state.}). | 4530 | to bring the interface up if it is down or to change its state.}). |
4531 | 4531 | ||
4532 | @item second, it verifies if the interface with the given name exists. | 4532 | @item second, it verifies if the interface with the given name exists. |
@@ -4551,7 +4551,7 @@ discoverable | |||
4551 | devices to get the port on which this device is listening on) | 4551 | devices to get the port on which this device is listening on) |
4552 | @end itemize | 4552 | @end itemize |
4553 | 4553 | ||
4554 | @item drops the root privilegies | 4554 | @item drops the root privileges |
4555 | 4555 | ||
4556 | @strong{If the interface is not a Bluetooth interface the helper exits | 4556 | @strong{If the interface is not a Bluetooth interface the helper exits |
4557 | with a suitable error} | 4557 | with a suitable error} |
@@ -4596,7 +4596,7 @@ the STDOUT file descriptor, then we write to STDOUT the message from the | |||
4596 | @emph{write_std} buffer. | 4596 | @emph{write_std} buffer. |
4597 | 4597 | ||
4598 | To find out on which port a device is listening on we connect to the local | 4598 | To find out on which port a device is listening on we connect to the local |
4599 | SDP server and searche the registered service for that device. | 4599 | SDP server and search the registered service for that device. |
4600 | 4600 | ||
4601 | @emph{You should be aware of the fact that if the device fails to connect | 4601 | @emph{You should be aware of the fact that if the device fails to connect |
4602 | to another one when trying to send a message it will attempt one more | 4602 | 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 | |||
4659 | advantage of coming standard from Windows XP SP2. The main disadvantage is | 4659 | advantage of coming standard from Windows XP SP2. The main disadvantage is |
4660 | that it only supports the RFCOMM protocol so we will not be able to have | 4660 | that it only supports the RFCOMM protocol so we will not be able to have |
4661 | a low level control over the Bluetooth device. Therefore it is the user | 4661 | a low level control over the Bluetooth device. Therefore it is the user |
4662 | responsability to check if the device is up and in the discoverable mode. | 4662 | responsibility to check if the device is up and in the discoverable mode. |
4663 | Also there are no tools which could be used for debugging in order to read | 4663 | Also there are no tools which could be used for debugging in order to read |
4664 | the data coming from and going to a Bluetooth device, which obviously | 4664 | the data coming from and going to a Bluetooth device, which obviously |
4665 | hindered my work. Another thing that slowed down the implementation of the | 4665 | hindered my work. Another thing that slowed down the implementation of the |
4666 | plugin (besides that I wasn't too accomodated with the win32 API) was that | 4666 | plugin (besides that I wasn't too accommodated with the win32 API) was that |
4667 | there were some bugs on MinGW regarding the Bluetooth. Now they are solved | 4667 | there were some bugs on MinGW regarding the Bluetooth. Now they are solved |
4668 | but you should keep in mind that you should have the latest updates | 4668 | but you should keep in mind that you should have the latest updates |
4669 | (especially the @emph{ws2bth} header). | 4669 | (especially the @emph{ws2bth} header). |
4670 | 4670 | ||
4671 | Besides the fact that it uses the Windows Sockets, the Windows | 4671 | Besides the fact that it uses the Windows Sockets, the Windows |
4672 | implemenation follows the same principles as the GNU/Linux one: | 4672 | implementation follows the same principles as the GNU/Linux one: |
4673 | 4673 | ||
4674 | @itemize @bullet | 4674 | @itemize @bullet |
4675 | @item It has a initalization part where it initializes the | 4675 | @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. | |||
4714 | @item Implement the broadcast functionality on Windows @emph{(currently | 4714 | @item Implement the broadcast functionality on Windows @emph{(currently |
4715 | working on)} | 4715 | working on)} |
4716 | @item Implement a testcase for the helper :@ @emph{The testcase | 4716 | @item Implement a testcase for the helper :@ @emph{The testcase |
4717 | consists of a program which emaluates the plugin and uses the helper. It | 4717 | consists of a program which emulates the plugin and uses the helper. It |
4718 | will simulate connections, disconnections and data transfers.} | 4718 | will simulate connections, disconnections and data transfers.} |
4719 | @end itemize | 4719 | @end itemize |
4720 | 4720 | ||
@@ -4902,7 +4902,7 @@ peers connecting, peers disconnecting and incoming messages) and send | |||
4902 | messages to connected peers using | 4902 | messages to connected peers using |
4903 | @code{GNUNET_CORE_notify_transmit_ready}. Note that applications must | 4903 | @code{GNUNET_CORE_notify_transmit_ready}. Note that applications must |
4904 | cancel pending transmission requests if they receive a disconnect event | 4904 | cancel pending transmission requests if they receive a disconnect event |
4905 | for a peer that had a transmission pending; furthermore, queueing more | 4905 | for a peer that had a transmission pending; furthermore, queuing more |
4906 | than one transmission request per peer per application using the | 4906 | than one transmission request per peer per application using the |
4907 | service is not permitted. | 4907 | service is not permitted. |
4908 | 4908 | ||
@@ -5197,11 +5197,11 @@ The API is heavily base on the CORE API. | |||
5197 | CADET delivers messages to other peers in "channels". | 5197 | CADET delivers messages to other peers in "channels". |
5198 | A channel is a permanent connection defined by a destination peer | 5198 | A channel is a permanent connection defined by a destination peer |
5199 | (identified by its public key) and a port number. | 5199 | (identified by its public key) and a port number. |
5200 | Internally, CADET tunnels all channels towards a destiantion peer | 5200 | Internally, CADET tunnels all channels towards a destination peer |
5201 | using one session key and relays the data on multiple "connections", | 5201 | using one session key and relays the data on multiple "connections", |
5202 | independent from the channels. | 5202 | independent from the channels. |
5203 | 5203 | ||
5204 | Each channel has optional paramenters, the most important being the | 5204 | Each channel has optional parameters, the most important being the |
5205 | reliability flag. | 5205 | reliability flag. |
5206 | Should a message get lost on TRANSPORT/CORE level, if a channel is | 5206 | Should a message get lost on TRANSPORT/CORE level, if a channel is |
5207 | created with as reliable, CADET will retransmit the lost message and | 5207 | 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 | |||
5242 | @code{GNUNET_CADET_notify_transmit_ready} immediately after | 5242 | @code{GNUNET_CADET_notify_transmit_ready} immediately after |
5243 | @code{GNUNET_CADET_create_channel}. When the callback is activated, it | 5243 | @code{GNUNET_CADET_create_channel}. When the callback is activated, it |
5244 | means that the channel is online. The callback can give 0 bytes to CADET | 5244 | means that the channel is online. The callback can give 0 bytes to CADET |
5245 | if no message is to be sent, this is ok. | 5245 | if no message is to be sent, this is OK. |
5246 | 5246 | ||
5247 | If a transmission was requested but before the callback fires it is no | 5247 | If a transmission was requested but before the callback fires it is no |
5248 | longer needed, it can be cancelled with | 5248 | longer needed, it can be canceled with |
5249 | @code{GNUNET_CADET_notify_transmit_ready_cancel}, which uses the handle | 5249 | @code{GNUNET_CADET_notify_transmit_ready_cancel}, which uses the handle |
5250 | given back by @code{GNUNET_CADET_notify_transmit_ready}. | 5250 | given back by @code{GNUNET_CADET_notify_transmit_ready}. |
5251 | As in the case of CORE, only one message can be requested at a time: a | 5251 | As in the case of CORE, only one message can be requested at a time: a |
5252 | client must not call @code{GNUNET_CADET_notify_transmit_ready} again until | 5252 | client must not call @code{GNUNET_CADET_notify_transmit_ready} again until |
5253 | the callback is called or the request is cancelled. | 5253 | the callback is called or the request is canceled. |
5254 | 5254 | ||
5255 | When a channel is no longer needed, a client can call | 5255 | When a channel is no longer needed, a client can call |
5256 | @code{GNUNET_CADET_channel_destroy} to get rid of it. | 5256 | @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. | |||
5298 | @subsection Motivation | 5298 | @subsection Motivation |
5299 | 5299 | ||
5300 | 5300 | ||
5301 | Some subsytems, like DHT, need to know the size of the GNUnet network to | 5301 | Some subsystems, like DHT, need to know the size of the GNUnet network to |
5302 | optimize some parameters of their own protocol. The decentralized nature | 5302 | optimize some parameters of their own protocol. The decentralized nature |
5303 | of GNUnet makes efficient and securely counting the exact number of peers | 5303 | of GNUnet makes efficient and securely counting the exact number of peers |
5304 | infeasable. Although there are several decentralized algorithms to count | 5304 | infeasible. Although there are several decentralized algorithms to count |
5305 | the number of peers in a system, so far there is none to do so securely. | 5305 | the number of peers in a system, so far there is none to do so securely. |
5306 | Other protocols may allow any malicious peer to manipulate the final | 5306 | Other protocols may allow any malicious peer to manipulate the final |
5307 | result or to take advantage of the system to perform | 5307 | result or to take advantage of the system to perform |
@@ -5323,7 +5323,7 @@ GNUnet's NSE protocol avoids these drawbacks. | |||
5323 | The NSE subsystem is designed to be resilient against these attacks. | 5323 | The NSE subsystem is designed to be resilient against these attacks. |
5324 | It uses @uref{http://en.wikipedia.org/wiki/Proof-of-work_system, proofs of work} | 5324 | It uses @uref{http://en.wikipedia.org/wiki/Proof-of-work_system, proofs of work} |
5325 | to prevent one peer from impersonating a large number of participants, | 5325 | to prevent one peer from impersonating a large number of participants, |
5326 | which would otherwise allow an adversary to artifically inflate the | 5326 | which would otherwise allow an adversary to artificially inflate the |
5327 | estimate. | 5327 | estimate. |
5328 | The DoS protection comes from the time-based nature of the protocol: | 5328 | The DoS protection comes from the time-based nature of the protocol: |
5329 | the estimates are calculated periodically and out-of-time traffic is | 5329 | 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. | |||
5385 | The target value itself is generated by hashing the current time, rounded | 5385 | The target value itself is generated by hashing the current time, rounded |
5386 | down to an agreed value. If the rounding amount is 1h (default) and the | 5386 | down to an agreed value. If the rounding amount is 1h (default) and the |
5387 | time is 12:34:56, the time to hash would be 12:00:00. The process is | 5387 | time is 12:34:56, the time to hash would be 12:00:00. The process is |
5388 | repeated each rouning amount (in this example would be every hour). | 5388 | repeated each rounding amount (in this example would be every hour). |
5389 | Every repetition is called a round. | 5389 | Every repetition is called a round. |
5390 | 5390 | ||
5391 | @node Timing | 5391 | @node Timing |
@@ -5397,12 +5397,12 @@ its ID all at one. Once each peer has the target random value, it | |||
5397 | compares its own ID to the target and calculates the hypothetical size of | 5397 | compares its own ID to the target and calculates the hypothetical size of |
5398 | the network if that peer were to be the closest. | 5398 | the network if that peer were to be the closest. |
5399 | Then it compares the hypothetical size with the estimate from the previous | 5399 | Then it compares the hypothetical size with the estimate from the previous |
5400 | rounds. For each value there is an assiciated point in the period, | 5400 | rounds. For each value there is an associated point in the period, |
5401 | let's call it "broadcast time". If its own hypothetical estimate | 5401 | let's call it "broadcast time". If its own hypothetical estimate |
5402 | is the same as the previous global estimate, its "broadcast time" will be | 5402 | is the same as the previous global estimate, its "broadcast time" will be |
5403 | in the middle of the round. If its bigger it will be earlier and if its | 5403 | in the middle of the round. If its bigger it will be earlier and if its |
5404 | smaller (the most likely case) it will be later. This ensures that the | 5404 | smaller (the most likely case) it will be later. This ensures that the |
5405 | peers closests to the target value start broadcasting their ID the first. | 5405 | peers closest to the target value start broadcasting their ID the first. |
5406 | 5406 | ||
5407 | @node Controlled Flooding | 5407 | @node Controlled Flooding |
5408 | @subsubsection Controlled Flooding | 5408 | @subsubsection Controlled Flooding |
@@ -5415,7 +5415,7 @@ with a message containing the better value. Then it checks a proof of | |||
5415 | work that must be included in the incoming message, to ensure that the | 5415 | work that must be included in the incoming message, to ensure that the |
5416 | other peer's ID is not made up (otherwise a malicious peer could claim to | 5416 | other peer's ID is not made up (otherwise a malicious peer could claim to |
5417 | have an ID of exactly the target value every round). Once validated, it | 5417 | have an ID of exactly the target value every round). Once validated, it |
5418 | compares the brodcast time of the received value with the current time | 5418 | compares the broadcast time of the received value with the current time |
5419 | and if it's not too early, sends the received value to its neighbors. | 5419 | and if it's not too early, sends the received value to its neighbors. |
5420 | Otherwise it stores the value until the correct broadcast time comes. | 5420 | Otherwise it stores the value until the correct broadcast time comes. |
5421 | This prevents unnecessary traffic of sub-optimal values, since a better | 5421 | This prevents unnecessary traffic of sub-optimal values, since a better |
@@ -5429,7 +5429,7 @@ to the neighbors. | |||
5429 | @c %**end of header | 5429 | @c %**end of header |
5430 | 5430 | ||
5431 | Once the closest ID has been spread across the network each peer gets the | 5431 | Once the closest ID has been spread across the network each peer gets the |
5432 | exact distance betweed this ID and the target value of the round and | 5432 | exact distance between this ID and the target value of the round and |
5433 | calculates the estimate with a mathematical formula described in the tech | 5433 | calculates the estimate with a mathematical formula described in the tech |
5434 | report. The estimate generated with this method for a single round is not | 5434 | report. The estimate generated with this method for a single round is not |
5435 | very precise. Remember the case of the example, where the only peer is the | 5435 | 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 | |||
5477 | @uref{http://en.wikipedia.org/wiki/Standard_deviation, standard deviation} | 5477 | @uref{http://en.wikipedia.org/wiki/Standard_deviation, standard deviation} |
5478 | of the last 64 rounds. The values provided by the callback function are | 5478 | of the last 64 rounds. The values provided by the callback function are |
5479 | logarithmic, this means that the real estimate numbers can be obtained by | 5479 | logarithmic, this means that the real estimate numbers can be obtained by |
5480 | calculating 2 to the power of the given value (2average). From a | 5480 | calculating 2 to the power of the given value (average). From a |
5481 | statistics point of view this means that: | 5481 | statistics point of view this means that: |
5482 | 5482 | ||
5483 | @itemize @bullet | 5483 | @itemize @bullet |
@@ -5503,7 +5503,7 @@ size is between one third and three times the estimate. This can of | |||
5503 | course vary with network conditions. | 5503 | course vary with network conditions. |
5504 | Thus, applications may want to also consider the provided standard | 5504 | Thus, applications may want to also consider the provided standard |
5505 | deviation value, not only the average (in particular, if the standard | 5505 | deviation value, not only the average (in particular, if the standard |
5506 | veriation is very high, the average maybe meaningless: the network size is | 5506 | variation is very high, the average maybe meaningless: the network size is |
5507 | changing rapidly). | 5507 | changing rapidly). |
5508 | 5508 | ||
5509 | @node libgnunetnse - Examples | 5509 | @node libgnunetnse - Examples |
@@ -5584,7 +5584,7 @@ At the beginning of each round the peer does the following: | |||
5584 | it has a better message in the "next round" slot which came early in the | 5584 | it has a better message in the "next round" slot which came early in the |
5585 | previous round) | 5585 | previous round) |
5586 | @item calculates, based on the stored round message (own or received) when | 5586 | @item calculates, based on the stored round message (own or received) when |
5587 | to stard flooding it to its neighbors | 5587 | to start flooding it to its neighbors |
5588 | @end itemize | 5588 | @end itemize |
5589 | 5589 | ||
5590 | Upon receiving a message the peer checks the validity of the message | 5590 | 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 | |||
6085 | lookup a single ego by name. Note that this is the user's name for the | 6085 | lookup a single ego by name. Note that this is the user's name for the |
6086 | ego, not the service function. The resulting ego will be returned via a | 6086 | ego, not the service function. The resulting ego will be returned via a |
6087 | callback and will only be valid during that callback. The operation can | 6087 | callback and will only be valid during that callback. The operation can |
6088 | be cancelled via @code{GNUNET_IDENTITY_ego_lookup_cancel} | 6088 | be canceled via @code{GNUNET_IDENTITY_ego_lookup_cancel} |
6089 | (cancellation is only legal before the callback is invoked). | 6089 | (cancellation is only legal before the callback is invoked). |
6090 | 6090 | ||
6091 | @node Associating egos with service functions | 6091 | @node Associating egos with service functions |
@@ -6658,7 +6658,7 @@ The size of an element's data is limited to around 62 KB. | |||
6658 | 6658 | ||
6659 | Sets created by a local client can be modified and reused for multiple | 6659 | Sets created by a local client can be modified and reused for multiple |
6660 | operations. As each set operation requires potentially expensive special | 6660 | operations. As each set operation requires potentially expensive special |
6661 | auxilliary data to be computed for each element of a set, a set can only | 6661 | auxiliary data to be computed for each element of a set, a set can only |
6662 | participate in one type of set operation (i.e. union or intersection). | 6662 | participate in one type of set operation (i.e. union or intersection). |
6663 | The type of a set is determined upon its creation. | 6663 | The type of a set is determined upon its creation. |
6664 | If a the elements of a set are needed for an operation of a different | 6664 | 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} | |||
6778 | @c %**end of header | 6778 | @c %**end of header |
6779 | 6779 | ||
6780 | To create symmetry between the two ways of starting a set operation | 6780 | To create symmetry between the two ways of starting a set operation |
6781 | (accepting and nitiating it), the operation handles returned by | 6781 | (accepting and initiating it), the operation handles returned by |
6782 | @code{GNUNET_SET_accept} and @code{GNUNET_SET_prepare} do not yet have a | 6782 | @code{GNUNET_SET_accept} and @code{GNUNET_SET_prepare} do not yet have a |
6783 | set to operate on, thus they can not do any work yet. | 6783 | set to operate on, thus they can not do any work yet. |
6784 | 6784 | ||
@@ -6938,7 +6938,7 @@ It then checks if the set size of the sender and the XOR over the keys | |||
6938 | match what is left of his own set. If they do, he sends a | 6938 | match what is left of his own set. If they do, he sends a |
6939 | @code{GNUNET_MESSAGE_TYPE_SET_INTERSECTION_P2P_DONE} back to indicate | 6939 | @code{GNUNET_MESSAGE_TYPE_SET_INTERSECTION_P2P_DONE} back to indicate |
6940 | that the latest set is the final result. | 6940 | that the latest set is the final result. |
6941 | Otherwise, the receiver starts another Bloom fitler exchange, except | 6941 | Otherwise, the receiver starts another Bloom filter exchange, except |
6942 | this time as the sender. | 6942 | this time as the sender. |
6943 | 6943 | ||
6944 | @node Salt | 6944 | @node Salt |
@@ -6946,7 +6946,7 @@ this time as the sender. | |||
6946 | 6946 | ||
6947 | @c %**end of header | 6947 | @c %**end of header |
6948 | 6948 | ||
6949 | Bloomfilter operations are probablistic: With some non-zero probability | 6949 | Bloomfilter operations are probabilistic: With some non-zero probability |
6950 | the test may incorrectly say an element is in the set, even though it is | 6950 | the test may incorrectly say an element is in the set, even though it is |
6951 | not. | 6951 | not. |
6952 | 6952 | ||
@@ -6999,7 +6999,7 @@ message. If the IBF fully decodes, the peer responds with a | |||
6999 | GNUNET_MESSAGE_TYPE_SET_UNION_P2P_DONE message instead of another | 6999 | GNUNET_MESSAGE_TYPE_SET_UNION_P2P_DONE message instead of another |
7000 | GNUNET_MESSAGE_TYPE_SET_UNION_P2P_IBF. | 7000 | GNUNET_MESSAGE_TYPE_SET_UNION_P2P_IBF. |
7001 | 7001 | ||
7002 | All Bloom filter operations use a salt to mingle keys before hasing them | 7002 | All Bloom filter operations use a salt to mingle keys before hashing them |
7003 | into buckets, such that future iterations have a fresh chance of | 7003 | into buckets, such that future iterations have a fresh chance of |
7004 | succeeding if they failed due to collisions before. | 7004 | succeeding if they failed due to collisions before. |
7005 | 7005 | ||
@@ -7557,7 +7557,7 @@ already knows more than about a thousand blocks may need to send | |||
7557 | several of these messages. Naturally, the client should transmit these | 7557 | several of these messages. Naturally, the client should transmit these |
7558 | messages as quickly as possible after the original GET request such that | 7558 | messages as quickly as possible after the original GET request such that |
7559 | the DHT can filter those results in the network early on. Naturally, as | 7559 | the DHT can filter those results in the network early on. Naturally, as |
7560 | these messages are sent after the original request, it is conceivalbe | 7560 | these messages are sent after the original request, it is conceivable |
7561 | that the DHT service may return blocks that match those already known | 7561 | that the DHT service may return blocks that match those already known |
7562 | to the client anyway. | 7562 | to the client anyway. |
7563 | 7563 | ||
@@ -7670,7 +7670,7 @@ duplicate results) and when they obtain a matching, non-filtered response | |||
7670 | a @code{struct PeerResultMessage} of type | 7670 | a @code{struct PeerResultMessage} of type |
7671 | @code{GNUNET_MESSAGE_TYPE_DHT_P2P_RESULT} is forwarded to the previous | 7671 | @code{GNUNET_MESSAGE_TYPE_DHT_P2P_RESULT} is forwarded to the previous |
7672 | hop. | 7672 | hop. |
7673 | Whenver a result is forwarded, the block plugin is used to update the | 7673 | Whenever a result is forwarded, the block plugin is used to update the |
7674 | Bloom filter accordingly, to ensure that the same result is never | 7674 | Bloom filter accordingly, to ensure that the same result is never |
7675 | forwarded more than once. | 7675 | forwarded more than once. |
7676 | The DHT service may also cache forwarded results locally if the | 7676 | The DHT service may also cache forwarded results locally if the |
@@ -7737,7 +7737,7 @@ record types. | |||
7737 | 7737 | ||
7738 | @c %**end of header | 7738 | @c %**end of header |
7739 | 7739 | ||
7740 | The GNS API itself is extremely simple. Clients first connec to the | 7740 | The GNS API itself is extremely simple. Clients first connect to the |
7741 | GNS service using @code{GNUNET_GNS_connect}. | 7741 | GNS service using @code{GNUNET_GNS_connect}. |
7742 | They can then perform lookups using @code{GNUNET_GNS_lookup} or cancel | 7742 | They can then perform lookups using @code{GNUNET_GNS_lookup} or cancel |
7743 | pending lookups using @code{GNUNET_GNS_lookup_cancel}. | 7743 | pending lookups using @code{GNUNET_GNS_lookup_cancel}. |
@@ -7786,9 +7786,9 @@ their respective zones can automatically be learned and added to the | |||
7786 | the shorten zone. If NULL is passed, shortening is disabled. | 7786 | the shorten zone. If NULL is passed, shortening is disabled. |
7787 | @item proc This argument identifies | 7787 | @item proc This argument identifies |
7788 | the function to call with the result. It is given proc_cls, the number of | 7788 | the function to call with the result. It is given proc_cls, the number of |
7789 | records found (possilby zero) and the array of the records as arguments. | 7789 | records found (possibly zero) and the array of the records as arguments. |
7790 | proc will only be called once. After proc,> has been called, the lookup | 7790 | proc will only be called once. After proc,> has been called, the lookup |
7791 | must no longer be cancelled. | 7791 | must no longer be canceled. |
7792 | @item proc_cls The closure for proc. | 7792 | @item proc_cls The closure for proc. |
7793 | @end table | 7793 | @end table |
7794 | 7794 | ||
@@ -7943,7 +7943,7 @@ This is merely one method for how we can obtain GNS queries. | |||
7943 | It is also possible to change @code{resolv.conf} to point to a machine | 7943 | It is also possible to change @code{resolv.conf} to point to a machine |
7944 | running @code{gnunet-dns2gns} or to modify libc's name system switch | 7944 | running @code{gnunet-dns2gns} or to modify libc's name system switch |
7945 | (NSS) configuration to include a GNS resolution plugin. | 7945 | (NSS) configuration to include a GNS resolution plugin. |
7946 | The method described in this chaper is more of a last-ditch catch-all | 7946 | The method described in this chapter is more of a last-ditch catch-all |
7947 | approach. | 7947 | approach. |
7948 | 7948 | ||
7949 | @code{gnunet-service-dns} enables intercepting DNS traffic using policy | 7949 | @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 | |||
8111 | NAMECACHE. Using @code{GNUNET_NAMECACHE_block_cache} clients can insert a | 8111 | NAMECACHE. Using @code{GNUNET_NAMECACHE_block_cache} clients can insert a |
8112 | block into the cache. | 8112 | block into the cache. |
8113 | @code{GNUNET_NAMECACHE_lookup_block} can be used to lookup blocks that | 8113 | @code{GNUNET_NAMECACHE_lookup_block} can be used to lookup blocks that |
8114 | were stored in the NAMECACHE. Both operations can be cancelled using | 8114 | were stored in the NAMECACHE. Both operations can be canceled using |
8115 | @code{GNUNET_NAMECACHE_cancel}. Note that cancelling a | 8115 | @code{GNUNET_NAMECACHE_cancel}. Note that canceling a |
8116 | @code{GNUNET_NAMECACHE_block_cache} operation can result in the block | 8116 | @code{GNUNET_NAMECACHE_block_cache} operation can result in the block |
8117 | being stored in the NAMECACHE --- or not. Cancellation primarily ensures | 8117 | being stored in the NAMECACHE --- or not. Cancellation primarily ensures |
8118 | that the continuation function with the result of the operation will no | 8118 | that the continuation function with the result of the operation will no |
@@ -8299,7 +8299,7 @@ revocations. | |||
8299 | @code{GNUNET_REVOCATION_query} is used to check if a given ECDSA public | 8299 | @code{GNUNET_REVOCATION_query} is used to check if a given ECDSA public |
8300 | key has been revoked. | 8300 | key has been revoked. |
8301 | The given callback will be invoked with the result of the check. | 8301 | The given callback will be invoked with the result of the check. |
8302 | The query can be cancelled using @code{GNUNET_REVOCATION_query_cancel} on | 8302 | The query can be canceled using @code{GNUNET_REVOCATION_query_cancel} on |
8303 | the return value. | 8303 | the return value. |
8304 | 8304 | ||
8305 | @node Preparing revocations | 8305 | @node Preparing revocations |
@@ -8477,7 +8477,7 @@ metadata describing the content of the namespace. | |||
8477 | Instead of the name of the identifier for a potential update, it contains | 8477 | Instead of the name of the identifier for a potential update, it contains |
8478 | the identifier for the root of the namespace. | 8478 | the identifier for the root of the namespace. |
8479 | The URI should always be empty. The @code{SBlock} is signed with the | 8479 | The URI should always be empty. The @code{SBlock} is signed with the |
8480 | content provder's RSA private key (just like any other SBlock). Peers | 8480 | content provider's RSA private key (just like any other SBlock). Peers |
8481 | can search for @code{SBlock}s in order to find out more about a namespace. | 8481 | can search for @code{SBlock}s in order to find out more about a namespace. |
8482 | 8482 | ||
8483 | @node KSBlocks | 8483 | @node KSBlocks |
@@ -8800,5 +8800,5 @@ so please make sure that endpoints are unambiguous. | |||
8800 | @subsection Endpoint documentation | 8800 | @subsection Endpoint documentation |
8801 | 8801 | ||
8802 | This is WIP. Endpoints should be documented appropriately. | 8802 | This is WIP. Endpoints should be documented appropriately. |
8803 | Perferably using annotations. | 8803 | Preferably using annotations. |
8804 | 8804 | ||