Re: [GNUnet-developers] gnunet-go: Milestone #1 reached

[Christian Grothoff]

Hi!

Great news, comments inline below.

On 9/18/19 5:49 PM, Bernd Fix wrote:
> =========================================
> GNUnet-Go: Status report for Milestone #1
> =========================================
> 
> I am happy to announce the completion of the first milestone for the
> GNUnet-Go project. The objective was to implement a simple
> GNUnet-compatible GNS service in Go that can do non-recursive resolution
> of names.
> 
> If you want to check out for yourself, here is how to do it on a Linux box:
> 
> (2) Install Go1.13 on you computer:
> -----------------------------------
> Either install a binary version at https://golang.org/dl/ or compile
> from sources after cloning the Git repository
> https://github.com/golang/go. Make sure the required environment
> variables are setup correctly (check with 'set | grep "^GO"' for
> meaningful settings).

It seems to work with Go 1.12 (Debian unstable) as well.

> (5) Run the gnunet-go-gns service:
> ----------------------------------
> 
> * The executable 'gnunet-service-gns-go' is found in the bin/ folder;
> copy it anywhere you like - it does not have dependencies (statically
> linked).

It would be nice to have a GNU-ish 'configure, make, make install'
process here, instead of having to manually copy binaries around. Or why
not just a nice 'go get' that also fetches the dependencies?

> * Copy the file "<repo>/src/config/gnunet-config.json" to the folder you
> want to use as the working directory for the service. 

"src/gnunet/config/gnunet-config.json" would be the correct path.

> This is the config
> file for Go-based GNUnet services. You can look at it (it is very small
>  at the moment), but there should be no need to change something.

That depends on how you configured your GNUnet peer. If you changed
anything from the defaults, you may have to change stuff in the
JSON.

It would be much nicer if the Go implementation could stick to
GNUnet's existing INI syntax for configuration, and also parse the
configuration of $GNUNET_PREFIX/share/config.d/ and
~/.config/gnunet.conf to find those values.

> * Start the service from the working directory; it will create a new
> socket 'gnunet-service-gns-go.sock' for message exchange (requests). The
> service will run as a foreground process and output log messages
> directly to the console (best to run it in a separate screen).

The service fails to start if GNUnet is not already running and has the
sockets open.

The process always seems to use 100% CPU.

When I tried to terminate it with CTRL-C, it failed to stop.

When killing it hard, it left behind a file
/tmp/gnunet-system-runtime/gnunet-service-gns-go.sock. Trying to start
the service with that file still present failed (without adequate error
message).

> * Create a small new GNUnet config file to tell GNUnet utilities which
> GNS socket to use; we want them to use our new socket. Easiest is to
> copy the existing gnunet.conf to gnunet-go.conf and add the following entry:
> 
>  [gns]
>  UNIXPATH=/tmp/gnunet-system-runtime/gnunet-service-gns-go.sock
> 
> Don't change the master gnunet.conf as it will for sure break your
> existing GNUnet node!
> 
> * Do name resolution with the Go-based GNS service:
>   $ gnunet-gns -t ANY -u myname.myzone -c gnunet-go.conf

That failed for me, I suspect it is because you are not handling certain
expiration times nicely:

$ gnunet-identity -C bar
$ gnunet-namestore -a -z bar -t A -V 1.2.3.4 -p -n foo -e never
$ gnunet-gns -c ini -u foo.bar
No results.
s
The resolver printed:

Sep 19 19:05:26{I}[gns] Received msg:
GNSLookupMsg{Id=0,Zone=0QXM4QWQSRJC70XG5GHD6C3FD871QVADJETD1DFV95QCP78A8W1G,Options=1,Type=1,Name=foo}
Sep 19 19:05:26{I}[gns] Lookup request received.
Sep 19 19:05:26{E}[gns] block expired at 586524-01-19T09:01:49.000615+01:00

You might want to look into the handling of the UINT64_MAX value for
absolute time, which has the special meaning of 'never' (similar to the
same value for relative time, which means 'forever'). The conversion to
a string should also special-case those values.

> The next milestone will handle recursive lookups.

Looking forward to it!

Christian