[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [gnunet] branch master updated: pindexs + format
From: |
gnunet |
Subject: |
[GNUnet-SVN] [gnunet] branch master updated: pindexs + format |
Date: |
Mon, 18 Mar 2019 19:30:00 +0100 |
This is an automated email from the git hooks/post-receive script.
ng0 pushed a commit to branch master
in repository gnunet.
The following commit(s) were added to refs/heads/master by this push:
new 466dd42d2 pindexs + format
466dd42d2 is described below
commit 466dd42d2bd71820bf28b0d8404157db339c6dc7
Author: ng0 <address@hidden>
AuthorDate: Mon Mar 18 18:29:52 2019 +0000
pindexs + format
---
doc/handbook/chapters/developer.texi | 32 +++++++++++++++++++++-----------
1 file 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
address@hidden CADET
address@hidden 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.
address@hidden 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
address@hidden 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.
address@hidden 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.
address@hidden 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.
address@hidden 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}.
address@hidden 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
-
address@hidden 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.
address@hidden 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
address@hidden 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. (
--
To stop receiving notification emails like this one, please contact
address@hidden
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] [gnunet] branch master updated: pindexs + format,
gnunet <=