aboutsummaryrefslogtreecommitdiff
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
parente63fa4906e791c925a7f1268b10abd5cc5e061a7 (diff)
downloadgnunet-466dd42d2bd71820bf28b0d8404157db339c6dc7.tar.gz
gnunet-466dd42d2bd71820bf28b0d8404157db339c6dc7.zip
pindexs + format
-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
5162retransmit the type map (with exponential back-off). 5162retransmit the type map (with exponential back-off).
5163 5163
5164@cindex CADET Subsystem 5164@cindex CADET Subsystem
5165@cindex CADET
5166@cindex cadet
5165@node CADET Subsystem 5167@node CADET Subsystem
5166@section CADET Subsystem 5168@section CADET Subsystem
5167 5169
@@ -5228,6 +5230,7 @@ Should a message get lost on TRANSPORT/CORE level, if a channel is
5228created with as reliable, CADET will retransmit the lost message and 5230created with as reliable, CADET will retransmit the lost message and
5229deliver it in order to the destination application. 5231deliver it in order to the destination application.
5230 5232
5233@pindex GNUNET_CADET_connect
5231To communicate with other peers using CADET, it is necessary to first 5234To communicate with other peers using CADET, it is necessary to first
5232connect to the service using @code{GNUNET_CADET_connect}. 5235connect to the service using @code{GNUNET_CADET_connect}.
5233This function takes several parameters in form of callbacks, to allow the 5236This function takes several parameters in form of callbacks, to allow the
@@ -5239,7 +5242,8 @@ CADET, even do one connection per listening port).
5239The function returns a handle which has to be used for any further 5242The function returns a handle which has to be used for any further
5240interaction with the service. 5243interaction with the service.
5241 5244
5242To connect to a remote peer a client has to call the 5245@pindex GNUNET_CADET_channel_create
5246To connect to a remote peer, a client has to call the
5243@code{GNUNET_CADET_channel_create} function. The most important parameters 5247@code{GNUNET_CADET_channel_create} function. The most important parameters
5244given are the remote peer's identity (it public key) and a port, which 5248given are the remote peer's identity (it public key) and a port, which
5245specifies which application on the remote peer to connect to, similar to 5249specifies which application on the remote peer to connect to, similar to
@@ -5249,6 +5253,7 @@ exchanges to assure and authenticated, secure and verified communication.
5249Similar to @code{GNUNET_CADET_connect},@code{GNUNET_CADET_create_channel} 5253Similar to @code{GNUNET_CADET_connect},@code{GNUNET_CADET_create_channel}
5250returns a handle to interact with the created channel. 5254returns a handle to interact with the created channel.
5251 5255
5256@pindex GNUNET_CADET_notify_transmit_ready
5252For every message the client wants to send to the remote application, 5257For every message the client wants to send to the remote application,
5253@code{GNUNET_CADET_notify_transmit_ready} must be called, indicating the 5258@code{GNUNET_CADET_notify_transmit_ready} must be called, indicating the
5254channel on which the message should be sent and the size of the message 5259channel 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
5265means that the channel is online. The callback can give 0 bytes to CADET 5270means that the channel is online. The callback can give 0 bytes to CADET
5266if no message is to be sent, this is OK. 5271if no message is to be sent, this is OK.
5267 5272
5273@pindex GNUNET_CADET_notify_transmit_cancel
5268If a transmission was requested but before the callback fires it is no 5274If a transmission was requested but before the callback fires it is no
5269longer needed, it can be canceled with 5275longer needed, it can be canceled with
5270@code{GNUNET_CADET_notify_transmit_ready_cancel}, which uses the handle 5276@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
5273client must not call @code{GNUNET_CADET_notify_transmit_ready} again until 5279client must not call @code{GNUNET_CADET_notify_transmit_ready} again until
5274the callback is called or the request is canceled. 5280the callback is called or the request is canceled.
5275 5281
5282@pindex GNUNET_CADET_channel_destroy
5276When a channel is no longer needed, a client can call 5283When a channel is no longer needed, a client can call
5277@code{GNUNET_CADET_channel_destroy} to get rid of it. 5284@code{GNUNET_CADET_channel_destroy} to get rid of it.
5278Note that CADET will try to transmit all pending traffic before notifying 5285Note 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
5284executes the callbacks given to it at the time of 5291executes the callbacks given to it at the time of
5285@code{GNUNET_CADET_connect}. 5292@code{GNUNET_CADET_connect}.
5286 5293
5294@pindex GNUNET_CADET_disconnect
5287Finally, when an application no longer wants to use CADET, it should call 5295Finally, when an application no longer wants to use CADET, it should call
5288@code{GNUNET_CADET_disconnect}, but first all channels and pending 5296@code{GNUNET_CADET_disconnect}, but first all channels and pending
5289transmissions must be closed (otherwise CADET will complain). 5297transmissions must be closed (otherwise CADET will complain).
@@ -5579,7 +5587,7 @@ simply disconnects from the service, with no message involved.
5579@subsection The NSE Peer-to-Peer Protocol 5587@subsection The NSE Peer-to-Peer Protocol
5580 5588
5581 5589
5582 5590@pindex GNUNET_MESSAGE_TYPE_NSE_P2P_FLOOD
5583The NSE subsystem only has one message in the P2P protocol, the 5591The NSE subsystem only has one message in the P2P protocol, the
5584@code{GNUNET_MESSAGE_TYPE_NSE_P2P_FLOOD} message. 5592@code{GNUNET_MESSAGE_TYPE_NSE_P2P_FLOOD} message.
5585 5593
@@ -5794,6 +5802,7 @@ The hostlist daemon is the main component of the HOSTLIST subsystem. It is
5794started by the ARM service and (if configured) starts the HOSTLIST client 5802started by the ARM service and (if configured) starts the HOSTLIST client
5795and server components. 5803and server components.
5796 5804
5805@pindex GNUNET_MESSAGE_TYPE_HOSTLIST_ADVERTISEMENT
5797If the daemon provides a hostlist itself it can advertise it's own 5806If the daemon provides a hostlist itself it can advertise it's own
5798hostlist to other peers. To do so it sends a 5807hostlist to other peers. To do so it sends a
5799@code{GNUNET_MESSAGE_TYPE_HOSTLIST_ADVERTISEMENT} message to other peers 5808@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".
8085@node Importing DNS Zones into GNS 8094@node Importing DNS Zones into GNS
8086@subsection Importing DNS Zones into GNS 8095@subsection Importing DNS Zones into GNS
8087 8096
8088
8089
8090This section discusses the challenges and problems faced when writing the 8097This section discusses the challenges and problems faced when writing the
8091Ascension tool. It also takes a look at possible improvements in the future. 8098Ascension tool. It also takes a look at possible improvements in the
8099future.
8092 8100
8093@menu 8101@menu
8094* Conversions between DNS and GNS:: 8102* Conversions between DNS and GNS::
@@ -8096,12 +8104,13 @@ Ascension tool. It also takes a look at possible improvements in the future.
8096* Performance:: 8104* Performance::
8097@end menu 8105@end menu
8098 8106
8107@cindex DNS Conversion
8099@node Conversions between DNS and GNS 8108@node Conversions between DNS and GNS
8100@subsubsection Conversions between DNS and GNS 8109@subsubsection Conversions between DNS and GNS
8101 8110
8102The differences between the two name systems lies in the details 8111The differences between the two name systems lies in the details
8103and is not always transparent. For instance an SRV record is converted to a 8112and is not always transparent.
8104GNS only BOX record. 8113For instance an SRV record is converted to a GNS only BOX record.
8105 8114
8106This is done by converting to a BOX record from an existing SRV record: 8115This is done by converting to a BOX record from an existing SRV record:
8107 8116
@@ -8114,11 +8123,12 @@ _sip._tcp.example.com. 14000 IN SRV 0 0 5060 www.example.com.
811414000 BOX n 5060 6 33 0 0 5060 www.example.com 812314000 BOX n 5060 6 33 0 0 5060 www.example.com
8115@end example 8124@end example
8116 8125
8117Other records that have such a transformation is the MX record type, as well as 8126Other records that have such a transformation is the MX record type,
8118the SOA record type. 8127as well as the SOA record type.
8128
8129Transformation of a SOA record into GNS works as described in the
8130following example. Very important to note are the rname and mname keys.
8119 8131
8120Transformation of a SOA record into GNS works as described in the following
8121example. Very important to note are the rname and mname keys.
8122@example 8132@example
8123# BIND syntax for a clean SOA record 8133# BIND syntax for a clean SOA record
8124@ IN SOA master.example.com. hostmaster.example.com. ( 8134@ IN SOA master.example.com. hostmaster.example.com. (