GSoC Work Product: GNUnet over QUIC
Hi, my name is Marshall and throughout the summer of 2023 I worked on developing a new communicator for the GNUnet transport service. I learned a lot about GNUnet through my development experience. Here are some details about the journey!
Goals of the Project.
The goal of this project was to develop a new transport, QUIC, for the Transport Next Generation (TNG) service. TNG is a successor to the previous transport plugins and will be running in the fall 2023 GNUnet release. At the time of writing, GNUnet currently supports transports over TCP, UDP, and UNIX sockets. I chose to implement a QUIC transport communicator due to the rising popularity and speed of this protocol. Because of this popularity, QUIC will be a great transport protocol for GNUnet traffic to sit on top of. QUIC is intended to be a faster alternative to TCP and tries to address some issues that TLS has.
What I completed.
One of the first steps was deciding 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. Once I finished these tasks, the QUIC communicator got merged upstream and is currently an experimental feature. This is due to the packaging situation with Quiche as it is difficult for some users to install the library, and there still may be bugs lingering in the QUIC communicator. More testing and refinement is needed to offer a truly robust and reliable communicator. Link to source code: QUIC communicator.
The current state.
The QUIC communicator currently functions and passes basic communicator tests. That being said, there are some latency issues that need to be addressed. Since the communicator suite is designed to run alongside the new TNG service, it is currently not usable since TNG is still under development (as mentioned previously). Mentioned below are some other things that have yet to be implemented in the QUIC communicator, but will be fixed in the future.
Future Work.
We still need to develop a more permanent solution to the certificate generation so that the Quiche API functions properly. This certificate generation has been done in previous implementations (for example the HTTPS plugin). Currently, we are using static, example certificates. Adding timers to each QUIC connection so that a timeout will trigger a connection to close also needs to be implemented. Finally, we should look into lowering the latency by finding points where the communicator is too slow and optimizing it.
Challenges I Encountered.
One of the challenges 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 examples that are 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.