www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Looking for a mentor for SAOC

reply Vlad =?UTF-8?B?Q2hpY2/ImQ==?= <vladut.chicos gmail.com> writes:
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!
Sep 12 2022
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Monday, 12 September 2022 at 10:26:16 UTC, Vlad Chicoș wrote:

 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.


For anyone interested in this, Symmetry pays $500 to every 
participating mentor at the end of the event. The primary duties 
of a mentor are as follows:

* assist the mentee with the initial project planning (milestone 
development)
* provide the mentee with guidance as needed throughout the event
* review the mentee's monthly milestone reports before the mentee 
submits them to the judges
* submit a review of the mentee's progress at the end of each 
milestone

The following document is aimed at the mentees, but it contains 
information potential mentors my find useful:

https://gist.github.com/mdparker/47d77649d2a09c31f529160b4176512f

Ultimately, it's up to each mentor how and how often to make 
themselves available. Some mentees require very little guidance, 
others require more. As a baseline, we recommend weekly video 
chats to keep an eye on progress if nothing else.

In this case, existing knowledge of the QUIC protocol, though 
useful, isn't necessary---that can be picked up on the fly. 
What's more important, aside from a willingness to help, is a 
strong background in D.

Additionally, the first milestone kicks off in a few days. We can 
make sure Vlăduț gets a good start on the initial milestone list, 
but any mentor who comes in should help refine it going forward.

Please let us know here, or email me at social dlang.org, if 
you're interested.

Thanks!
Sep 12 2022
prev sibling parent Adam D Ruppe <destructionator gmail.com> writes:
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.
Sep 12 2022