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

[Bernd Fix]

On 9/19/19 5:23 PM, Christian Grothoff wrote:
>> (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.

Yes, it will probably even work with older versions. But once Go 2 is
released, I will most likely use new features that are more restrictive
on the version.

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

Yes, of course that is 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.

That makes sense as long as GNUnet-C and GNUnet-Go are running in a
"mixed" mode (some services in Go and some in C). But my long-time goal
is to have all of it in Go (at least the "basic" system that is usable
for something on top of it), so I am tempted to use a more "modern"
approach to configuration in the long run.

I choose JSON at this stage just out of convenience: parsing the config
is a one-liner. This will not be the final solution anyway.

As an intermediate approach I can try out something like
https://github.com/go-ini/ini to "re-use" the exisiting INI
configuration and add all extras I might need and ignore the stuff that
is not needed.

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

Yes.

> The process always seems to use 100% CPU.

Yes. I didn't hunt that bug down yet, but it is a "busy loop" somewhere
in a "for { select {...}}" construct.

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

Happens sometimes that the signal for ^C is skipped somewhere in the Go
runtime; it works by sending a SIG_TERM (a SIG_KILL is overkill and ca
lead to problems, see below). It may take a few seconds for all
go-routines to finish before the program closes down.

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

Yes. A kill will not execute the cleanup for Unix domain sockets (which
removes the file from the filesystem).

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

Thanks, I didn't kow that. Yes, as the log shows the request was
processed (returning a block from Namecache or DHT), but it believes it
expired on Jan. 10th, 586524 -- and that that is in the past. At least
we now know when eternity starts... ;)

Thanks for the findings and comments - much appreciated.

Cheers, Bernd.