summaryrefslogtreecommitdiff
path: root/template/l2o/mile6.html.j2
blob: 8a271dd476e2d4e66aa3a7b4f5c67e464bb05570 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
 {% extends "common/base.j2" %}
{% block body_content %}
<main id="maincontent">
<article class="container">

  <header>
    <h1>{{ _("NGI Assure project: Layer-2-Overlay") }}</h1>
  </header>

  <div class="row">
    <div class="col-2 d-none d-lg-block"><!-- for large viewports show menu for better orientation -->
      <nav class="nav subnav position-fixed flex-column border-right" style="position:fixed">
      <a class="nav-link" href="index.html#idea">{{ _("Project main page") }}</a>
      </nav>
    </div>
    <div class="col">

      <h2>Implementation details milestone 6</h2><br/>

      <section>
        <h4>{{ _("TNG Service") }}</h4><br/>
        <p>
          {% trans %}
	  <ul>
		<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>
		<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>
		<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>
		<li>Handling flow control takes used window size into account, together with data loss.</li>
		<li>We do not update queue performance if PendingMessage was resend.</li>
		<li>Changed test case to except 0.5% packet loss.</li>
		<li>Removed misplaced sending of an acknowlegement in udp communicator.</li>
		<li>GNUNET_SERVICE_client_continue was misplaced after receiving CORE Ack, blocking the service.</li>
		<li>Fixed bug when checking, if fragment sub tree is done.</li>
		<li>Fixed bug in calculation of delay for PendingAcknowledgement.</li>
		<li>Fixed bug in calculation of subtree fragment message size.</li>
		<li>Fixed bug that additional queues for the same communicator inherit the validity period.</li>
		<li>Fixed logic bug when searching for QueueEntry matching acknowledgement.</li>
		<li>Fixed misplaced increase of queue length.</li>
	  </ul>
	  {% endtrans %}
        </p>
      </section>

      <section>
	<h4>{{ _("Configuration") }}</h4>
        <p>
          {% trans %}
	  <table width="100%">
	  	 <tr>
			<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>
		</tr>
	  </table>
	  {% endtrans %}
	</p>
      </section>
      <section>
        <h4>{{ _("Performance Measurement") }}</h4>
        <p>
          {% trans %}
	  The performance increased to 160 MByte/s for packet size of 65000 bytes using TCP and UDP together.

	  There are still possibilities to increase performance documented as TODOs in the source code.
      	  {% endtrans %}
        </p>
      </section>
      <section>
        <h4>{{ _("Synergie with Interpeer Channeler project.") }}</h4>
        <p>
          {% trans %}
	  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.

	  In conclusion, both projects can benefit from each other. At this point in time, it is still too early to tackle this concretely.
      	  {% endtrans %}
        </p>
      </section>
    </div>
  </div>

</article>
{% endblock body_content %}