aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authort3sserakt <t3ss@posteo.de>2023-05-04 10:31:12 +0200
committert3sserakt <t3ss@posteo.de>2023-05-04 10:31:12 +0200
commit85c3924f95924eddeea3e9703bc68edf4b7604ac (patch)
tree4f4c36a42372d13e67a4fd869f51ffad3ecf5bdb
parent825e62e283e2b4fe94e456f0f2a03db568003feb (diff)
downloadwww-85c3924f95924eddeea3e9703bc68edf4b7604ac.tar.gz
www-85c3924f95924eddeea3e9703bc68edf4b7604ac.zip
Added L2O milestone 6 documentation
-rw-r--r--template/l2o/index.html.j22
-rw-r--r--template/l2o/mile6.html.j280
2 files changed, 81 insertions, 1 deletions
diff --git a/template/l2o/index.html.j2 b/template/l2o/index.html.j2
index a4ff4da9..33f27113 100644
--- a/template/l2o/index.html.j2
+++ b/template/l2o/index.html.j2
@@ -201,7 +201,7 @@ I will finish the project with a performance analysis to optimize the selection
201 <h4>Deliverable</h4><br/> 201 <h4>Deliverable</h4><br/>
202 <p> 202 <p>
203 {% trans %} 203 {% trans %}
204 The test cases in the CI are measuring the performance gains. This measurement can be compared with the measurement of milestone 5. Again one outcome of this milestone will be a stable release. 204 The test cases in the CI are measuring the performance gains. This measurement can be compared with the measurement of milestone 5. Again one outcome of this milestone will be a stable release. <a href="mile6.html">Details</a>
205 205
206 Documentation of the interpeer project analysis. 206 Documentation of the interpeer project analysis.
207 {% endtrans %} 207 {% endtrans %}
diff --git a/template/l2o/mile6.html.j2 b/template/l2o/mile6.html.j2
new file mode 100644
index 00000000..8a271dd4
--- /dev/null
+++ b/template/l2o/mile6.html.j2
@@ -0,0 +1,80 @@
1 {% extends "common/base.j2" %}
2{% block body_content %}
3<main id="maincontent">
4<article class="container">
5
6 <header>
7 <h1>{{ _("NGI Assure project: Layer-2-Overlay") }}</h1>
8 </header>
9
10 <div class="row">
11 <div class="col-2 d-none d-lg-block"><!-- for large viewports show menu for better orientation -->
12 <nav class="nav subnav position-fixed flex-column border-right" style="position:fixed">
13 <a class="nav-link" href="index.html#idea">{{ _("Project main page") }}</a>
14 </nav>
15 </div>
16 <div class="col">
17
18 <h2>Implementation details milestone 6</h2><br/>
19
20 <section>
21 <h4>{{ _("TNG Service") }}</h4><br/>
22 <p>
23 {% trans %}
24 <ul>
25 <li>Introduced frags_in_flight flag. With this flag we check if fragments of a PendingMessage are being send right now, to not resend single fragments, but the PendingMessage at once.</li>
26 <li>The time to wait for resending a PendingMessage - which was fragmented - is calculated, depending on the number of fragments present, and how much of the PendingMessage was already fragmented.</li>
27 <li>ValidationState now contains the addres prefix of the address being validated, because we have to check which communicator gave us the validation response.</li>
28 <li>Handling flow control takes used window size into account, together with data loss.</li>
29 <li>We do not update queue performance if PendingMessage was resend.</li>
30 <li>Changed test case to except 0.5% packet loss.</li>
31 <li>Removed misplaced sending of an acknowlegement in udp communicator.</li>
32 <li>GNUNET_SERVICE_client_continue was misplaced after receiving CORE Ack, blocking the service.</li>
33 <li>Fixed bug when checking, if fragment sub tree is done.</li>
34 <li>Fixed bug in calculation of delay for PendingAcknowledgement.</li>
35 <li>Fixed bug in calculation of subtree fragment message size.</li>
36 <li>Fixed bug that additional queues for the same communicator inherit the validity period.</li>
37 <li>Fixed logic bug when searching for QueueEntry matching acknowledgement.</li>
38 <li>Fixed misplaced increase of queue length.</li>
39 </ul>
40 {% endtrans %}
41 </p>
42 </section>
43
44 <section>
45 <h4>{{ _("Configuration") }}</h4>
46 <p>
47 {% trans %}
48 <table width="100%">
49 <tr>
50 <td width="60%" style="vertical-align: top;">src/transport/test_transport_simple_send_performance_topo.conf</td><td width="40%" style="vertical-align: top;">Changed configuration to use TCP and UDP together.</td>
51 </tr>
52 </table>
53 {% endtrans %}
54 </p>
55 </section>
56 <section>
57 <h4>{{ _("Performance Measurement") }}</h4>
58 <p>
59 {% trans %}
60 The performance increased to 160 MByte/s for packet size of 65000 bytes using TCP and UDP together.
61
62 There are still possibilities to increase performance documented as TODOs in the source code.
63 {% endtrans %}
64 </p>
65 </section>
66 <section>
67 <h4>{{ _("Synergie with Interpeer Channeler project.") }}</h4>
68 <p>
69 {% trans %}
70 The Interpeer library Channeler and the L2O project have some goals in common. These include independence of the transmission protocol used, congestion control, reliability. Other goals of the Channeler project are not goals of the L2O project, but are already implemented or planned for other layers of GNUnet, such as multiplexing and ordered delivery of packages. There are also goals of the L2O project that are not goals of the Channeler project, such as metadata protection and identity assurance of communication partners. Due to these half overlapping half disjoint targets it is not reasonable that on project makes use of the other as a whole. However, parts of one project may well be applicable in the other. Since the Channeler project is not yet completed, it is not yet possible to identify the interesting parts beyond doubt. Interesting for the further development of L2O is the "Zero-Copy and Buffering" functionality of the Channeler project. This is also planned for future versions of L2O.
71
72 In conclusion, both projects can benefit from each other. At this point in time, it is still too early to tackle this concretely.
73 {% endtrans %}
74 </p>
75 </section>
76 </div>
77 </div>
78
79</article>
80{% endblock body_content %}