gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Fwd: Re: [GSoC] Question on "Rust implementation


From: Andrew Cann
Subject: Re: [GNUnet-developers] Fwd: Re: [GSoC] Question on "Rust implementation of GNUnet utils" project
Date: Mon, 18 Apr 2016 02:09:58 -0400
User-agent: Mutt/1.5.23 (2014-03-12)

Sorry to take so long to get back. I've been putting off replying because
what's going on at MaidSafe regarding this stuff is kind of up-in-the-air at
the moment. 

> Yes, we should see if we can reuse any of those components. My issue with NAT
> libraries is that coming up with a good generic API is tricky, especially
> given that asking third parties to assist with NAT traversal inherently
> requires coordination with higher layers.

As far as I can see, there's two things that a NAT library needs the upper
layers to do for it:

    (0) Tell it the addresses+ports that they see it as.
    (1) Route messages to/from the peers that its trying to punch holes to.

(0) Can be covered by something very generic, eg. STUN.
(1) Can be handled generically on the library-side, eg. when you want to create
    a NAT-traversed tcp connection between two peers, you call some function
    tcp_rendezvous_connect on both sides, pass them each a callback that gets
    called every time they have data they need you to route to the other peer,
    and every time you get data from the other peer you call some function to
    pass it to the in-progress rendezvous connect. In Rust, a blocking version
    of this might look something like:

    fn tcp_rendezvous_connect<C: Read + Write>(channel: C)
            -> Result<TcpStream, Error> { ... }

    The NAT-traversal library uses the channel to coordinate with the other
    peer and exchange information about external endpoints. The only
    responsibility of the higher layers is to implement the channel.

> As for sharing "core" logic, there are a few questions to answer:             
>                                                                               
> 1) do you really have sufficiently similar semantics?
> 2) do you really support multiple pluggable transports?
> 3) do you really support resource allocation / transport selection 
>    (ATS in GNUnet)?
> 4) can we get our "DV" routing to work in this context?

No. GNUnet's lower-layers are far more advanced than MaidSafe's. But we'll be
looking to overhaul the lower layers of the network in the coming months which
is an opportunity to make things more "GNUnety". The main problems with just
using the GNUnet libraries are that they're written in C, not thread-safe and
they force you to use the GNUnet event loop.

If there was an effort to rewrite core in rust then MaidSafe *might* be willing
to join forces. But it would need to be discussed with people above me.

> That said, the crust documentation I found was VERY high level, so maybe
> a first step would be for you to point me to detailed documentation on
> the crust API/specs/code --- the starting point here really needs to be
> a list of features, not the code itself.

That level of documentation hasn't been written. But as I say, everything
crust-and-below is looking to be rewritten in the near future. All the new
implementation will need to be able to do to be feature-compatible with the
current implementation is:
  * Connect peers over tcp and udp
  * Nat-traversal/hole punching
  * Local network peer discovery

> "> When Rust is ported to OpenWRT also Maidsafe can run its first
> experiments
> > with open-wireless-networks.
>
> Are you aware of any efforts in that regard?
> All I ever found was a very hacky guide on how to build an outdated
> version Rust using the OpenWrt-toolchain -- no integration or packaging
> was provided. Afaik Rust depends on it's own embedded version of LLVM,
> which is rather hard to natively integrate into OpenWrt's toolchain...
> "

Not really. This github project seems to indicate that it's possible to compile
Rust programs for OpenWRT: https://github.com/japaric/rust-on-openwrt

 - Andrew

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]