Hi! I am interested in working on this project : https://github.com/dlang/projects/issues/84 (QUIC Protocol) and I am in search of a mentor. The judges proposed me to work on an implementation of QUIC Protocol that does not have a hard dependency on vibe.d.  In order to achieve this, I want to work on an abstraction layer of multiple components like an UDP socket, threads, and some synchronization mechanisms(Mutex for example) to handle the concurrent nature of QUIC. As Sönke suggested me, an initial implementation of this abstraction layer could involve the Druntime primitives(with fibers behind the "Thread", for example).

This protocol puts an emphasis on encryption, so the project should start by implementing a compliant handshake that exchanges both transport and TLS 1.3 related information.

Thank you!

On Monday, 12 September 2022 at 10:26:16 UTC, Vlad Chicoș wrote:
> an implementation of QUIC Protocol that does not have a hard dependency on vibe.d.  In order to achieve this, I want to work on an abstraction layer of multiple components like an UDP socket, threads, and some synchronization mechanisms(Mutex for example) to handle the concurrent nature of QUIC.

I don't know quic specifically, but I find it hard to believe you actually would need all those things. A network protocol implementation doesn't even need sockets at all - it would work with internal things and you feed it data from the network on the edges and it tells you when it needs to read/write via return values. Like how OpenSSL works, for an example to look at.

Similarly, concurrency with network connections can be done with separate substream state objects that can read/write to the same main provider, and when you want to read from one thing it will do something like return "needs more read". Again, OpenSSL can already work this way in its nonblocking mode so it is an example.

Then code on top of it can either block on it, or yield on it, or whatever it wants to do. But the core implementation doesn't have to know.