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. _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
