[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [gnunet-texinfo] branch master updated: developer.texi: Mos
From: |
gnunet |
Subject: |
[GNUnet-SVN] [gnunet-texinfo] branch master updated: developer.texi: Mostly complete structure of chapters |
Date: |
Mon, 27 Mar 2017 00:38:44 +0200 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] [gnunet-texinfo] branch master updated: developer.texi: Mostly complete structure of chapters,
gnunet <=