diff options
Diffstat (limited to 'template')
| -rw-r--r-- | template/probnat/api.html.j2 | 6 |
1 files changed, 4 insertions, 2 deletions
diff --git a/template/probnat/api.html.j2 b/template/probnat/api.html.j2 index 90e56cfd..64267f69 100644 --- a/template/probnat/api.html.j2 +++ b/template/probnat/api.html.j2 | |||
| @@ -39,9 +39,11 @@ | |||
| 39 | The second is to create the synchronisation message which the caller has to send to the other peer. | 39 | The second is to create the synchronisation message which the caller has to send to the other peer. |
| 40 | Within GNUnet the Distance Vector DV protocol is used for sending the synchronisation message. Applications which do not want to use the complete GNUnet stack have to use transportion by other means.<br/><br/> | 40 | Within GNUnet the Distance Vector DV protocol is used for sending the synchronisation message. Applications which do not want to use the complete GNUnet stack have to use transportion by other means.<br/><br/> |
| 41 | 41 | ||
| 42 | The API call needs two parameters. The avarage round trip time rtt_avarage has to be provided by the callers application. In GNUnet this information is constantly calculated from messages delivered by DV. Again, applications not using the GNUnet stack have to assemble this information by themself. The second parameter is returned by the first API call and must be temporarily stored to use it in the second.<br/><br/> | 42 | The API call needs two parameters. The avarage round trip time rtt_avarage has to be provided by the callers application. In GNUnet this information is constantly calculated from messages delivered by DV. Again, applications not using the GNUnet stack have to assemble this information by themself. The round trip time has to be calculated as the time a message needs to arrive at another peer plus the time a response to this message needs to travel back. The messages used to measure this time needs to be send via the same transportion mechanism like the burst synchromisation method. The value used in the API should be an average over several RTTs. rtt_average is measured in microseconds. <br/><br/> |
| 43 | 43 | ||
| 44 | The first API call also needs the avarage RTT and the synchronisation message received from another peer. The callback is called, if both peers are ready to synchronize. Therefore the callback should start the burst mode which will finally do the hole punch for NAT traversal.<br/><br/> | 44 | The second parameter is returned by the first API call and must be temporarily stored to use it in the second. This is the burst synchromisation method, which encapsulates the RTT calculated by the sending peer, and if that peer is ready to sync.<br/><br/> |
| 45 | |||
| 46 | The first API call also needs the avarage RTT and the synchronisation message received from another peer. The callback is called, if both peers are ready to synchronize. Therefore the callback should start the burst mode which will finally do the hole punch for NAT traversal. One can find an example in the GNUnet code src/service/transport/gnunet-service-transport.c in the function handle_flow_control. <br/><br/> | ||
| 45 | {% endtrans %} | 47 | {% endtrans %} |
| 46 | </p> | 48 | </p> |
| 47 | </section> | 49 | </section> |