[GNUnet-SVN] [gnunet-texinfo] branch master updated: developer.texi: leading whitespaces fixes etc

[gnunet]

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

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

The following commit(s) were added to refs/heads/master by this push:
     new 644a9d7  developer.texi: leading whitespaces fixes etc
644a9d7 is described below

commit 644a9d7def978151ce1b888d4d598b90bb4b449d
Author: ng0 <address@hidden>
AuthorDate: Fri Feb 17 16:57:51 2017 +0000

    developer.texi: leading whitespaces fixes etc
---
 developer.texi | 449 +++++++++++++++++++++++++--------------------------------
 1 file changed, 195 insertions(+), 254 deletions(-)

diff --git a/developer.texi b/developer.texi
index cacb56f..6bcab0c 100644
--- a/developer.texi
+++ b/developer.texi
@@ -736,7 +736,7 @@ relevant to developers that hope to be able to avoid 
changes to applications
 build on top of the APIs of the framework.
 
 The following table summarizes our current view of the stability of the
-respective protocols or APIs: 
+respective protocols or APIs:
 @multitable @columnfractions 0.0263157894736842
 0.0263157894736842 0.0263157894736842 0.0263157894736842 0.0263157894736842
 0.0263157894736842 0.0263157894736842 0.0263157894736842 0.0263157894736842
@@ -1340,7 +1340,7 @@ if ( (1 == foo) || ((0 == bar) && (x != y)) ) return x;
 However, this is not:
 @example
 if (1 == foo) return x; if (0 == bar && x != y)
-return x; 
+return x;
 @end example
 
 
@@ -2010,19 +2010,10 @@ Note the difference between this downward propagation 
of the
 propagation --- the upward propagation is needed for ensuring that the barrier
 is reached by all the controllers and the downward propagation is for
 triggering that the barrier is crossed.
address@hidden
address@hidden
-
-
address@hidden
 
address@hidden itemize
address@hidden 
***************************************************************************
address@hidden Automatic large-scale deployment of GNUnet in the PlanetLab 
testbed
 @settitle Automatic large-scale deployment of GNUnet in the PlanetLab testbed
address@hidden %**end of header
-
address@hidden Top
-
-
 
 PlanetLab is as a testbed for computer networking and distributed systems
 research. It was established in 2002 and as of June 2010 was composed of 1090
@@ -2032,28 +2023,17 @@ To automate the GNUnet we created a set of automation 
tools to simplify 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 https://gnunet.org/installation-fedora8-svn and@
-https://gnunet.org/installation-fedora12-svn to find detailled instructions how
-to install GNUnet on a PlanetLab node
address@hidden PlanetLab Automation for Fedora8 nodes
address@hidden %**end of header
-
address@hidden Top
-
-
address@hidden
address@hidden
-
-
address@hidden
-
address@hidden itemize
address@hidden Install buildslave on PlanetLab nodes running fedora core 8
address@hidden %**end of header
-
address@hidden Top
+Please also check @uref{https://gnunet.org/installation-fedora8-svn} and@
address@hidden://gnunet.org/installation-fedora12-svn} to find detailled
+instructions how to install GNUnet on a PlanetLab node.
 
address@hidden 
***************************************************************************
address@hidden PlanetLab Automation for Fedora8 nodes
address@hidden PlanetLab Automation for Fedora8 nodes
 
address@hidden 
***************************************************************************
address@hidden Install buildslave on PlanetLab nodes running fedora core 8
address@hidden Install buildslave on PlanetLab nodes running fedora core 8
 
 Since most of the PlanetLab nodes are running the very old fedora core 8 image,
 installing the buildslave software is quite some pain. For our PlanetLab
@@ -2076,35 +2056,19 @@ install@ }
 The setup will download the matching twisted package and install it.@ It will
 also try to install the latest version of zope.interface which will fail to
 install. Buildslave will work anyway since version 3.8.0 was installed before!
address@hidden
address@hidden
-
-
address@hidden
-
address@hidden itemize
address@hidden Setup a new PlanetLab testbed using GPLMT
address@hidden %**end of header
-
-
address@hidden Top
 
address@hidden 
***************************************************************************
address@hidden Setup a new PlanetLab testbed using GPLMT
address@hidden Setup a new PlanetLab testbed using GPLMT
 
 @itemize
 @bullet
-
-
address@hidden Get a new slice and assing nodes
-
address@hidden Get a new slice and assign nodes
 Ask your PlanetLab PI to give you a new slice and assign the nodes you need
-
 @item Install a buildmaster
-
 You can stick to the buildbot documentation:@
-http://buildbot.net/buildbot/docs/current/manual/installation.html
-
address@hidden://buildbot.net/buildbot/docs/current/manual/installation.html}
 @item Install the buildslave software on all nodes
-
 To install the buildslave on all nodes assigned to your slice you can use the
 tasklist @code{install_buildslave_fc8.xml} provided with GPLMT:
 
@@ -2136,61 +2100,43 @@ configuration for some nodes in a file:@ @code{@
 <template>@ }
 
 @item Copy the @code{master.cfg} to the buildmaster and start it
-
 Use @code{buildbot start <basedir>} to start the server
-
address@hidden Setup the buildslaves @end itemize
-
address@hidden
address@hidden
-
-
address@hidden
-
address@hidden itemize
address@hidden Why do i get an ssh error when using the regex profiler?
address@hidden %**end of header
-
address@hidden Top
-
-Language  English
address@hidden
address@hidden
-
-
address@hidden
-
address@hidden Setup the buildslaves
 @end itemize
 
address@hidden 
***************************************************************************
address@hidden Why do i get an ssh error when using the regex profiler?
address@hidden Why do i get an ssh error when using the regex profiler?
 
 Why do i get an ssh error "Permission denied (publickey,password)." when using
 the regex profiler although passwordless ssh to localhost works using publickey
 and ssh-agent?
 
-You have to generate a public/private-key pair with no password:@ ssh-keygen -t
-rsa -b 4096 -f ~/.ssh/id_localhost@ and then add the following to your
-~/.ssh/config
+You have to generate a public/private-key pair with no password:@
address@hidden -t rsa -b 4096 -f ~/.ssh/id_localhost}@
+and then add the following to your ~/.ssh/config file:
 
-Host 127.0.0.1@ IdentityFile ~/.ssh/id_localhost
address@hidden 127.0.0.1@ IdentityFile ~/.ssh/id_localhost}
 
-now make sure your hostsfile looks like@ [USERNAME]@@127.0.0.1:22@
+now make sure your hostsfile looks like@
+
+[USERNAME]@@127.0.0.1:22@
 [USERNAME]@@127.0.0.1:22
 
-you can test your setup by running `ssh 127.0.0.1` in a terminal and then in
+You can test your setup by running `ssh 127.0.0.1` in a terminal and then in
 the opened session run it again. If you were not asked for a password on either
-login, then you should be good to address@hidden TESTBED Caveats @c %**end of
-header
-
address@hidden Top
-
+login, then you should be good to go.
 
address@hidden 
***************************************************************************
address@hidden TESTBED Caveats
address@hidden TESTBED Caveats
 
 This section documents a few caveats when using the GNUnet testbed
address@hidden CORE must be started @c %**end of header
-
address@hidden Top
-
+subsystem.
 
address@hidden 
***************************************************************************
address@hidden CORE must be started
address@hidden CORE must be started
 
 A simple issue is #3993: Your configuration MUST somehow ensure that for each
 peer the CORE service is started when the peer is setup, otherwise TESTBED may
@@ -2200,11 +2146,11 @@ running). The easiest way is to set 'FORCESTART = YES' 
in the '[core]' section
 of the configuration file. Alternatively, having any service that directly or
 indirectly depends on CORE being started with FORCESTART will also do. This
 issue largely arises if users try to over-optimize by not starting any services
-with address@hidden ATS must want the connections @c %**end of header
-
address@hidden Top
-
+with FORCESTART.
 
address@hidden 
***************************************************************************
address@hidden ATS must want the connections
address@hidden ATS must want the connections
 
 When TESTBED sets up connections, it only offers the respective HELLO
 information to the TRANSPORT service. It is then up to the ATS service to
@@ -2216,18 +2162,11 @@ provided the required information), then that 
connection will count as failed
 for TESTBED. Note that you can configure TESTBED to tolerate a certain number
 of connection failures (see '-e' option of gnunet-testbed-profiler). This issue
 largely arises for dense overlay topologies, especially if you try to create
-cliques with more than 20 peers.  @itemize @bullet
-
-
address@hidden
-
address@hidden itemize
address@hidden libgnunetutil
address@hidden %**end of header
-
address@hidden Top
-
+cliques with more than 20 peers.
 
address@hidden 
***************************************************************************
address@hidden libgnunetutil
address@hidden libgnunetutil
 
 libgnunetutil is the fundamental library that all GNUnet code builds upon.
 Ideally, this library should contain most of the platform dependent code
@@ -2239,46 +2178,26 @@ provided by libgnunetutil fall roughly into the 
following categories (in
 roughly the order of importance for new developers):
 @itemize
 @bullet
-
-
 @item logging (common_logging.c)
-
 @item memory allocation (common_allocation.c)
-
 @item endianess conversion (common_endian.c)
-
 @item internationalization (common_gettext.c)
-
 @item String manipulation (string.c)
-
 @item file access (disk.c)
-
 @item buffered disk IO (bio.c)
-
 @item time manipulation (time.c)
-
 @item configuration parsing (configuration.c)
-
 @item command-line handling (getopt*.c)
-
 @item cryptography (crypto_*.c)
-
 @item data structures (container_*.c)
-
 @item CPS-style scheduling (scheduler.c)
-
 @item Program initialization (program.c)
-
 @item Networking (network.c, client.c, server*.c, service.c)
-
 @item message queueing (mq.c)
-
 @item bandwidth calculations (bandwidth.c)
-
 @item Other OS-related (os*.c, plugin.c, signal.c)
-
address@hidden Pseudonym management (pseudonym.c) @end itemize
-
address@hidden Pseudonym management (pseudonym.c)
address@hidden itemize
 
 It should be noted that only developers that fully understand this entire API
 will be able to write good GNUnet code.
@@ -2286,19 +2205,10 @@ will be able to write good GNUnet code.
 Ideally, porting GNUnet should only require porting the gnunetutil library.
 More testcases for the gnunetutil APIs are therefore a great way to make
 porting of GNUnet easier.
address@hidden
address@hidden
-
-
address@hidden
-
address@hidden itemize
address@hidden Logging
address@hidden %**end of header
-
address@hidden Top
-
 
address@hidden 
***************************************************************************
address@hidden Logging
address@hidden Logging
 
 GNUnet is able to log its activity, mostly for the purposes of debugging the
 program at various levels.
@@ -2392,25 +2302,25 @@ Because environment variables are inherited by child 
processes when they are
 launched, starting or re-starting the ARM service with these variables will
 propagate them to all other services.
 
- "GNUNET_LOG" and "GNUNET_FORCE_LOG" variables must contain a specially
- formatted @strong{logging definition} string, which looks like this:@ @code{@
- 
[component];[file];[function];[from_line[-to_line]];address@hidden/component...]}@
- }@ That is, a logging definition consists of definition entries, separated by
- slashes ('/'). If only one entry is present, there is no need to add a slash
- to its end (although it is not forbidden either).@ All definition fields
- (component, file, function, lines and loglevel) are mandatory, but (except for
- the loglevel) they can be empty. An empty field means "match anything". Note
- that even if fields are empty, the semicolon (';') separators must be
- present.@ The loglevel field is mandatory, and must contain one of the log
- level names (ERROR, WARNING, INFO or DEBUG).@ The lines field might contain
- one non-negative number, in which case it matches only one line, or a range
- "from_line-to_line", in which case it matches any line in the interval
- [from_line;to_line] (that is, including both start and end line).@ GNUnet
- mostly defaults component name to the name of the service that is implemented
- in a process ('transport', 'core', 'peerinfo', etc), but logging calls can
- specify custom component names using @code{GNUNET_log_from}.@ File name and
- function name are provided by the compiler (__FILE__ and __FUNCTION__
- built-ins).
+"GNUNET_LOG" and "GNUNET_FORCE_LOG" variables must contain a specially
+formatted @strong{logging definition} string, which looks like this:@ @code{@
+[component];[file];[function];[from_line[-to_line]];address@hidden/component...]}@
+}@ That is, a logging definition consists of definition entries, separated by
+slashes ('/'). If only one entry is present, there is no need to add a slash
+to its end (although it is not forbidden either).@ All definition fields
+(component, file, function, lines and loglevel) are mandatory, but (except for
+the loglevel) they can be empty. An empty field means "match anything". Note
+that even if fields are empty, the semicolon (';') separators must be
+present.@ The loglevel field is mandatory, and must contain one of the log
+level names (ERROR, WARNING, INFO or DEBUG).@ The lines field might contain
+one non-negative number, in which case it matches only one line, or a range
+"from_line-to_line", in which case it matches any line in the interval
+[from_line;to_line] (that is, including both start and end line).@ GNUnet
+mostly defaults component name to the name of the service that is implemented
+in a process ('transport', 'core', 'peerinfo', etc), but logging calls can
+specify custom component names using @code{GNUNET_log_from}.@ File name and
+function name are provided by the compiler (__FILE__ and __FUNCTION__
+built-ins).
 
 Component, file and function fields are interpreted as non-extended regular
 expressions (GNU libc regex functions are used). Matching is case-sensitive, ^
@@ -2426,15 +2336,15 @@ component names (it can't be used in function names and 
file names anyway).@
 @end table
 
 
- Every logging call in GNUnet code will be (at run time) matched against the
- log definitions passed to the process. If a log definition fields are matching
- the call arguments, then the call log level is compared the the log level of
- that definition. If the call log level is less or equal to the definition log
- level, the call is allowed to proceed. Otherwise the logging call is
- forbidden, and nothing is logged. If no definitions matched at all, GNUnet
- will use the global log level or (if a global log level is not specified) will
- default to WARNING (that is, it will allow the call to proceed, if its level
- is less or equal to the global log level or to WARNING).
+Every logging call in GNUnet code will be (at run time) matched against the
+log definitions passed to the process. If a log definition fields are matching
+the call arguments, then the call log level is compared the the log level of
+that definition. If the call log level is less or equal to the definition log
+level, the call is allowed to proceed. Otherwise the logging call is
+forbidden, and nothing is logged. If no definitions matched at all, GNUnet
+will use the global log level or (if a global log level is not specified) will
+default to WARNING (that is, it will allow the call to proceed, if its level
+is less or equal to the global log level or to WARNING).
 
 That is, definitions are evaluated from left to right, and the first matching
 definition is used to allow or deny the logging call. Thus it is advised to
@@ -2454,10 +2364,11 @@ configuration files, only via environment variables.
 
 At the moment GNUnet will stop processing a log definition when it encounters
 an error in definition formatting or an error in regular expression syntax, and
-will not report the failure in any address@hidden Examples @c %**end of header
-
address@hidden Top
+will not report the failure in any way.
 
address@hidden 
***************************************************************************
address@hidden Examples
address@hidden Examples
 
 @table @asis
 
@@ -2487,7 +2398,8 @@ default level).
 -s} Start GNUnet process tree, allowing any logging calls from the components
 that have "transport" in their names, and are made from function that have
 "send" in their names. Everything else will be allowed to be logged only if it
-has WARNING level.  @end table
+has WARNING level.
address@hidden table
 
 
 On Windows, one can use batch files to run GNUnet processes with special
@@ -2496,11 +2408,11 @@ look like this:@ @code{@ set 
GNUNET_FORCE_LOG=;;do_transmit;;DEBUG@ gnunet-arm
 -s@ }@ (note the absence of double quotes in the environment variable
 definition, as opposed to earlier examples, which use the shell).@ Another
 limitation, on Windows, GNUNET_FORCE_LOGFILE @strong{MUST} be set in order to
-GNUNET_FORCE_LOG to address@hidden Log files @c %**end of header
-
address@hidden Top
-
+GNUNET_FORCE_LOG to work.
 
address@hidden 
***************************************************************************
address@hidden Log files
address@hidden Log files
 
 GNUnet can be told to log everything into a file instead of stderr (which is
 the default) using the "--log-file=logfile" or "-l logfile" option. This option
@@ -2513,48 +2425,35 @@ with the name of the service. This is used to keep logs 
from more than one
 service separate, while only specifying one template containing 
"@address@hidden" in
 GLOBAL_POSTFIX.
 
- As part of a secondary file name expansion, the first occurrence of "[]"
- sequence ("left square brace" followed by "right square brace") in the file
- name will be replaced with a process identifier or the process when it
- initializes its logging subsystem. As a result, all processes will log into
- different files. This is convenient for isolating messages of a particular
- process, and prevents I/O races when multiple processes try to write into the
- file at the same time. This expansion is done independently of 
"@address@hidden"
- expansion that ARM service does (see above).
-
- The log file name that is specified via "-l" can contain format characters
- from the 'strftime' function family. For example, "%Y" will be replaced with
- the current year. Using "basename-%Y-%m-%d.log" would include the current
- year, month and day in the log file. If a GNUnet process runs for long enough
- to need more than one log file, it will eventually clean up old log files.
- Currently, only the last three log files (plus the current log file) are
- preserved. So once the fifth log file goes into use (so after 4 days if you
- use "%Y-%m-%d" as above), the first log file will be automatically deleted.
- Note that if your log file name only contains "%Y", then log files would be
- kept for 4 years and the logs from the first year would be deleted once year 5
- begins. If you do not use any date-related string format codes, logs would
- never be automatically deleted by GNUnet.
- @itemize
- @bullet
-
-
address@hidden
-
address@hidden itemize
address@hidden Updated behavior of GNUNET_log
address@hidden %**end of header
-
address@hidden Top
+As part of a secondary file name expansion, the first occurrence of "[]"
+sequence ("left square brace" followed by "right square brace") in the file
+name will be replaced with a process identifier or the process when it
+initializes its logging subsystem. As a result, all processes will log into
+different files. This is convenient for isolating messages of a particular
+process, and prevents I/O races when multiple processes try to write into the
+file at the same time. This expansion is done independently of 
"@address@hidden"
+expansion that ARM service does (see above).
+
+The log file name that is specified via "-l" can contain format characters
+from the 'strftime' function family. For example, "%Y" will be replaced with
+the current year. Using "basename-%Y-%m-%d.log" would include the current
+year, month and day in the log file. If a GNUnet process runs for long enough
+to need more than one log file, it will eventually clean up old log files.
+Currently, only the last three log files (plus the current log file) are
+preserved. So once the fifth log file goes into use (so after 4 days if you
+use "%Y-%m-%d" as above), the first log file will be automatically deleted.
+Note that if your log file name only contains "%Y", then log files would be
+kept for 4 years and the logs from the first year would be deleted once year 5
+begins. If you do not use any date-related string format codes, logs would
+never be automatically deleted by GNUnet.
 
address@hidden 
***************************************************************************
address@hidden Updated behavior of GNUNET_log
address@hidden Updated behavior of GNUNET_log
 
 @itemize
 @bullet
-
-
 @item Bart Polot's blog
-
address@hidden
-
 @end itemize
 
 
@@ -2575,15 +2474,18 @@ new change in GNUNET_log aims to solve these problems.
 @strong{This change requires to @code{./configure} with at least
 @code{--enable-logging=verbose} to see debug messages.}
 
-Here is an example of code with dense debug statements: @example switch
-(restrict_topology) @{ case GNUNET_TESTING_TOPOLOGY_CLIQUE: #if VERBOSE_TESTING
+Here is an example of code with dense debug statements:
address@hidden
+switch (restrict_topology) @{
+case GNUNET_TESTING_TOPOLOGY_CLIQUE: #if VERBOSE_TESTING
 GNUNET_log (GNUNET_ERROR_TYPE_DEBUG, _("Blacklisting all but clique
 topology\n")); #endif unblacklisted_connections = create_clique (pg,
 &remove_connections, BLACKLIST, GNUNET_NO); break; case
 GNUNET_TESTING_TOPOLOGY_SMALL_WORLD_RING: #if VERBOSE_TESTING GNUNET_log
 (GNUNET_ERROR_TYPE_DEBUG, _("Blacklisting all but small world (ring)
 topology\n")); #endif unblacklisted_connections = create_small_world_ring (pg,
-&remove_connections, BLACKLIST); break; @end example
+&remove_connections, BLACKLIST); break;
address@hidden example
 
 
 Pretty hard to follow, huh?
@@ -2593,15 +2495,11 @@ acheive the same behavior. The GNUNET_log and 
GNUNET_log_from macros take care
 of it for you, depending on the configure option:
 @itemize
 @bullet
-
-
 @item If @code{--enable-logging} is set to @code{no}, the binary will contain
 no log messages at all.
-
 @item If @code{--enable-logging} is set to @code{yes}, the binary will contain
 no DEBUG messages, and therefore running with -L DEBUG 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 -L DEBUG or set the DEBUG config option to show them).
@@ -2611,16 +2509,12 @@ neccessary to run with -L DEBUG or set the DEBUG config 
option to show them).
 If you are a developer:
 @itemize
 @bullet
-
-
 @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 code.
 @end itemize
 
-
 Since now activating DEBUG automatically makes it VERBOSE and activates
 @strong{all} debug messages by default, you probably want to use the
 https://gnunet.org/logging functionality to filter only relevant messages. A
@@ -2628,12 +2522,10 @@ suitable configuration could be:@ @code{$ export
 GNUNET_FORCE_LOG="^YOUR_SUBSYSTEM$;;;;DEBUG/;;;;WARNING"}@ Which will behave
 almost like enabling DEBUG in that subsytem before the change. Of course you
 can adapt it to your particular needs, this is only a quick example.
address@hidden Interprocess communication API
address@hidden %**end of header
-
address@hidden Top
-
 
address@hidden 
***************************************************************************
address@hidden Interprocess communication API
address@hidden Interprocess communication API
 
 In GNUnet a variety of new message types might be defined and used in
 interprocess communication, in this tutorial we use the @code{struct
@@ -2641,29 +2533,28 @@ AddressLookupMessage} as a example to introduce how to 
construct our own
 message type in GNUnet and how to implement the message communication between
 service and client.@ (Here, a client uses the @code{struct
 AddressLookupMessage} as a request to ask the server to return the address of
-any other peer connecting to the service.)@settitle Define new message types @c
-%**end of header
-
address@hidden Top
-
+any other peer connecting to the service.)
 
address@hidden 
***************************************************************************
address@hidden Define new message types
address@hidden Define new message types
 
 First of all, you should define the new message type in
address@hidden: @example
address@hidden:
address@hidden
  // Request to look addresses of peers in server.
 #define GNUNET_MESSAGE_TYPE_TRANSPORT_ADDRESS_LOOKUP 29
   // Response to the address lookup request.
 #define GNUNET_MESSAGE_TYPE_TRANSPORT_ADDRESS_REPLY 30
 @end example
address@hidden Define message struct
address@hidden %**end of header
-
address@hidden Top
-
 
address@hidden 
***************************************************************************
address@hidden Define message struct
address@hidden Define message struct
 
 After the type definition, the specified message structure should also be
-described in the header file, e.g. transport.h in our case.  @example
+described in the header file, e.g. transport.h in our case.
address@hidden
 GNUNET_NETWORK_STRUCT_BEGIN
 
 struct AddressLookupMessage @{ struct GNUNET_MessageHeader header; int32_t
@@ -2671,11 +2562,15 @@ numeric_only GNUNET_PACKED; struct 
GNUNET_TIME_AbsoluteNBO timeout; uint32_t
 addrlen GNUNET_PACKED;
  /* followed by 'addrlen' bytes of the actual address, then
     followed by the 0-terminated name of the transport */ @};
-    GNUNET_NETWORK_STRUCT_END @end example
+    GNUNET_NETWORK_STRUCT_END
address@hidden example
 
 
 Please note @code{GNUNET_NETWORK_STRUCT_BEGIN} and @code{GNUNET_PACKED} which
 both ensure correct alignment when sending structs over the network
+
address@hidden 
***************************************************************************
address@hidden Connection between client and server
 @settitle Connection between client and server
 @c %**end of header
 
@@ -2686,11 +2581,15 @@ both ensure correct alignment when sending structs over 
the network
 For typical communication, the connection should be created first, in other
 words, a connection between the client and the service should be
 established.
address@hidden 
***************************************************************************
address@hidden Client setting
 @settitle Client setting
 @c %**end of header
 
 @node Top
 
address@hidden 
***************************************************************************
address@hidden Establish connection
 @settitle Establish connection
 @c %**end of header
 
@@ -2705,6 +2604,8 @@ connected.
 struct GNUNET_CLIENT_Connection *client; client =
 GNUNET_CLIENT_connect ("transport", cfg);
 @end example
address@hidden 
***************************************************************************
address@hidden Initialize request message
 @settitle Initialize request message
 @c %**end of header
 
@@ -2732,6 +2633,8 @@ Note that, here the functions @code{htonl}, @code{htons} 
and
 endian, about the usage of the big/small edian order and the corresponding
 conversion function please refer to Introduction of Big Endian and Little
 Endian.
address@hidden 
***************************************************************************
address@hidden Send request and receive response
 @settitle Send request and receive response
 @c %**end of header
 
@@ -2754,17 +2657,13 @@ arp_ctx);
  the argument @code{address_response_processor} is a function with
  @code{GNUNET_CLIENT_MessageHandler} type, which is used to process the reply
  message from the service.
- @settitle Server Setting
- @c %**end of header
-
address@hidden Top
address@hidden 
***************************************************************************
address@hidden Server Setting
address@hidden Server Setting
 
address@hidden 
***************************************************************************
address@hidden Startup service
 @settitle Startup service
address@hidden %**end of header
-
address@hidden Top
-
-
 
 After receiving the request message, we run a standard GNUnet service startup
 sequence using @code{GNUNET_SERVICE_run}, as follows,
@@ -2774,6 +2673,8 @@ argc, char**argv) @{ GNUNET_SERVICE_run(argc, argv, 
"transport"
 GNUNET_SERVICE_OPTION_NONE, &run, NULL)); @}
 @end example
 
address@hidden 
***************************************************************************
address@hidden Add new handles for specified messages
 @settitle Add new handles for specified messages
 @c %**end of header
 
@@ -2808,6 +2709,8 @@ 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.
address@hidden 
***************************************************************************
address@hidden Process request message
 @settitle Process request message
 @c %**end of header
 
@@ -2848,6 +2751,8 @@ 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 message.
 
address@hidden 
***************************************************************************
address@hidden Response to client
 @settitle Response to client
 @c %**end of header
 
@@ -2876,6 +2781,8 @@ GNUNET_SERVER_transmit_context_run (tc, rtimeout); @end 
example
 
  Note that, there are also a number of other APIs provided to the service to
  send the message.
address@hidden 
***************************************************************************
address@hidden Notification of clients
 @settitle Notification of clients
 @c %**end of header
 
@@ -2908,6 +2815,8 @@ messages to the server.
 @item
 
 @end itemize
address@hidden 
***************************************************************************
address@hidden Conversion between Network Byte Order (Big Endian) and Host Byte 
Order
 @settitle Conversion between Network Byte Order (Big Endian) and Host Byte 
Order
 @c %**end of header
 
@@ -2971,6 +2880,8 @@ time from network byte order.
 @item
 
 @end itemize
address@hidden 
***************************************************************************
address@hidden Cryptography API
 @settitle Cryptography API
 @c %**end of header
 
@@ -3015,6 +2926,8 @@ be considered secure for traditional applications of RSA.
 @item
 
 @end itemize
address@hidden 
***************************************************************************
address@hidden Message Queue API
 @settitle Message Queue API
 @c %**end of header
 
@@ -3146,6 +3059,8 @@ callback. When canceling an envelope, it is not 
necessary@ to call
 @item
 
 @end itemize
address@hidden 
***************************************************************************
address@hidden Service API
 @settitle Service API
 @c %**end of header
 
@@ -3220,6 +3135,8 @@ values before terminating.
 @item
 
 @end itemize
address@hidden 
***************************************************************************
address@hidden Optimizing Memory Consumption of GNUnet's (Multi-) Hash Maps
 @settitle Optimizing Memory Consumption of GNUnet's (Multi-) Hash Maps
 @c %**end of header
 
@@ -3235,6 +3152,8 @@ sometimes responsible for a large share of GNUnet's 
overall memory consumption
 (for some processes, 30% is not uncommon). The following text documents some
 API quirks (and their implications for applications) that were recently
 introduced to minimize the footprint of the hash map.
address@hidden 
***************************************************************************
address@hidden Analysis
 @settitle Analysis
 
 @c %**end of header
@@ -3279,6 +3198,8 @@ just an extreme example: overheads in practice are 
actually sometimes close to
 those highlighted in this example. This is especially true for maps with a
 significant number of entries, as there we tend to really try to keep the
 entries small.
address@hidden 
***************************************************************************
address@hidden Solution
 @settitle Solution
 @c %**end of header
 
@@ -3297,6 +3218,8 @@ entries small.
  within the entry, not just a pointer to a transient location of the key. If
  the client code does not meet these requirements, the result is a dangling
  pointer and undefined behavior of the (multi-)hash map API.
address@hidden 
***************************************************************************
address@hidden Migration
 @settitle Migration
 @c %**end of header
 
@@ -3341,6 +3264,8 @@ If everything was done correctly, you now use about 60 
bytes less memory per
 entry in @code{map}. However, if now (or in the future) any call to @code{put}
 does not ensure that the given key is valid until the entry is removed from the
 map, undefined behavior is likely to be observed.
address@hidden 
***************************************************************************
address@hidden Conclusion
 @settitle Conclusion
 @c %**end of header
 
@@ -3354,6 +3279,8 @@ map, undefined behavior is likely to be observed.
  applications should refrain from enabling the new mode unless the resulting
  performance increase is deemed significant enough. In particular, it should
  generally not be used in new code (wait at least until benchmarks exist).
address@hidden 
***************************************************************************
address@hidden Availability
 @settitle Availability
 @c %**end of header
 
@@ -3373,6 +3300,8 @@ map, undefined behavior is likely to be observed.
 @item
 
 @end itemize
address@hidden 
***************************************************************************
address@hidden The CONTAINER_MDLL API
 @settitle The CONTAINER_MDLL API
 @c %**end of header
 
@@ -3431,6 +3360,8 @@ accessing the "next_XX" and/or "prev_XX" members.
 @item
 
 @end itemize
address@hidden 
***************************************************************************
address@hidden The Automatic Restart Manager (ARM)
 @settitle The Automatic Restart Manager (ARM)
 @c %**end of header
 
@@ -3446,6 +3377,8 @@ planned to incorporate automatic debugging for diagnosing 
service crashes
 providing developers insights about crash reasons. The purpose of this document
 is to give GNUnet developer an idea about how ARM works and how to interact
 with it.
address@hidden 
***************************************************************************
address@hidden Basic functionality
 @settitle Basic functionality
 @c %**end of header
 
@@ -3478,6 +3411,8 @@ a service "resolver", stops the "resolver" then stops 
"ARM".
 @item
 
 @end itemize
address@hidden 
***************************************************************************
address@hidden Key configuration options
 @settitle Key configuration options
 @c %**end of header
 
@@ -3547,6 +3482,8 @@ that are going to run.@
 @item
 
 @end itemize
address@hidden 
***************************************************************************
address@hidden Availability
 @settitle Availability
 @c %**end of header
 
@@ -3592,8 +3529,10 @@ work).
 
 
 @item
-
address@hidden itemize @settitle Reliability @c %**end of header
address@hidden itemize
address@hidden 
***************************************************************************
address@hidden Reliability
address@hidden Reliability
 
 @node Top
 
@@ -3642,6 +3581,8 @@ trying to restart a problematic service.
 @item
 
 @end itemize
address@hidden 
***************************************************************************
address@hidden GNUnet's TRANSPORT Subsystem
 @settitle GNUnet's TRANSPORT Subsystem
 @c %**end of header
 

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