Re: [GNUnet-developers] [GSoC] Question on "Rust implementation of GNUnet utils" project

[kc]

Hi Jeff,

Thank you for the insight, no wonder I couldn't find any Rust code!

I also feel starting with the second option is better since it has a
mucher lower entry barrier so I can start hacking ASAP.

I see that GNS lookup, peer info listing and identity ego lookups are
implemented. Do you think adding async IO to those functionalities by
mid-term evaluation is feasible? What would you like to see by the end
of the GSoC? Perhaps finish the "Next on the list" items?

I've used asyc IO in a few projects before. For instance I've
goroutines/channels (from golang) to implement a few distributed
algorithms such as for Byzantine agreement, leader election and mutual
exclusion. I also used some of the Haskell async libraries
namely Control.Concurrent for a project where we had to implement the
log-structured merge-tree. Finally, I've used pthreads when I was
working on an enterprise backup system. I don't have any async IO
experience in Rust but the paradigms shouldn't be to different.

Regarding those libraries, I can't say I'm familair with the state
machine based ones like rotor. On the other hand, I'm familair with the
concept behind Futures and Promises which is what gj and eventual_io
uses. Is there a preferred async IO model for GNUnet-rs or it's still
up for discussion?

Kind regards,
Kelong

On Sat, 2016-03-19 at 19:15 +0100, Jeff Burdges wrote:
> There is a project by Andrew Cann <address@hidden> on github here
> : 
> https://github.com/canndrew/gnunet-rs
> 
> It's referred to as "GNUnet bindings", but it's really a
> reimplementation of GNUnet utils, so that Rust code can speak some
> existing GNUnet IPCs.  Just fyi, one cannot make literal "bindings"
> because GNUnet code is too unsafe, well it's not even thread safe.
> 
> There are a couple things one might work on here : 
> 1.  Implement more existing GNUnet IPCs in gnunet-rs.
> 2.  Switch gnunet-rs to asynchronous IO using mio either directly or
> indirectly : https://github.com/canndrew/gnunet-rs/issues/1
> 
> I'd kinda recommend doing 2 first and then doing 1 if there is time,
> but
> if you're more interested in learning about GNUnet itself, then maybe
> just 1 from the beginning. 
> 
> Have you used asynchronous IO before?  What sort of model?  
> After hacking around inside the GNUnet utils scheduler, I developed a
> slight prejudice against basic callbacks, as used in GNUnet.  And
> towards something with more structure, like maybe the ADT state
> machines
> of rotor : https://github.com/tailhook/rotor
> Do any of rotor, gj, eventual_io, etc. sound/look like something
> you've
> used before?  I'll have a conversation with Christian this week about
> what GNUnet protocols look like to try to get a sense if one of these
> approaches is more amenable. 
> 
> Jeff
> 
> p.s.  There are cryptographic bindings in GNUnet utils, but that
> appears
> unnecessary.  I'd envision individual projects that using gnunet-rs
> using an orthogonal rust crypto library, either sodiumoxide,
> rust-crypto, or ring, well the crypto would always be a project
> talking
> to itself after all.
> 
> 
> 
> 
> On Sat, 2016-03-19 at 15:43 +0100, kc wrote:
> > 
> > Dear GNUnet developers,
> > 
> > I'm a MSc student currently studying in TU Delft, specialising in
> > cryptography and security. GNUnet aligns closely with my interests
> > so
> > I'm very excited about this opportunity with GSoC. 
> > 
> > I'm interested and would like to know about the "Rust
> > implementation of
> > GNUnet utils" project. The description implied that there are
> > existing
> > Rust implementations, but I couldn't find any *.rs files in your
> > SVN
> > repo.
> > 
> > Suppose there does not exist any Rust code yet, which utils would
> > have
> > the highest priority, i.e. that would benefit the most from asyc
> > IO?
> > 
> > Kind regards,
> > Kelong
> > 
> > _______________________________________________
> > GNUnet-developers mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/gnunet-developers