[www] branch master updated: GSoC-QUIC: fill in answers

[gnunet]

This is an automated email from the git hooks/post-receive script.

marshall pushed a commit to branch master
in repository www.

The following commit(s) were added to refs/heads/master by this push:
     new e5a8502c GSoC-QUIC: fill in answers
e5a8502c is described below

commit e5a8502c0607ff1ff892b4b39202a55b84dff5df
Author: marshall <stmr@umich.edu>
AuthorDate: Thu Aug 24 20:52:45 2023 -0400

    GSoC-QUIC: fill in answers
---
 template/news/2023-08-GSoC-QUIC.html.j2 | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/template/news/2023-08-GSoC-QUIC.html.j2 
b/template/news/2023-08-GSoC-QUIC.html.j2
index 13a96123..4829b514 100644
--- a/template/news/2023-08-GSoC-QUIC.html.j2
+++ b/template/news/2023-08-GSoC-QUIC.html.j2
@@ -5,14 +5,23 @@
 <p>
 <ul>
 <li>A short description of the goals of the project.</li>
-<li>What you did (also include quich packaging).</li>
+The goal of this project was to develop a new transport, QUIC, for the 
Transport Next Generation (TNG) service.
+<li>What you did (also include quiche packaging).</li>
+First, I had to decide on a library that can process QUIC packets and would be 
available to users running different operating systems.
+We chose to go with Cloudflare's Quiche library because the C API seemed 
simpler than other available libraries. Installing cloudflare-quiche via the 
Homebrew package manager (MacOS) did not actually install the libraries 
properly for linking with other C programs so I made a pull request in the 
Homebrew repository and fixed the formula. 
+After this, I worked on handling the receiving functionality of the 
communicator. This involved reading from the socket then processing the QUIC 
packets using the Quiche library. Then I implemented the ability to send 
messages in a similar manner. One of the last steps involved connecting 
everything together with the transport service so that the communicator can 
receive information about peers and relay messages. 
 <li>The current state.</li>
+The QUIC communicator currently functions and passes basic communicator tests. 
That being said, there are some latency issues that need to be addressed.
 <li>What&#39;s left to do.</li>
+We still need to develop a more robust solution to the certificate generation 
so that the Quiche API functions properly. Currently, we are using static, 
example certificates. Adding timers to each connection so that a timeout will 
trigger a connection to close also needs to be done. Finally, we should look 
into lowering the latency by finding where the code is too slow and optimizing 
it.
 <li>What code got merged (or not) upstream.</li>
+The QUIC communicator got merged upstream and is currently an experimental 
feature. This is because the packaging situation with Quiche makes it difficult 
for some users to install the library and there still may be bugs lingering in 
the QUIC communicator. More testing is needed.
 <li>Any challenges or important things you learned during the project.</li>
+Something challenging about the project was reverse engineering the Quiche C 
API because it has such limited documentation. I learned how to make use of the 
API by looking at the very simple example client and server that is provided in 
the Quiche repository. There is documentation for the Rust API which seems to 
operate pretty similarly, so this was helpful too at times. I overcame this 
challenge with the help and guidance of my mentor Martin Schanzenbach.
 </ul>
 </p>
 <p>
   Other notes on experience.
 </p>
+Overall, my experience with GNUnet was fantastic. My mentors were friendly and 
consistently available when I needed help. I plan to continue contributing to 
GNUnet in the future.
 {% endblock body_content %}

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.