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: Christian Grothoff
Subject: Re: [GNUnet-developers] Fwd: Re: [GSoC] Question on "Rust implementation of GNUnet utils" project
Date: Mon, 18 Apr 2016 08:29:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0

On 04/18/2016 08:09 AM, Andrew Cann wrote:
> 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. 

Sure. No rush. I'll have very high latency a bit myself.

>> 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.

STUN is insecure as it leaks data about internal networks. You might
want to look for certain RFC numbers in the published parts of the
Snowden archive ;-).  So it might be a starting point, but we ought to
try to improve it before declaring victory here...

> (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.
>

I wasn't saying it couldn't be done, I just haven't seen it done well.

>> 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.

We have a few people interested in porting some key parts of GNUnet to
Rust. We also have a semi-urgent item on our agenda to make the GNUnet
event loop "exchangable", i.e. that you can combine it with libevent,
libev or other event loop styles.  There'll still be the
GNUNET_SCHEDULER-API, but it won't be as draconian as it is today.

However, rewriting anything _major_ in Rust isn't on my agenda, and
there are reasons to have C implementations around for various
scenarios. That said, if we can make the IPC APIs compatible, I'm
perfectly happy to have both available and if the Rust one becomes
better, make that the default.

>> 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

Sure, that's a minimum set we can consider part of what we even call
"transport" or "crust".  Anyway, if MaidSafe is interested, we should
definitively discuss how to join forces on this with the goal of
becoming compatible; I'd also be happy to host a hack-a-thon in Rennes
to discuss APIs, designs, and get dirty with actual code.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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