[GNUnet-SVN] [gnunet-texinfo] branch master updated (adcb89c -> b50e281)

[gnunet]

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

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

    from adcb89c  developer.texi: @section, @subsection, @subsubsection for 
chapter "introduction".
     new da84577  developer.texi: more chapters
     new b50e281  developer.texi: Remove dircategory{} for now.

The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 developer.texi | 400 +++++++++++++++------------------------------------------
 1 file changed, 103 insertions(+), 297 deletions(-)

diff --git a/developer.texi b/developer.texi
index 3867eba..6b6ea9e 100644
--- a/developer.texi
+++ b/developer.texi
@@ -28,272 +28,6 @@ A copy of the license is also available from the Free 
Software
 Foundation Web site at @url{http://www.gnu.org/licenses/gpl.html}.
 @end copying
 
address@hidden GNUnet Developer Handbook
address@hidden
-* Introduction
-* C Tutorial
-* Java Tutorial
-* Project Overview
-* Code Overview
-* System Architecture
-* Subsystem stability
-* Naming conventions and coding style guide
-* Include files
-* Binaries
-* logging
-* Configuration
-* Exported Symbols
-* private (library-internal) symbols (including structs and macros)
-* testcases
-* performance tests
-* src/ directories
-* Coding style
-* Build system
-* Developing extensions for GNUnet using the gnunet-ext template
-* Writing testcases
-* GNUnet's TESTING library
-* API
-* Finer control over peer stop
-* Helper functions
-* Testing with multiple processes
-* Performance regression analysis with Gauger
-* GNUnet's TESTBED Subsystem
-* Supported Topologies
-* Hosts file format
-* Topology file format
-* Testbed Barriers
-* Automatic large-scale deployment of GNUnet in the PlanetLab testbed
-* PlanetLab Automation for Fedora8 nodes
-* Install buildslave on PlanetLab nodes running fedora core 8
-* Setup a new PlanetLab testbed using GPLMT
-* Why do i get an ssh error when using the regex profiler?
-* TESTBED Caveats
-* CORE must be started
-* ATS must want the connections
-* libgnunetutil
-* Logging
-* Examples
-* Log files
-* Updated behavior of GNUNET_log
-* Interprocess communication API
-* Define new message types
-* Define message struct
-* Connection between client and server
-* Client setting
-* Establish connection
-* Initialize request message
-* Send request and receive response
-* Server Setting
-* Startup service
-* Add new handles for specified messages
-* Process request message
-* Response to client
-* Notification of clients
-* Conversion between Network Byte Order (Big Endian) and Host Byte Order
-* Cryptography API
-* Message Queue API
-* Service API
-* Optimizing Memory Consumption of GNUnet's (Multi-) Hash Maps
-* Analysis
-* Solution
-* Migration
-* Conclusion
-* Availability
-* The CONTAINER_MDLL API
-* The Automatic Restart Manager (ARM)
-* Basic functionality
-* Key configuration options
-* Availability
-* Reliability
-* GNUnet's TRANSPORT Subsystem
-* Address validation protocol
-* NAT library
-* Distance-Vector plugin
-* SMTP plugin
-* Why use SMTP for a peer-to-peer transport?
-* How does it work?
-* How do I configure my peer?
-* How do I test if it works?
-* How fast is it?
-* Bluetooth plugin
-* What do I need to use the Bluetooth plugin transport?
-* How does it work?
-* What possible errors should I be aware of?
-* How do I configure my peer?
-* How can I test it?
-* The implementation of the Bluetooth transport plugin
-* Linux functionality
-* THE INITIALIZATION
-* THE LOOP
-* Detailes about the broadcast implementation
-* Windows functionality
-* Pending features
-* WLAN plugin
-* The ATS Subsystem
-* GNUnet's CORE Subsystem
-* Limitations
-* When is a peer "connected"?
-* libgnunetcore
-* The CORE Client-Service Protocol
-* Setup
-* Notifications
-* Sending
-* The CORE Peer-to-Peer Protocol
-* Creating the EphemeralKeyMessage
-* Establishing a connection
-* Encryption and Decryption
-* Type maps
-* GNUnet's CADET subsystem
-* libgnunetcadet
-* GNUnet's NSE subsystem
-* Motivation
-* Security
-* Principle
-* Example
-* Algorithm
-* Target value
-* Timing
-* Controlled Flooding
-* Calculating the estimate
-* libgnunetnse
-* Results
-* Examples
-* The NSE Client-Service Protocol
-* The NSE Peer-to-Peer Protocol
-* GNUnet's HOSTLIST subsystem
-* HELLOs
-* Overview for the HOSTLIST subsystem
-* Features
-* Limitations
-* Interacting with the HOSTLIST daemon
-* Hostlist security: address validation
-* The HOSTLIST daemon
-* The HOSTLIST server
-* The HTTP Server
-* Advertising the URL
-* The HOSTLIST client
-* Bootstrapping
-* Learning
-* Usage
-* GNUnet's IDENTITY subsystem
-* libgnunetidentity
-* Connecting to the service
-* Operations on Egos
-* Convenience API to lookup a single ego
-* Associating egos with service functions
-* The IDENTITY Client-Service Protocol
-* GNUnet's NAMESTORE Subsystem
-* libgnunetnamestore
-* Editing Zone Information
-* Iterating Zone Information
-* Monitoring Zone Information
-* GNUnet's PEERINFO subsystem
-* Features
-* Limitations
-* Peer Information
-* Startup
-* Managing Information
-* Obtaining Information
-* The PEERINFO Client-Service Protocol
-* libgnunetpeerinfo
-* Connecting to the Service
-* Adding Information
-* Obtaining Information
-* GNUnet's PEERSTORE subsystem
-* Functionality
-* Architecture
-* libgnunetpeerstore
-* GNUnet's SET Subsystem
-* Local Sets
-* Set Modifications
-* Set Operations
-* Result Elements
-* libgnunetset
-* Sets
-* Listeners
-* Operations
-* Supplying a Set
-* The Result Callback
-* The SET Client-Service Protocol
-* Creating Sets
-* Listeners
-* Initiating Operations
-* Modifying Sets
-* Results and Operation Status
-* Iterating Sets
-* The SET-Intersection Peer-to-Peer Protocol
-* The Bloom filter exchange
-* Salt
-* The SET-Union Peer-to-Peer Protocol
-* GNUnet's STATISTICS subsystem
-* libgnunetstatistics
-* Statistics retrieval
-* Setting statistics and updating them
-* Watches
-* The STATISTICS Client-Service Protocol.
-* Statistics retrieval
-* Setting and updating statistics
-* Watching for updates
-* GNUnet's Distributed Hash Table (DHT)
-* Block library and plugins
-* What is a Block?
-* The API of libgnunetblock
-* Queries
-* Sample Code
-* Conclusion
-* libgnunetdht
-* GET
-* PUT
-* MONITOR
-* DHT Routing Options
-* The DHT Client-Service Protocol
-* PUTting data into the DHT
-* GETting data from the DHT
-* Monitoring the DHT
-* The DHT Peer-to-Peer Protocol
-* Routing GETs or PUTs
-* PUTting data into the DHT
-* GETting data from the DHT
-* The GNU Name System (GNS)
-* libgnunetgns
-* Looking up records
-* Accessing the records
-* Creating records
-* Future work
-* libgnunetgnsrecord
-* Value handling
-* Type handling
-* GNS plugins
-* The GNS Client-Service Protocol
-* Hijacking the DNS-Traffic using gnunet-service-dns
-* Network Setup Details
-* Serving DNS lookups via GNS on W32
-* The GNS Namecache
-* libgnunetnamecache
-* The NAMECACHE Client-Service Protocol
-* Lookup
-* Store
-* The NAMECACHE Plugin API
-* Lookup
-* Store
-* The REVOCATION Subsystem
-* Dissemination
-* Revocation Message: Design Requirements
-* libgnunetrevocation
-* Querying for revoked keys
-* Preparing revocations
-* Issuing revocations
-* The REVOCATION Client-Service Protocol
-* The REVOCATION Peer-to-Peer Protocol
-* GNUnet's File-sharing (FS) Subsystem
-* Encoding for Censorship-Resistant Sharing (ECRS)
-* Namespace Advertisements
-* KSBlocks
-* File-sharing persistence directory structure
-* GNUnet's REGEX Subsystem
-* How to run the regex profiler
address@hidden direntry
-
 @titlepage
 @title GNUnet Developer Handbook
 @author The GNUnet Developers
@@ -1160,7 +894,7 @@ GNUnet.
 
 @c ***************************************************************************
 @node GNUnet's TESTING library
address@hidden GNUnet's TESTING library
address@hidden GNUnet's TESTING library
 
 The TESTING library is used for writing testcases which involve starting a
 single or multiple peers. While peers can also be started by testcases using
@@ -1189,8 +923,8 @@ only creates peers on the localhost, however by using 
TESTBED testcases can
 benefit from creating peers across multiple hosts.
 
 @c ***************************************************************************
address@hidden API
 @node API
address@hidden API
 
 TESTING abstracts a group of peers as a TESTING system. All peers in a system
 have common hostname and no two services of these peers have a same port or a
@@ -1237,8 +971,8 @@ paths in allocated in its configuration are reclaimed for 
usage in new
 peers.
 
 @c ***************************************************************************
address@hidden Finer control over peer stop
 @node Finer control over peer stop
address@hidden Finer control over peer stop
 
 Using @code{GNUNET_TESTING_peer_stop()} is normally fine for testcases.
 However, calling this function for each peer is inefficient when trying to
@@ -1264,7 +998,7 @@ when the peer is stopped.
 
 @c ***************************************************************************
 @node Helper functions
address@hidden Helper functions
address@hidden Helper functions
 
 Most of the testcases can benefit from an abstraction which configures a peer
 and starts it. This is provided by the function
@@ -1281,7 +1015,7 @@ given service is run.
 
 @c ***************************************************************************
 @node Testing with multiple processes
address@hidden Testing with multiple processes
address@hidden Testing with multiple processes
 
 When testing GNUnet, the splitting of the code into a services and clients
 often complicates testing. The solution to this is to have the testcase fork
@@ -1315,7 +1049,7 @@ the plugin directly.
 
 @c ***************************************************************************
 @node Performance regression analysis with Gauger
address@hidden Performance regression analysis with Gauger
address@hidden Performance regression analysis with Gauger
 
 To help avoid performance regressions, GNUnet uses Gauger. Gauger is a simple
 logging tool that allows remote hosts to send performance data to a central
@@ -1377,7 +1111,7 @@ latest stable release or check out Gauger's Subversion 
repository.
 
 @c ***************************************************************************
 @node GNUnet's TESTBED Subsystem
address@hidden GNUnet's TESTBED Subsystem
address@hidden GNUnet's TESTBED Subsystem
 
 The TESTBED subsystem facilitates testing and measuring of multi-peer
 deployments on a single host or over multiple hosts.
@@ -1462,7 +1196,7 @@ linking with -lgnunettestbed.
 
 @c ***************************************************************************
 @node Supported Topologies
address@hidden Supported Topologies
address@hidden Supported Topologies
 
 While testing multi-peer deployments, it is often needed that the peers are
 connected in some topology. This requirement is addressed by the function
@@ -1546,7 +1280,7 @@ See Topology file format for the format of this file.
 
 @c ***************************************************************************
 @node Hosts file format
address@hidden Hosts file format
address@hidden Hosts file format
 
 The testbed API offers the function GNUNET_TESTBED_hosts_load_from_file() to
 load from a given file details about the hosts which testbed can use for
@@ -1573,7 +1307,7 @@ numerical addresses as hostnames whenever possible.
 
 @c ***************************************************************************
 @node Topology file format
address@hidden Topology file format
address@hidden Topology file format
 
 A topology file describes how peers are to be connected. It should adhere to
 the following format for testbed to parse it correctly.
@@ -1588,7 +1322,7 @@ For example, the following file will result in 5 overlay 
connections: [2->1],
 
 @c ***************************************************************************
 @node Testbed Barriers
address@hidden Testbed Barriers
address@hidden Testbed Barriers
 
 The testbed subsystem's barriers API facilitates coordination among the peers
 run by the testbed and the experiment driver. The concept is similar to the
@@ -1639,7 +1373,7 @@ by @code{GNUNET_TESTBED_barrier_wait()}.
 
 @c ***************************************************************************
 @node Implementation
address@hidden Implementation
address@hidden Implementation
 
 Since barriers involve coordination between experiment driver and peers, the
 barrier service in the testbed controller is split into two components. The
@@ -1703,8 +1437,8 @@ is reached by all the controllers and the downward 
propagation is for
 triggering that the barrier is crossed.
 
 @c ***************************************************************************
address@hidden Automatic large-scale deployment of GNUnet in the PlanetLab 
testbed
address@hidden Automatic large-scale deployment of GNUnet in the PlanetLab 
testbed
address@hidden Automatic large-scale deployment of GNUnet in the PlanetLab 
testbed
address@hidden Automatic large-scale deployment of GNUnet in the PlanetLab 
testbed
 
 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
@@ -1719,12 +1453,14 @@ Please also check 
@uref{https://gnunet.org/installation-fedora8-svn} and@
 instructions how to install GNUnet on a PlanetLab node.
 
 @c ***************************************************************************
address@hidden PlanetLab Automation for Fedora8 nodes
 @node PlanetLab Automation for Fedora8 nodes
address@hidden PlanetLab Automation for Fedora8 nodes
 
 @c ***************************************************************************
address@hidden Install buildslave on PlanetLab nodes running fedora core 8
 @node Install buildslave on PlanetLab nodes running fedora core 8
address@hidden Install buildslave on PlanetLab nodes running fedora core 8
address@hidden ** Actually this is a subsubsubsection, but must be fixed 
differently
address@hidden ** as subsubsection is the lowest.
 
 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
@@ -1749,8 +1485,8 @@ 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!
 
 @c ***************************************************************************
address@hidden Setup a new PlanetLab testbed using GPLMT
 @node Setup a new PlanetLab testbed using GPLMT
address@hidden Setup a new PlanetLab testbed using GPLMT
 
 @itemize @bullet
 @item Get a new slice and assign nodes
@@ -1795,8 +1531,8 @@ Use @code{buildbot start <basedir>} to start the server
 @end itemize
 
 @c ***************************************************************************
address@hidden Why do i get an ssh error when using the regex profiler?
 @node 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
@@ -1819,14 +1555,14 @@ login, then you should be good to go.
 
 @c ***************************************************************************
 @node TESTBED Caveats
address@hidden TESTBED Caveats
address@hidden TESTBED Caveats
 
 This section documents a few caveats when using the GNUnet testbed
 subsystem.
 
 @c ***************************************************************************
address@hidden CORE must be started
 @node 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
@@ -1839,8 +1575,8 @@ issue largely arises if users try to over-optimize by not 
starting any services
 with FORCESTART.
 
 @c ***************************************************************************
address@hidden ATS must want the connections
 @node 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
@@ -1897,7 +1633,7 @@ porting of GNUnet easier.
 
 @c ***************************************************************************
 @node Logging
address@hidden Logging
address@hidden Logging
 
 GNUnet is able to log its activity, mostly for the purposes of debugging the
 program at various levels.
@@ -2056,7 +1792,7 @@ will not report the failure in any way.
 
 @c ***************************************************************************
 @node Examples
address@hidden Examples
address@hidden Examples
 
 @table @asis
 
@@ -2100,7 +1836,7 @@ GNUNET_FORCE_LOG to work.
 
 @c ***************************************************************************
 @node Log files
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
@@ -2137,7 +1873,7 @@ never be automatically deleted by GNUnet.
 
 @c ***************************************************************************
 @node Updated behavior of GNUNET_log
address@hidden Updated behavior of GNUNET_log
address@hidden Updated behavior of GNUNET_log
 
 It's currently quite common to see constructions like this all over the code:
 @example
@@ -2205,8 +1941,8 @@ 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.
 
 @c ***************************************************************************
address@hidden Interprocess communication API
address@hidden Interprocess communication API
address@hidden Interprocess communication API (IPC)
address@hidden Interprocess communication API (IPC)
 
 In GNUnet a variety of new message types might be defined and used in
 interprocess communication, in this tutorial we use the @code{struct
@@ -2218,7 +1954,7 @@ any other peer connecting to the service.)
 
 @c ***************************************************************************
 @node Define new message types
address@hidden Define new message types
address@hidden Define new message types
 
 First of all, you should define the new message type in
 @code{gnunet_protocols.h}:
@@ -2231,7 +1967,7 @@ First of all, you should define the new message type in
 
 @c ***************************************************************************
 @node Define message struct
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.
@@ -2252,6 +1988,7 @@ both ensure correct alignment when sending structs over 
the network
 
 @c ***************************************************************************
 @node Connection between client and server
address@hidden Connection between client and server
 @c %**end of header
 
 For typical communication, the connection should be created first, in other
@@ -2259,10 +1996,12 @@ words, a connection between the client and the service 
should be
 established.
 @c ***************************************************************************
 @node Client setting
address@hidden Client setting
 @c %**end of header
 
 @c ***************************************************************************
 @node Establish connection
address@hidden Establish connection
 @c %**end of header
 
 At first, on the client side, the underlying API is employed to create a new
@@ -2275,6 +2014,7 @@ GNUNET_CLIENT_connect ("transport", cfg);
 
 @c ***************************************************************************
 @node Initialize request message
address@hidden Initialize request message
 @c %**end of header
 
 When the connection is ready, we initialize the message. In this step, all the
@@ -2299,6 +2039,7 @@ Endian.
 
 @c ***************************************************************************
 @node Send request and receive response
address@hidden Send request and receive response
 @c %**end of header
 
 Next, the client would send the constructed message as a request to the service
@@ -2318,9 +2059,11 @@ message from the service.
 
 @c ***************************************************************************
 @node Server Setting
address@hidden Server Setting
 
 @c ***************************************************************************
 @node Startup service
address@hidden Startup service
 
 After receiving the request message, we run a standard GNUnet service startup
 sequence using @code{GNUNET_SERVICE_run}, as follows,
@@ -2332,12 +2075,16 @@ GNUNET_SERVICE_OPTION_NONE, &run, NULL)); @}
 
 @c ***************************************************************************
 @node Add new handles for specified messages
address@hidden Add new handles for specified messages
 @c %**end of header
 
 in the function above the argument @code{run} is used to initiate transport
-service,and defined like this: @example static void run (void *cls, struct
+service,and defined like this:
address@hidden
+static void run (void *cls, struct
 GNUNET_SERVER_Handle *serv, const struct GNUNET_CONFIGURATION_Handle *cfg) @{
-GNUNET_SERVER_add_handlers (serv, handlers); @} @end example
+GNUNET_SERVER_add_handlers (serv, handlers); @}
address@hidden example
 
 
 Here, @code{GNUNET_SERVER_add_handlers} must be called in the run function to
@@ -2366,6 +2113,7 @@ can be set. In addition, the terminator sign depicted as 
@address@hidden, NULL, 0,
 
 @c ***************************************************************************
 @node Process request message
address@hidden Process request message
 @c %**end of header
 
 After the initialization of transport service, the request message would be
@@ -2404,6 +2152,7 @@ In comparison to the aforementioned situation, when the 
argument is equal to
 
 @c ***************************************************************************
 @node Response to client
address@hidden Response to client
 @c %**end of header
 
 Once the processing of current request is done, the server should give the
@@ -2433,6 +2182,7 @@ send the message.
 
 @c ***************************************************************************
 @node Notification of clients
address@hidden Notification of clients
 @c %**end of header
 
 Often a service needs to (repeatedly) transmit notifications to a client or a
@@ -2456,6 +2206,8 @@ messages to the server.
 
 @c ***************************************************************************
 @node Conversion between Network Byte Order (Big Endian) and Host Byte Order
address@hidden Conversion between Network Byte Order (Big Endian) and Host Byte 
Order
address@hidden %** subsub? it's a referenced page on the ipc document.
 @c %**end of header
 
 Here we can simply comprehend big endian and little endian as Network Byte
@@ -2509,6 +2261,7 @@ time from network byte order.
 
 @c ***************************************************************************
 @node Cryptography API
address@hidden Cryptography API
 @c %**end of header
 
 The gnunetutil APIs provides the cryptographic primitives used in GNUnet.
@@ -2544,6 +2297,7 @@ be considered secure for traditional applications of RSA.
 
 @c ***************************************************************************
 @node Message Queue API
address@hidden Message Queue API
 @c %**end of header
 
 @strong{ Introduction }@ Often, applications need to queue messages that are to
@@ -2667,6 +2421,7 @@ callback. When canceling an envelope, it is not 
necessary@ to call
 
 @c ***************************************************************************
 @node Service API
address@hidden Service API
 @c %**end of header
 
 Most GNUnet code lives in the form of services. Services are processes that
@@ -2732,6 +2487,7 @@ values before terminating.
 
 @c ***************************************************************************
 @node Optimizing Memory Consumption of GNUnet's (Multi-) Hash Maps
address@hidden Optimizing Memory Consumption of GNUnet's (Multi-) Hash Maps
 @c %**end of header
 
 A commonly used data structure in GNUnet is a (multi-)hash map. It is most
@@ -2745,6 +2501,7 @@ introduced to minimize the footprint of the hash map.
 
 @c ***************************************************************************
 @node Analysis
address@hidden Analysis
 @c %**end of header
 
 The main reason for the "excessive" memory consumption by the hash map is that
@@ -2789,6 +2546,7 @@ significant number of entries, as there we tend to really 
try to keep the
 entries small.
 @c ***************************************************************************
 @node Solution
address@hidden Solution
 @c %**end of header
 
 The solution that has now been implemented is to @strong{optionally} allow the
@@ -2804,6 +2562,7 @@ the client code does not meet these requirements, the 
result is a dangling
 pointer and undefined behavior of the (multi-)hash map API.
 @c ***************************************************************************
 @node Migration
address@hidden Migration
 @c %**end of header
 
 To use the new feature, first check that the values contain the respective key
@@ -2846,6 +2605,7 @@ does not ensure that the given key is valid until the 
entry is removed from the
 map, undefined behavior is likely to be observed.
 @c ***************************************************************************
 @node Conclusion
address@hidden Conclusion
 @c %**end of header
 
 The new optimization can is often applicable and can result in a reduction in
@@ -2856,6 +2616,7 @@ performance increase is deemed significant enough. In 
particular, it should
 generally not be used in new code (wait at least until benchmarks exist).
 @c ***************************************************************************
 @node Availability
address@hidden Availability
 @c %**end of header
 
 The new multi hash map code was committed in SVN 24319 (will be in GNUnet
@@ -2866,6 +2627,7 @@ by 20-30% due to this change.
 
 @c ***************************************************************************
 @node The CONTAINER_MDLL API
address@hidden The CONTAINER_MDLL API
 @c %**end of header
 
 This text documents the GNUNET_CONTAINER_MDLL API. The GNUNET_CONTAINER_MDLL
@@ -2921,6 +2683,7 @@ accessing the "next_XX" and/or "prev_XX" members.
 
 @c ***************************************************************************
 @node The Automatic Restart Manager (ARM)
address@hidden The Automatic Restart Manager (ARM)
 @c %**end of header
 
 GNUnet's Automated Restart Manager (ARM) is the GNUnet service responsible for
@@ -2934,6 +2697,7 @@ with it.
 
 @c ***************************************************************************
 @node Basic functionality
address@hidden Basic functionality
 @c %**end of header
 
 @itemize @bullet
@@ -2956,6 +2720,7 @@ a service "resolver", stops the "resolver" then stops 
"ARM".
 
 @c ***************************************************************************
 @node Key configuration options
address@hidden Key configuration options
 @c %**end of header
 
 Configurations for ARM and services should be available in a .conf file (As an
@@ -3015,6 +2780,7 @@ that are going to run.@
 
 @c ***************************************************************************
 @node Availability
address@hidden Availability
 @c %**end of header
 
 As mentioned before, one of the features provided by ARM is starting services
@@ -3053,6 +2819,7 @@ work).
 
 @c ***************************************************************************
 @node Reliability
address@hidden Reliability
 
 One of the features provided by ARM, is the automatic restart of crashed
 services.@ ARM needs to know which of the running services died. Function
@@ -3093,6 +2860,7 @@ trying to restart a problematic service.
 
 @c ***************************************************************************
 @node GNUnet's TRANSPORT Subsystem
address@hidden GNUnet's TRANSPORT Subsystem
 @c %**end of header
 
 This chapter documents how the GNUnet transport subsystem works. The GNUnet
@@ -3145,6 +2913,7 @@ Note that the term "clients" in the list above really 
refers to the GNUnet-CORE
 service, as CORE is typically the only client of the transport service.
 
 @node Address validation protocol
address@hidden Address validation protocol
 @c %**end of header
 
 This section documents how the GNUnet transport service validates connections
@@ -3199,6 +2968,7 @@ and uses an expiration time for the signature (but those 
are almost
 implementation details).
 
 @node NAT library
address@hidden NAT library
 @c %**end of header
 
 The goal of the GNUnet NAT library is to provide a general-purpose API for NAT
@@ -3242,6 +3012,7 @@ and then contact a @code{gnunet-nat-server} (running by 
default on
 easy to test if the current NAT configuration is valid.
 
 @node Distance-Vector plugin
address@hidden Distance-Vector plugin
 @c %**end of header
 
 The Distance Vector (DV) transport is a transport mechanism that allows peers
@@ -3298,6 +3069,7 @@ receives this message, unwraps the original message, and 
delivers it to Carol
 as though it came directly from Alice.
 
 @node SMTP plugin
address@hidden SMTP plugin
 @c %**end of header
 
 This page describes the new SMTP transport plugin for GNUnet as it exists in
@@ -3315,6 +3087,7 @@ performance results presented are quite old and maybe 
outdated at this point.
 @end itemize
 
 @node Why use SMTP for a peer-to-peer transport?
address@hidden Why use SMTP for a peer-to-peer transport?
 @c %**end of header
 
 There are many reasons why one would not want to use SMTP:
@@ -3347,6 +3120,7 @@ to a peer outside of the private network. Even an 
extraordinary overhead for
 this first message would be irrelevant in this type of situation.
 
 @node How does it work?
address@hidden How does it work?
 @c %**end of header
 
 When a GNUnet peer needs to send a message to another GNUnet peer that has
@@ -3359,6 +3133,7 @@ over time. This makes it impossible to censor GNUnet 
E-mail messages by
 searching for a generic filter.
 
 @node How do I configure my peer?
address@hidden How do I configure my peer?
 @c %**end of header
 
 First, you need to configure @code{procmail} to filter your inbound E-mail for
@@ -3397,6 +3172,7 @@ e.g. just one hour. For this, set @code{HELLOEXPIRES} to 
@code{1} in the
 
 This should be it, but you may probably want to test it first.@
 @node How do I test if it works?
address@hidden How do I test if it works?
 @c %**end of header
 
 Any transport can be subjected to some rudimentary tests using the
@@ -3417,6 +3193,7 @@ test will only work if you have configured the transport 
to send and receive
 messages.
 
 @node How fast is it?
address@hidden How fast is it?
 @c %**end of header
 
 We have measured the performance of the UDP, TCP and SMTP transport layer
@@ -3477,6 +3254,7 @@ the throughput to 13 kbps as figure smtp-MTUs shows. Our 
research paper) has
 some more details on the benchmarking results.
 
 @node Bluetooth plugin
address@hidden Bluetooth plugin
 @c %**end of header
 
 This page describes the new Bluetooth transport plugin for GNUnet. The plugin
@@ -3491,6 +3269,7 @@ have any questions or problems just post them here or ask 
on the IRC channel.
 @end itemize
 
 @node What do I need to use the Bluetooth plugin transport?
address@hidden What do I need to use the Bluetooth plugin transport?
 @c %**end of header
 
 If you are a Linux user and you want to use the Bluetooth transport plugin you
@@ -3513,6 +3292,7 @@ Bluetooth Stack supports only the RFCOMM protocol so we 
cannot turn on your
 device programatically!
 
 @node How does it work?
address@hidden How does it work?
 @c %**end of header
 
 The Bluetooth transport plugin uses virtually the same code as the WLAN plugin
@@ -3540,6 +3320,7 @@ Once in a while the device will make an inquiry scan to 
discover the nearby
 devices and it will send them randomly HELLO messages for peer discovery.
 
 @node What possible errors should I be aware of?
address@hidden What possible errors should I be aware of?
 @c %**end of header
 
 @emph{This section is dedicated for Linux users}
@@ -3575,6 +3356,7 @@ device and to send some particular commands to it.
 @end itemize
 
 @node How do I configure my peer?
address@hidden How do I configure my peer?
 @c %**end of header
 
 On Linux, you just have to be sure that the interface name corresponds to the
@@ -3605,6 +3387,7 @@ should do is to add @emph{bluetooth} on the plugins list 
of the transport
 service.
 
 @node How can I test it?
address@hidden How can I test it?
 @c %**end of header
 
 If you have two Bluetooth devices on the same machine which use Linux you
@@ -3647,6 +3430,7 @@ Another way to test the plugin functionality is to create 
your own application
 which will use the GNUnet framework with the Bluetooth transport service.
 
 @node The implementation of the Bluetooth transport plugin
address@hidden The implementation of the Bluetooth transport plugin
 @c %**end of header
 
 This page describes the implementation of the Bluetooth transport plugin.
@@ -3668,6 +3452,7 @@ platforms.
 @end itemize
 
 @node Linux functionality
address@hidden Linux functionality
 @c %**end of header
 
 In order to implement the plugin functionality on Linux I used the BlueZ
@@ -3679,6 +3464,7 @@ interface) and is separated in two stages:
 @c %** 'THE INITIALIZATION' should be in bigger letters or stand out, not
 @c %** starting a new section?
 @node THE INITIALIZATION
address@hidden THE INITIALIZATION
 
 @itemize @bullet
 @item first, it checks if we have root privilegies (@emph{Remember that we need
@@ -3715,6 +3501,7 @@ suitable error}
 
 @c %** Same as for @node entry above
 @node THE LOOP
address@hidden THE LOOP
 
 The helper binary uses a list where it saves all the connected neighbour
 devices (@emph{neighbours.devices}) and two buffers (@emph{write_pout} and
@@ -3758,6 +3545,7 @@ fails again, then it skips the message.}
 transport Bluetooth plugin has support for @strong{broadcast messages}.}
 
 @node Details about the broadcast implementation
address@hidden Details about the broadcast implementation
 @c %**end of header
 
 First I want to point out that the broadcast functionality for the CONTROL
@@ -3801,6 +3589,7 @@ to connect to it and in case of success we save the 
address and the socket on
 the list. If we are already connected to that device we simply use the socket.
 
 @node Windows functionality
address@hidden Windows functionality
 @c %**end of header
 
 For Windows I decided to use the Microsoft Bluetooth stack which has the
@@ -3853,6 +3642,7 @@ Also, currently on Windows the Bluetooth plugin doesn't 
have support for
 broadcast messages. When it receives a broadcast message it will skip it.
 
 @node Pending features
address@hidden Pending features
 @c %**end of header
 
 @itemize @bullet
@@ -3868,12 +3658,14 @@ I could improve the implementation you are welcome to 
comment or to contact
 me.
 
 @node WLAN plugin
address@hidden WLAN plugin
 @c %**end of header
 
 This section documents how the wlan transport plugin works. Parts which are not
 implemented yet or could be better implemented are described at the end.
 
 @node The ATS Subsystem
address@hidden The ATS Subsystem
 @c %**end of header
 
 ATS stands for "automatic transport selection", and the function of ATS in
@@ -3894,6 +3686,7 @@ strategies which differ significantly in their 
performance and maturity, and it
 is still unclear if any particular plugin is generally superior.
 
 @node GNUnet's CORE Subsystem
address@hidden GNUnet's CORE Subsystem
 @c %**end of header
 
 The CORE subsystem in GNUnet is responsible for securing link-layer
@@ -3923,6 +3716,7 @@ keys)
 @end itemize
 
 @node Limitations
address@hidden Limitations
 @c %**end of header
 
 CORE does not perform @uref{http://en.wikipedia.org/wiki/Routing, routing};
@@ -3953,6 +3747,7 @@ expected to process messages at line-speed. If flow 
control is needed,
 applications should use the CADET service.
 
 @node When is a peer "connected"?
address@hidden When is a peer "connected"?
 @c %**end of header
 
 In addition to the security features mentioned above, CORE also provides one
@@ -3981,6 +3776,7 @@ connecting peers before exchanging information about 
supported message types
 and notifying applications about the new connection.
 
 @node libgnunetcore
address@hidden libgnunetcore
 @c %**end of header
 
 The CORE API (defined in @code{gnunet_core_service.h}) is the basic messaging
@@ -4041,12 +3837,14 @@ disconnect events for all existing connections. Once 
the connections are
 re-established, the applications will be receive matching connect events.
 
 @node The CORE Client-Service Protocol
address@hidden The CORE Client-Service Protocol
 @c %**end of header
 
 This section describes the protocol between an application using the CORE
 service (the client) and the CORE service process itself.
 
 @node Setup
address@hidden Setup
 @c %**end of header
 
 When a client connects to the CORE service, it first sends a
@@ -4078,6 +3876,7 @@ The CORE service responds to the @code{InitMessage} with 
an
 CORE and the client can send messages.
 
 @node Notifications
address@hidden Notifications
 @c %**end of header
 
 The CORE will send @code{ConnectNotifyMessage}s and
@@ -4092,6 +3891,7 @@ for the message type) is used to notify clients 
monitoring outbound messages;
 here, the peer identity given is that of the receiver.
 
 @node Sending
address@hidden Sending
 @c %**end of header
 
 When a client wants to transmit a message, it first requests a transmission
@@ -4109,9 +3909,11 @@ contain a "unique" request ID (based on a counter 
incremented by the client
 for each request).
 
 @node The CORE Peer-to-Peer Protocol
address@hidden The CORE Peer-to-Peer Protocol
 @c %**end of header
 
 @node Creating the EphemeralKeyMessage
address@hidden Creating the EphemeralKeyMessage
 @c %**end of header
 
 When the CORE service starts, each peer creates a fresh ephemeral (ECC)
@@ -4152,6 +3954,7 @@ using the new ephemeral key
 @end table
 
 @node Establishing a connection
address@hidden Establishing a connection
 @c %**end of header
 
 Peers begin their interaction by sending a @code{EphemeralKeyMessage} to the
@@ -4167,6 +3970,7 @@ receiving a @code{PongMessage} check the challenge, and 
if it matches set the
 connection to @code{KX_STATE_UP}.
 
 @node Encryption and Decryption
address@hidden Encryption and Decryption
 @c %**end of header
 
 All functions related to the key exchange and encryption/decryption of
@@ -4192,6 +3996,7 @@ ephemeral key changes every 12h, a peer would not even be 
able to decrypt
 messages older than 12h.
 
 @node Type maps
address@hidden Type maps
 @c %**end of header
 
 Once an encrypted connection has been established, peers begin to exchange
@@ -4224,6 +4029,7 @@ the correct hash of the type map) is not received, the 
sender will retransmit
 the type map (with exponential back-off).
 
 @node GNUnet's CADET subsystem
address@hidden GNUnet's CADET subsystem
 @c %**end of header
 
 The CADET subsystem in GNUnet is responsible for secure end-to-end

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