[GNUnet-SVN] [gnunet-texinfo] branch master updated: developer.texi: Mostly complete structure of chapters

[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 3b5c914  developer.texi: Mostly complete structure of chapters
3b5c914 is described below

commit 3b5c914c808e571bafe922092b7b5b9c1384aca2
Author: ng0 <address@hidden>
AuthorDate: Fri Feb 17 16:58:14 2017 +0000

    developer.texi: Mostly complete structure of chapters
---
 developer.texi | 139 +++++++++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 130 insertions(+), 9 deletions(-)

diff --git a/developer.texi b/developer.texi
index 8f36558..b30da76 100644
--- a/developer.texi
+++ b/developer.texi
@@ -4664,6 +4664,7 @@ For more information on how to configure the HOSTLIST 
subsystem see the
 installation handbook:@ Configuring the hostlist to bootstrap@ Configuring your
 peer to provide a hostlist
 
address@hidden GNUnet's IDENTITY subsystem
 @node GNUnet's IDENTITY subsystem
 @c %**end of header
 
@@ -4706,9 +4707,11 @@ fixed and known to everyone. Thus, anyone can perform 
actions as anonymous.
 This can be useful as with this trick, code does not have to contain a special
 case to distinguish between anonymous and pseudonymous egos.
 
address@hidden libgnunetidentity
 @node libgnunetidentity
 @c %**end of header
 
address@hidden Connecting to the service
 @node Connecting to the service
 @c %**end of header
 
@@ -4741,6 +4744,7 @@ The ego handle passed to the callback remains valid until 
the callback is
 invoked with a name of NULL, so it is safe to store a reference to the ego's
 handle.
 
address@hidden Operations on Egos
 @node Operations on Egos
 @c %**end of header
 
@@ -4761,6 +4765,7 @@ respective continuations would be called. It is not 
guaranteed that the
 operation will not be completed anyway, only the continuation will no longer be
 called.
 
address@hidden The anonymous Ego
 @node The anonymous Ego
 @c %**end of header
 
@@ -4772,6 +4777,7 @@ signatures (for example, to avoid a special path in the 
code). The anonymous
 ego is always valid and accessing it does not require a connection to the
 identity service.
 
address@hidden Convenience API to lookup a single ego
 @node Convenience API to lookup a single ego
 
 As applications commonly simply have to lookup a single ego, there is a
@@ -4782,6 +4788,7 @@ will only be valid during that callback. The operation 
can be cancelled via
 @code{GNUNET_IDENTITY_ego_lookup_cancel} (cancellation is only legal before the
 callback is invoked).
 
address@hidden Associating egos with service functions
 @node Associating egos with service functions
 
 The @code{GNUNET_IDENTITY_set} function is used to associate a particular ego
@@ -4789,6 +4796,7 @@ with a service function. The name used by the service and 
the ego are given as
 arguments. Afterwards, the service can use its name to lookup the associated
 ego using @code{GNUNET_IDENTITY_get}.
 
address@hidden The IDENTITY Client-Service Protocol
 @node The IDENTITY Client-Service Protocol
 @c %**end of header
 
@@ -4815,6 +4823,7 @@ message, which includes the name of the service function. 
The identity service
 will respond to a GET_DEFAULT request with a SET_DEFAULT message containing the
 respective information, or with a RESULT_CODE to indicate an error.
 
address@hidden GNUnet's NAMESTORE Subsystem
 @node GNUnet's NAMESTORE Subsystem
 @c %**end of header
 
@@ -4841,6 +4850,7 @@ a specific or all zones and to monitor zones for changes. 
NAMESTORE
 functionality can be accessed using the NAMESTORE api or the NAMESTORE command
 line tool.
 
address@hidden libgnunetnamestore
 @node libgnunetnamestore
 @c %**end of header
 
@@ -4857,6 +4867,7 @@ private keys can be obtained from the IDENTITY subsytem. 
Here @address@hidden
 can be used to refer to zones or the default ego assigned to the GNS subsystem
 can be used to obtained the master zone's private key.}}
 
address@hidden Editing Zone Information
 @node Editing Zone Information
 @c %**end of header
 
@@ -4891,6 +4902,7 @@ and records stored in a zone. Here the client uses the
 zone, the nickname as string plus a the callback with the result of the
 operation.
 
address@hidden Iterating Zone Information
 @node Iterating Zone Information
 @c %**end of header
 
@@ -4907,6 +4919,7 @@ NAMESTORE calls the callback for every result and expects 
the client to call@
 NAMESTORE reached the last item it will call the callback with a NULL value to
 indicate.
 
address@hidden Monitoring Zone Information
 @node Monitoring Zone Information
 @c %**end of header
 
@@ -4923,6 +4936,7 @@ zone, the label and the records and their number.
 To stop monitoring, the client call @code{GNUNET_NAMESTORE_zone_monitor_stop}
 and passes the handle obtained from the function to start the monitoring.
 
address@hidden GNUnet's PEERINFO subsystem
 @node GNUnet's PEERINFO subsystem
 @c %**end of header
 
@@ -4941,6 +4955,7 @@ subsystems tend to need to store per-peer information in 
persistent way. To not
 duplicate this functionality we plan to provide a PEERSTORE service providing
 this functionality
 
address@hidden Features
 @node Features
 @c %**end of header
 
@@ -4951,12 +4966,14 @@ this functionality
 @item Differentiation between public and friend-only HELLO
 @end itemize
 
address@hidden Limitations @c %**end of header
address@hidden Limitations
address@hidden Limitations
 
 @itemize @bullet
 @item Does not perform HELLO validation
 @end itemize
 
address@hidden Peer Information
 @node Peer Information
 @c %**end of header
 
@@ -4984,6 +5001,7 @@ purposes. Clients are for example the HOSTLIST component 
providing these
 information to other peers in form of a hostlist or the TRANSPORT subsystem
 using these information to maintain connections to other peers.
 
address@hidden Startup
 @node Startup
 @c %**end of header
 
@@ -4997,6 +5015,7 @@ the distribution. The use of these HELLOs can be 
prevented by setting the
 @code{USE_INCLUDED_HELLOS} in the @code{PEERINFO} configuration section to
 @code{NO}. Files containing invalid information are removed.
 
address@hidden Managing Information
 @node Managing Information
 @c %**end of header
 
@@ -5015,6 +5034,7 @@ it finds. Expired TRANSPORT addresses are removed from 
the HELLO and if the
 HELLO does not contain any valid addresses, it is discarded and removed from
 disk.
 
address@hidden Obtaining Information
 @node Obtaining Information
 @c %**end of header
 
@@ -5029,6 +5049,7 @@ list of clients interested in this notifications. Such a 
notification occurs if
 a HELLO for a peer was updated (due to a merge for example) or a new peer was
 added.
 
address@hidden The PEERINFO Client-Service Protocol
 @node The PEERINFO Client-Service Protocol
 @c %**end of header
 
@@ -5057,6 +5078,7 @@ message is @code{struct GNUNET_MessageHeader} with type
 @code{GNUNET_MESSAGE_TYPE_PEERINFO_INFO}. If the client receives this message,
 he can proceed with the next request if any is pending
 
address@hidden libgnunetpeerinfo
 @node libgnunetpeerinfo
 @c %**end of header
 
@@ -5064,6 +5086,7 @@ The PEERINFO API consists mainly of three different 
functionalities:
 maintaining a connection to the service, adding new information and retrieving
 information form the PEERINFO service.
 
address@hidden Connecting to the Service
 @node Connecting to the Service
 @c %**end of header
 
@@ -5072,6 +5095,7 @@ is used, taking a configuration handle as an argument, 
and to disconnect from
 PEERINFO the function @code{GNUNET_PEERINFO_disconnect}, taking the PEERINFO
 handle returned from the connect function has to be called.
 
address@hidden Adding Information
 @node Adding Information
 @c %**end of header
 
@@ -5084,6 +5108,7 @@ operation allowing to cancel the operation with the 
respective cancel function
 you can iterate over all information stored with PEERINFO or you can tell
 PEERINFO to notify if new peer information are available.
 
address@hidden Obtaining Information
 @node Obtaining Information
 @c %**end of header
 
@@ -5103,6 +5128,7 @@ will notify you about every change and the callback 
function will be called to
 notify you about changes. The function returns a handle to cancel notifications
 with @code{GNUNET_PEERINFO_notify_cancel}.
 
address@hidden GNUnet's PEERSTORE subsystem
 @node GNUnet's PEERSTORE subsystem
 @c %**end of header
 
@@ -5119,6 +5145,7 @@ the following fields:
 @item expiry: record expiry date.
 @end itemize
 
address@hidden Functionality
 @node Functionality
 @c %**end of header
 
@@ -5142,6 +5169,7 @@ Subsystems can also request to be notified about any new 
values stored under a
 (subsystem, peerid, key) combination by sending a "watch" request to
 PEERSTORE.
 
address@hidden Architecture
 @node Architecture
 @c %**end of header
 
@@ -5155,6 +5183,7 @@ issue commands to the PEERSTORE service.
 "sqlite" plugin is implemented.
 @end itemize
 
address@hidden libgnunetpeerstore
 @node libgnunetpeerstore
 @c %**end of header
 
@@ -5194,6 +5223,7 @@ the @code{sync_first} flag is set to @code{GNUNET_YES}, 
the API will delay the
 disconnection until all pending STORE requests are sent to the PEERSTORE
 service, otherwise, the pending STORE requests will be destroyed as well.
 
address@hidden GNUnet's SET Subsystem
 @node GNUnet's SET Subsystem
 @c %**end of header
 
@@ -5203,6 +5233,7 @@ operations. Elements of a set consist of an @emph{element 
type} and arbitrary
 binary @emph{data}. The size of an element's data is limited to around 62
 KB.
 
address@hidden Local Sets
 @node Local Sets
 @c %**end of header
 
@@ -5214,6 +5245,7 @@ of a set is determined upon its creation. If a the 
elements of a set are needed
 for an operation of a different type, all of the set's element must be copied
 to a new set of appropriate type.
 
address@hidden Set Modifications
 @node Set Modifications
 @c %**end of header
 
@@ -5224,6 +5256,7 @@ sees a snapshot of the set from the time the operation 
was started. This
 mechanism is @emph{not} implemented by copying the whole set, but by attaching
 @emph{generation information} to each element and operation.
 
address@hidden Set Operations
 @node Set Operations
 @c %**end of header
 
@@ -5238,6 +5271,7 @@ application id. Once notified of an incoming set request, 
the client can
 accept the set request (providing a local set for the operation) or reject
 it.
 
address@hidden Result Elements
 @node Result Elements
 @c %**end of header
 
@@ -5259,9 +5293,11 @@ elements. This can be useful if only the remove peer is 
actually interested in
 the result of the set operation.
 @end itemize
 
address@hidden libgnunetset
 @node libgnunetset
 @c %**end of header
 
address@hidden Sets
 @node Sets
 @c %**end of header
 
@@ -5275,6 +5311,7 @@ functions dealing with sets. This return value must 
always be checked.
 Elements are added and removed with @code{GNUNET_SET_add_element} and
 @code{GNUNET_SET_remove_element}.
 
address@hidden Listeners
 @node Listeners
 @c %**end of header
 
@@ -5285,6 +5322,7 @@ synchronously call either @code{GNUNET_SET_accept} or 
@code{GNUNET_SET_reject}.
 Note that the operation will not be started until the client calls
 @code{GNUNET_SET_commit} (see Section "Supplying a Set").
 
address@hidden Operations
 @node Operations
 @c %**end of header
 
@@ -5293,6 +5331,7 @@ Operations to be initiated by the local peer are created 
with
 the client calls @code{GNUNET_SET_commit} (see Section "Supplying a
 Set").
 
address@hidden Supplying a Set
 @node Supplying a Set
 @c %**end of header
 
@@ -5305,6 +5344,7 @@ The client must call @code{GNUNET_SET_commit} to specify 
a set to use for an
 operation. @code{GNUNET_SET_commit} may only be called once per set
 operation.
 
address@hidden The Result Callback
 @node The Result Callback
 @c %**end of header
 
@@ -5316,9 +5356,11 @@ result mode. The callback needs to know which result 
mode it is used in, as the
 arguments do not indicate if an element is part of the full result set, or if
 it is in the difference between the original set and the final set.
 
address@hidden The SET Client-Service Protocol
 @node The SET Client-Service Protocol
 @c %**end of header
 
address@hidden Creating Sets
 @node Creating Sets
 @c %**end of header
 
@@ -5327,6 +5369,7 @@ are created by sending the 
@code{GNUNET_SERVICE_SET_CREATE} message over a new
 client connection. Multiple operations for one set are multiplexed over one
 client connection, using a request id supplied by the client.
 
address@hidden Listeners
 @node Listeners
 @c %**end of header
 
@@ -5338,6 +5381,7 @@ client connection. In contrast, when accepting an 
incoming request, a a
 @code{GNUNET_SERVICE_SET_ACCEPT} message must be sent over the@ set that is
 supplied for the set operation.
 
address@hidden Initiating Operations
 @node Initiating Operations
 @c %**end of header
 
@@ -5345,6 +5389,7 @@ Operations with remote peers are initiated by sending a
 @code{GNUNET_SERVICE_SET_EVALUATE} message to the service. The@ client
 connection that this message is sent by determines the set to use.
 
address@hidden Modifying Sets
 @node Modifying Sets
 @c %**end of header
 
@@ -5357,6 +5402,7 @@ Sets are modified with the @code{GNUNET_SERVICE_SET_ADD} 
and
 The service notifies the client of result elements and success/failure of a set
 operation with the @code{GNUNET_SERVICE_SET_RESULT} message.
 
address@hidden Iterating Sets
 @node Iterating Sets
 @c %**end of header
 
@@ -5367,6 +5413,7 @@ with @code{GNUNET_SERVICE_SET_ITER_DONE}. After each 
received element, the
 client@ must send @code{GNUNET_SERVICE_SET_ITER_ACK}. Note that only one set
 iteration may be active for a set at any given time.
 
address@hidden The SET-Intersection Peet-to-Peer Protocol
 @node The SET-Intersection Peer-to-Peer Protocol
 @c %**end of header
 
@@ -5390,6 +5437,7 @@ Bloom filter exchange, unless the set size is indicated 
to be zero, in which
 case the intersection is considered finished after just the initial
 handshake.
 
address@hidden The Bloom filter exchange
 @node The Bloom filter exchange
 @c %**end of header
 
@@ -5412,6 +5460,7 @@ a@ GNUNET_MESSAGE_TYPE_SET_INTERSECTION_P2P_DONE back to 
indicate that the
 latest set is the final result. Otherwise, the receiver starts another Bloom
 fitler exchange, except this time as the sender.
 
address@hidden Salt
 @node Salt
 @c %**end of header
 
@@ -5428,6 +5477,7 @@ The iterations terminate once both peers have established 
that they have sets
 of the same size, and where the XOR over all keys computes the same 512-bit
 value (leaving a failure probability of 2-511).
 
address@hidden The SET-Union Peer-to-Peer Protocol
 @node The SET-Union Peer-to-Peer Protocol
 @c %**end of header
 
@@ -5466,6 +5516,7 @@ All Bloom filter operations use a salt to mingle keys 
before hasing them into
 buckets, such that future iterations have a fresh chance of succeeding if they
 failed due to collisions before.
 
address@hidden GNUnet's STATISTICS subsystem
 @node GNUnet's STATISTICS subsystem
 @c %**end of header
 
@@ -5507,6 +5558,7 @@ before terminating itself. This is to prevent the loss of 
data during peer
 shutdown --- delaying the STATISTICS service shutdown helps other services to
 store important data to STATISTICS during shutdown.
 
address@hidden libgnunetstatistics
 @node libgnunetstatistics
 @c %**end of header
 
@@ -5527,6 +5579,7 @@ configuration all calls to 
@code{GNUNET_STATISTICS_create()} return @code{NULL}
 as the STATISTICS subsystem is unavailable and no other functions from the API
 can be used.
 
address@hidden Statistics retrieval
 @node Statistics retrieval
 @c %**end of header
 
@@ -5547,6 +5600,7 @@ the function @code{GNUNET_STATISTICS_get_cancel()}. This 
is helpful when
 retrieving statistics takes too long and especially when we want to shutdown
 and cleanup everything.
 
address@hidden Setting statistics and updating them
 @node Setting statistics and updating them
 @c %**end of header
 
@@ -5570,6 +5624,8 @@ The library will combine multiple set or update 
operations into one message if
 the client performs requests at a rate that is faster than the available IPC
 with the STATISTICS service. Thus, the client does not have to worry about
 sending requests too quickly.
+
address@hidden Watches
 @node Watches
 @c %**end of header
 
@@ -5586,9 +5642,11 @@ A registered watch will keep notifying any value changes 
until
 @code{GNUNET_STATISTICS_watch_cancel()} is called with the same parameters that
 are used for registering the watch.
 
address@hidden The STATISTICS Client-Service Protocol.
address@hidden The STATISTICS Client-Service Protocol
address@hidden The STATISTICS Client-Service Protocol
 @c %**end of header
 
address@hidden Statistics retrieval
 @node Statistics retrieval
 @c %**end of header
 
@@ -5600,6 +5658,7 @@ statistics parameters that match the client request for 
the client. The end of
 information retrieved is signaled by the service by sending a message of type
 @code{GNUNET_MESSAGE_TYPE_STATISTICS_END}.
 
address@hidden Setting and updating statistics
 @node Setting and updating statistics
 @c %**end of header
 
@@ -5620,6 +5679,7 @@ relative update by sending a message of type
 (@code{GNUNET_STATISTICS_SETFLAG_RELATIVE}) signifying that the value in the
 message should be treated as an update value.
 
address@hidden Watching for updates
 @node Watching for updates
 @c %**end of header
 
@@ -5629,6 +5689,7 @@ notifications through messages of type
 @code{GNUNET_MESSAGE_TYPE_STATISTICS_WATCH_VALUE} whenever the statistic
 parameter's value is changed.
 
address@hidden GNUnet's Distributed Hash Table (DHT)
 @node GNUnet's Distributed Hash Table (DHT)
 @c %**end of header
 
@@ -5663,9 +5724,11 @@ significant delay. Your application logic must be 
written to tolerate this
 (naturally, some loss of performance or quality of service is expected in this
 case).
 
address@hidden Block library and plugins
 @node Block library and plugins
 @c %**end of header
 
address@hidden What is a Block?
 @node What is a Block?
 @c %**end of header
 
@@ -5679,6 +5742,7 @@ for the maintenance of the DHT are both stored using 
blocks). The block
 subsystem provides a few common functions that must be available for any type
 of block.
 
address@hidden The API of libgnunetblock
 @node The API of libgnunetblock
 @c %**end of header
 
@@ -5706,6 +5770,7 @@ replies (by adding the current response to the Bloom 
filter and rejecting it if
 it is encountered again). If a plugin fails to do this, responses may loop in
 the network.
 
address@hidden Queries
 @node Queries
 @c %**end of header
 
@@ -5729,6 +5794,7 @@ Depending on the results from the plugin, the DHT will 
then discard the
 (invalid) query, forward the query, discard the (invalid) reply, cache the
 (valid) reply, and/or forward the (valid and non-duplicate) reply.
 
address@hidden Sample Code
 @node Sample Code
 @c %**end of header
 
@@ -5737,6 +5803,7 @@ new block plugins --- it does the minimal work by 
implementing a plugin that
 performs no validation at all. The respective @strong{Makefile.am} shows how to
 build and install a block plugin.
 
address@hidden Conclusion
 @node Conclusion
 @c %**end of header
 
@@ -5747,6 +5814,7 @@ and any reply as matching any query. This type is also 
used for the DHT command
 line tools. However, it should NOT be used for normal applications due to the
 lack of error checking that results from this primitive implementation.
 
address@hidden libgnunetdht
 @node libgnunetdht
 @c %**end of header
 
@@ -5755,6 +5823,7 @@ that work as expected. The specified block type refers to 
the block library
 which allows the DHT to run application-specific logic for data stored in the
 network.
 
address@hidden GET
 @node GET
 @c %**end of header
 
@@ -5778,6 +5847,7 @@ more). This way, the DHT will filter the respective 
blocks using the block
 library in the network, which may result in a significant reduction in
 bandwidth consumption.
 
address@hidden PUT
 @node PUT
 @c %**end of header
 
@@ -5795,6 +5865,7 @@ rule of thumb is that there should be at least a dozen 
PUT operations within
 the content lifetime. Content in the DHT typically expires after one day, so
 DHT PUT operations should be repeated at least every 1-2 hours.
 
address@hidden MONITOR
 @node MONITOR
 @c %**end of header
 
@@ -5813,6 +5884,7 @@ workers have no good way to guess the keys under which 
work would be stored.
 Naturally, additional protocols might be needed to ensure that the desired
 number of workers will process the distributed workload.
 
address@hidden DHT Routing Options
 @node DHT Routing Options
 @c %**end of header
 
@@ -5841,9 +5913,11 @@ the DHT's peer discovery mechanism and should not be 
used by applications.
 the future offer performance improvements for clique topologies.
 @end table
 
address@hidden The DHT Client-Service Protocol
 @node The DHT Client-Service Protocol
 @c %**end of header
 
address@hidden PUTting data into the DHT
 @node PUTting data into the DHT
 @c %**end of header
 
@@ -5862,6 +5936,7 @@ the same key-value pair was already stored in the DHT. 
However, changing this
 would also require additional state and messages in the P2P
 interaction.
 
address@hidden GETting data from the DHT
 @node GETting data from the DHT
 @c %**end of header
 
@@ -5897,6 +5972,7 @@ is more common as this allows a client to run many 
concurrent GET operations
 over the same connection with the DHT service --- and to stop them
 individually.
 
address@hidden Monitoring the DHT
 @node Monitoring the DHT
 @c %**end of header
 
@@ -5911,9 +5987,11 @@ GNUNET_DHT_MonitorPutMessage} for PUT events and@ 
@code{struct
 GNUNET_DHT_MonitorGetRespMessage} for RESULTs. Each of these messages contains
 all of the information about the event.
 
address@hidden The DHT Peer-to-Peer Protocol
 @node The DHT Peer-to-Peer Protocol
 @c %**end of header
 
address@hidden Routing GETs or PUTs
 @node Routing GETs or PUTs
 @c %**end of header
 
@@ -5926,6 +6004,7 @@ estimate, the selection of the peers maybe randomized or 
by proximity to the
 key. Furthermore, requests include a set of peers that a request has already
 traversed; those peers are also excluded from the selection.
 
address@hidden PUTting data into the DHT
 @node PUTting data into the DHT
 @c %**end of header
 
@@ -5943,6 +6022,7 @@ previous hop; however, the path should not include the 
identity of the previous
 hop and the receiver should append the identity of the sender to the path, not
 its own identity (this is done to reduce bandwidth).
 
address@hidden GETting data from the DHT
 @node GETting data from the DHT
 @c %**end of header
 
@@ -5973,6 +6053,7 @@ filter accordingly, to ensure that the same result is 
never forwarded more than
 once. The DHT service may also cache forwarded results locally if the
 "CACHE_RESULTS" option is set to "YES" in the configuration.
 
address@hidden The GNU Name System (GNS)
 @node The GNU Name System (GNS)
 @c %**end of header
 
@@ -6009,6 +6090,7 @@ users, the NAMESTORE to store information specific to the 
local users, and the
 DHT to exchange data between users. A plugin API is used to enable applications
 to define new GNS record types.
 
address@hidden libgnunetgns
 @node libgnunetgns
 @c %**end of header
 
@@ -6018,6 +6100,7 @@ using @code{GNUNET_GNS_connect}. They can then perform 
lookups using
 @code{GNUNET_GNS_lookup_cancel}. Once finished, clients disconnect using
 @code{GNUNET_GNS_disconnect}.
 
address@hidden Looking up records
 @node Looking up records
 @c %**end of header
 
@@ -6056,6 +6139,7 @@ longer be cancelled.
 @item proc_cls The closure for proc.
 @end table
 
address@hidden Accessing the records
 @node Accessing the records
 @c %**end of header
 
@@ -6068,6 +6152,7 @@ applications.
 For DNS records, the @code{libgnunetdnsparser} library provides functions for
 parsing (and serializing) common types of DNS records.
 
address@hidden Creating records
 @node Creating records
 @c %**end of header
 
@@ -6077,6 +6162,7 @@ information (possibly with the help of 
@code{libgnunetgnsrecord} and
 publish the information. The GNS API is not involved in this
 operation.
 
address@hidden Future work
 @node Future work
 @c %**end of header
 
@@ -6084,6 +6170,7 @@ In the future, we want to expand @code{libgnunetgns} to 
allow applications to
 observe shortening operations performed during GNS resolution, for example so
 that users can receive visual feedback when this happens.
 
address@hidden libgnunetgnsrecord
 @node libgnunetgnsrecord
 @c %**end of header
 
@@ -6101,6 +6188,7 @@ We will now discuss the four commonly used functions of 
the API.@
 uses plugins to perform the operation. GNUnet includes plugins to support
 common DNS record types as well as standard GNS record types.
 
address@hidden Value handling
 @node Value handling
 @c %**end of header
 
@@ -6113,6 +6201,7 @@ available plugin.
 readable string to the respective (binary) representation of a GNS record
 value.
 
address@hidden Type handling
 @node Type handling
 @c %**end of header
 
@@ -6128,6 +6217,7 @@ time.}
 associated with a given numeric value. For example, given the type number 1,
 the function will return the typename "A".
 
address@hidden GNS plugins
 @node GNS plugins
 @c %**end of header
 
@@ -6150,6 +6240,7 @@ The central functions of the block APIs (plugin and main 
library) are the same
 four functions for converting between values and strings, and typenames and
 numbers documented in the previous section.
 
address@hidden The GNS Client-Service Protocol
 @node The GNS Client-Service Protocol
 @c %**end of header
 
@@ -6166,6 +6257,7 @@ The response includes the number of records and the 
records themselves in the
 format created by @code{GNUNET_GNSRECORD_records_serialize}. They can thus be
 deserialized using @code{GNUNET_GNSRECORD_records_deserialize}.
 
address@hidden Hijacking the DNS-Traffic using gnunet-service-dns
 @node Hijacking the DNS-Traffic using gnunet-service-dns
 @c %**end of header
 
@@ -6191,6 +6283,7 @@ application using the DNS service will be sent to the 
original recipient. The
 answer to the query will always be sent back through the virtual interface with
 the original nameserver as source address.
 
address@hidden Network Setup Details
 @node Network Setup Details
 @c %**end of header
 
@@ -6206,6 +6299,7 @@ beforehand (@code{$LOCALPORT}) will be routed normally. 
Line 2 marks every
 other packet to a DNS-Server with mark 3 (chosen arbitrarily). The third line
 adds a routing policy based on this mark 3 via the routing table.
 
address@hidden Serving DNS lookups via GNS on W32
 @node Serving DNS lookups via GNS on W32
 @c %**end of header
 
@@ -6269,6 +6363,7 @@ use alternative means of resolving names (such as sending 
queries to a DNS
 server directly by themselves). This includes some of well known utilities,
 like "ping" and "nslookup".
 
address@hidden The GNS Namecache
 @node The GNS Namecache
 @c %**end of header
 
@@ -6295,6 +6390,7 @@ always small enough (a few MB) to fit on the drive.
 
 The NAMECACHE supports the use of different database backends via a plugin API.
 
address@hidden libgnunetnamecache
 @node libgnunetnamecache
 @c %**end of header
 
@@ -6314,6 +6410,7 @@ the NAMECACHE.
 The maximum size of a block that can be stored in the NAMECACHE is
 @code{GNUNET_NAMECACHE_MAX_VALUE_SIZE}, which is defined to be 63 kB.
 
address@hidden The NAMECACHE Client-Service Protocol
 @node The NAMECACHE Client-Service Protocol
 @c %**end of header
 
@@ -6323,6 +6420,7 @@ standard message header. The request ID is used to match 
requests with the
 respective responses from the NAMECACHE, as they are allowed to happen
 out-of-order.
 
address@hidden Lookup
 @node Lookup
 @c %**end of header
 
@@ -6333,6 +6431,7 @@ sets the expiration time in the response to zero. 
Otherwise, the response is
 expected to contain the expiration time, the ECDSA signature, the derived key
 and the (variable-size) encrypted data of the block.
 
address@hidden Store
 @node Store
 @c %**end of header
 
@@ -6342,6 +6441,7 @@ service responds with a @code{struct 
BlockCacheResponseMessage} which contains
 the result of the operation (success or failure). In the future, we might want
 to make it possible to provide an error message as well.
 
address@hidden The NAMECACHE Plugin API
 @node The NAMECACHE Plugin API
 @c %**end of header
 
@@ -6349,6 +6449,7 @@ The NAMECACHE plugin API consists of two functions, 
@code{cache_block} to store
 a block in the database, and @code{lookup_block} to lookup a block in the
 database.
 
address@hidden Lookup
 @node Lookup
 @c %**end of header
 
@@ -6357,6 +6458,7 @@ iterator, and return @code{GNUNET_NO} if there were no 
non-expired results. If
 there are multiple non-expired results in the cache, the lookup is supposed to
 return the result with the largest expiration time.
 
address@hidden Store
 @node Store
 @c %**end of header
 
@@ -6371,6 +6473,7 @@ can done either by simply adding new blocks and selecting 
for the most recent
 expiration time during lookup, or by checking which block is more recent during
 the store operation.
 
address@hidden The REVOCATION Subsystem
 @node The REVOCATION Subsystem
 @c %**end of header
 
@@ -6380,6 +6483,7 @@ REVOCATION system to inform all of the other users that 
this private key is no
 longer valid. The subsystem thus includes ways to query for the validity of
 keys and to propagate revocation messages.
 
address@hidden Dissemination
 @node Dissemination
 @c %**end of header
 
@@ -6400,6 +6504,7 @@ messages whenever two peers (that both support REVOCATION 
dissemination)
 connect. The SET service is used to perform this operation
 efficiently.
 
address@hidden Revocation Message: Design Requirements
 @node Revocation Message: Design Requirements
 @c %**end of header
 
@@ -6419,12 +6524,14 @@ revoked. Thus, they can only be created while the 
private key is in the
 possession of the respective user. This is another reason to create a
 revocation message ahead of time and store it in a secure location.
 
address@hidden libgnunetrevocation
 @node libgnunetrevocation
 @c %**end of header
 
 The REVOCATION API consists of two parts, to query and to issue
 revocations.
 
address@hidden Querying for revoked keys
 @node Querying for revoked keys
 @c %**end of header
 
@@ -6433,6 +6540,7 @@ been revoked. The given callback will be invoked with the 
result of the check.
 The query can be cancelled using @code{GNUNET_REVOCATION_query_cancel} on the
 return value.
 
address@hidden Preparing revocations
 @node Preparing revocations
 @c %**end of header
 
@@ -6462,6 +6570,7 @@ the future) is to be revoked and returns the signature. 
The signature can again
 be saved to disk for later use, which will then allow performing a revocation
 even without access to the private key.
 
address@hidden Issuing revocations
 @node Issuing revocations
 
 Given a ECDSA public key, the signature from @code{GNUNET_REVOCATION_sign} and
@@ -6471,6 +6580,7 @@ operation. @code{GNUNET_REVOCATION_revoke_cancel} can be 
used to stop the
 library from calling the continuation; however, in that case it is undefined
 whether or not the revocation operation will be executed.
 
address@hidden The REVOCATION Client-Service Protocol
 @node The REVOCATION Client-Service Protocol
 
 The REVOCATION protocol consists of four simple messages.
@@ -6488,6 +6598,7 @@ and the proof-of-work, The service responds with a
 @code{RevokeMessage} was invalid (i.e. proof of work incorrect), or otherwise
 indicates that the revocation has been processed successfully.
 
address@hidden The REVOCATION Peer-to-Peer Protocol
 @node The REVOCATION Peer-to-Peer Protocol
 @c %**end of header
 
@@ -6515,6 +6626,7 @@ peers at any time; however, well-behaved peers should 
only initiate this
 operation once after establishing a connection to a peer with a larger hashed
 peer identity.
 
address@hidden GNUnet's File-sharing (FS) Subsystem
 @node GNUnet's File-sharing (FS) Subsystem
 @c %**end of header
 
@@ -6541,6 +6653,7 @@ in the FS service.
 
 NOTE: The documentation in this chapter is quite incomplete.
 
address@hidden Encoding for Censorship-Resistant Sharing (ECRS)
 @node Encoding for Censorship-Resistant Sharing (ECRS)
 @c %**end of header
 
@@ -6555,6 +6668,7 @@ extensions are not in the paper is that we felt that they 
were obvious or
 trivial extensions to the original scheme and thus did not warrant space in
 the research report.
 
address@hidden Namespace Advertisements
 @node Namespace Advertisements
 @c %**end of header
 
@@ -6566,6 +6680,7 @@ namespace. The URI should always be empty. The 
@code{SBlock} is signed with
 the content provder′s RSA private key (just like any other SBlock). Peers
 can search for @code{SBlock}s in order to find out more about a namespace.
 
address@hidden KSBlocks
 @node KSBlocks
 @c %**end of header
 
@@ -6589,8 +6704,10 @@ Collections are also advertised using @code{KSBlock}s.
 @table @asis
 @item Attachment Size
 @item  ecrs.pdf 270.68 KB
address@hidden https://gnunet.org/sites/default/files/ecrs.pdf
 @end table
 
address@hidden File-sharing persistence directory structure
 @node File-sharing persistence directory structure
 @c %**end of header
 
@@ -6661,6 +6778,7 @@ this directory structure is flat and does not mirror the 
structure of the
 publishing operation. Note that unindex operations cannot have associated child
 operations.
 
address@hidden GNUnet's REGEX Subsystem
 @node GNUnet's REGEX Subsystem
 @c %**end of header
 
@@ -6674,6 +6792,7 @@ For the technical details, we have "Max's defense talk 
and Max's Master's
 thesis. An additional publication is under preparation and available to team
 members (in Git).
 
address@hidden How to run the regex profiler
 @node How to run the regex profiler
 @c %**end of header
 
@@ -6702,13 +6821,15 @@ adding it to the AUTOSTART set of ARM:@
 AUTOSTART = YES@
 }
 
-Furthermore you have to specify the location of the binary:@ @code{@
-[regexprofiler]@
- # Location of the gnunet-daemon-regexprofiler binary.@
- BINARY = /home/szengel/gnunet/src/mesh/.libs/gnunet-daemon-regexprofiler@
- # Regex prefix that will be applied to all regular expressions and search
- # strings.@
- REGEX_PREFIX = "GNVPN-0001-PAD"@ }
+Furthermore you have to specify the location of the binary:
address@hidden
+[regexprofiler]
+# Location of the gnunet-daemon-regexprofiler binary.
+BINARY = /home/szengel/gnunet/src/mesh/.libs/gnunet-daemon-regexprofiler
+# Regex prefix that will be applied to all regular expressions and
+# search string.
+REGEX_PREFIX = "GNVPN-0001-PAD"
address@hidden example
 
 When running the profiler with a large scale deployment, you probably want to
 reduce the workload of each peer. Use the following options to do this.@

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