summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorng0 <ng0@n0.is>2019-03-18 18:29:52 +0000
committerng0 <ng0@n0.is>2019-03-18 18:29:52 +0000
commit466dd42d2bd71820bf28b0d8404157db339c6dc7 (patch)
treea1269b9447c11f880c9e5bddaa5e134041e84b3c /doc
parente63fa4906e791c925a7f1268b10abd5cc5e061a7 (diff)
pindexs + format
Diffstat (limited to 'doc')
-rw-r--r--doc/handbook/chapters/developer.texi32
1 files changed, 21 insertions, 11 deletions
diff --git a/doc/handbook/chapters/developer.texi b/doc/handbook/chapters/developer.texi
index 7cefa5603..6c426ebad 100644
--- a/doc/handbook/chapters/developer.texi
+++ b/doc/handbook/chapters/developer.texi
@@ -5162,6 +5162,8 @@ receiving a type map by sending back a
retransmit the type map (with exponential back-off).
@cindex CADET Subsystem
+@cindex CADET
+@cindex cadet
@node CADET Subsystem
@section CADET Subsystem
@@ -5228,6 +5230,7 @@ Should a message get lost on TRANSPORT/CORE level, if a channel is
created with as reliable, CADET will retransmit the lost message and
deliver it in order to the destination application.
+@pindex GNUNET_CADET_connect
To communicate with other peers using CADET, it is necessary to first
connect to the service using @code{GNUNET_CADET_connect}.
This function takes several parameters in form of callbacks, to allow the
@@ -5239,7 +5242,8 @@ CADET, even do one connection per listening port).
The function returns a handle which has to be used for any further
interaction with the service.
-To connect to a remote peer a client has to call the
+@pindex GNUNET_CADET_channel_create
+To connect to a remote peer, a client has to call the
@code{GNUNET_CADET_channel_create} function. The most important parameters
given are the remote peer's identity (it public key) and a port, which
specifies which application on the remote peer to connect to, similar to
@@ -5249,6 +5253,7 @@ exchanges to assure and authenticated, secure and verified communication.
Similar to @code{GNUNET_CADET_connect},@code{GNUNET_CADET_create_channel}
returns a handle to interact with the created channel.
+@pindex GNUNET_CADET_notify_transmit_ready
For every message the client wants to send to the remote application,
@code{GNUNET_CADET_notify_transmit_ready} must be called, indicating the
channel on which the message should be sent and the size of the message
@@ -5265,6 +5270,7 @@ case. To be alerted when a channel is online, a client can call
means that the channel is online. The callback can give 0 bytes to CADET
if no message is to be sent, this is OK.
+@pindex GNUNET_CADET_notify_transmit_cancel
If a transmission was requested but before the callback fires it is no
longer needed, it can be canceled with
@code{GNUNET_CADET_notify_transmit_ready_cancel}, which uses the handle
@@ -5273,6 +5279,7 @@ As in the case of CORE, only one message can be requested at a time: a
client must not call @code{GNUNET_CADET_notify_transmit_ready} again until
the callback is called or the request is canceled.
+@pindex GNUNET_CADET_channel_destroy
When a channel is no longer needed, a client can call
@code{GNUNET_CADET_channel_destroy} to get rid of it.
Note that CADET will try to transmit all pending traffic before notifying
@@ -5284,6 +5291,7 @@ on any incoming or outgoing channels are given to the client when CADET
executes the callbacks given to it at the time of
@code{GNUNET_CADET_connect}.
+@pindex GNUNET_CADET_disconnect
Finally, when an application no longer wants to use CADET, it should call
@code{GNUNET_CADET_disconnect}, but first all channels and pending
transmissions must be closed (otherwise CADET will complain).
@@ -5579,7 +5587,7 @@ simply disconnects from the service, with no message involved.
@subsection The NSE Peer-to-Peer Protocol
-
+@pindex GNUNET_MESSAGE_TYPE_NSE_P2P_FLOOD
The NSE subsystem only has one message in the P2P protocol, the
@code{GNUNET_MESSAGE_TYPE_NSE_P2P_FLOOD} message.
@@ -5794,6 +5802,7 @@ The hostlist daemon is the main component of the HOSTLIST subsystem. It is
started by the ARM service and (if configured) starts the HOSTLIST client
and server components.
+@pindex GNUNET_MESSAGE_TYPE_HOSTLIST_ADVERTISEMENT
If the daemon provides a hostlist itself it can advertise it's own
hostlist to other peers. To do so it sends a
@code{GNUNET_MESSAGE_TYPE_HOSTLIST_ADVERTISEMENT} message to other peers
@@ -8085,10 +8094,9 @@ This includes some of well known utilities, like "ping" and "nslookup".
@node Importing DNS Zones into GNS
@subsection Importing DNS Zones into GNS
-
-
This section discusses the challenges and problems faced when writing the
-Ascension tool. It also takes a look at possible improvements in the future.
+Ascension tool. It also takes a look at possible improvements in the
+future.
@menu
* Conversions between DNS and GNS::
@@ -8096,12 +8104,13 @@ Ascension tool. It also takes a look at possible improvements in the future.
* Performance::
@end menu
+@cindex DNS Conversion
@node Conversions between DNS and GNS
@subsubsection Conversions between DNS and GNS
The differences between the two name systems lies in the details
-and is not always transparent. For instance an SRV record is converted to a
-GNS only BOX record.
+and is not always transparent.
+For instance an SRV record is converted to a GNS only BOX record.
This is done by converting to a BOX record from an existing SRV record:
@@ -8114,11 +8123,12 @@ _sip._tcp.example.com. 14000 IN SRV 0 0 5060 www.example.com.
14000 BOX n 5060 6 33 0 0 5060 www.example.com
@end example
-Other records that have such a transformation is the MX record type, as well as
-the SOA record type.
+Other records that have such a transformation is the MX record type,
+as well as the SOA record type.
+
+Transformation of a SOA record into GNS works as described in the
+following example. Very important to note are the rname and mname keys.
-Transformation of a SOA record into GNS works as described in the following
-example. Very important to note are the rname and mname keys.
@example
# BIND syntax for a clean SOA record
@ IN SOA master.example.com. hostmaster.example.com. (