[Top][All Lists]

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

Re: [GNUnet-developers] Two questions regarding CADET application

From: Christian Grothoff
Subject: Re: [GNUnet-developers] Two questions regarding CADET application
Date: Fri, 30 Dec 2016 18:01:45 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

On 12/30/2016 03:41 PM, Heiko Stamer wrote:
> Am 29.12.2016 um 17:52 schrieb Christian Grothoff:
>> Ideally, your application should pick such a hash-port at random or
>> based on a shared secret of the various participants. In the rare cases
>> where you do need to hard code one, just use a string describing the
>> purpose and hash that.
> For CADET port numbers I can do the port selection in the described way.
> However, what's about the GNUNET message types?

Those remain at 16-bit and should be defined in gnunet_protocols.h as we
still want them to be globally unique.  Eventually I want to create a
software-based protocol number registration service, but for now we tend
to reserve a range of numbers for each subsystem that needs one. Feel
free to give us a guess as to how many message types you need (and what
your subsystem prefix is), and we can reserve that range.

>>> 2) GNUNET_PROGRAM_run() does not terminates, if services (i.e. ARM) are
>>> not running. Is this behavior intended? (Workaround: should I use exit
>>> in shutdown task?)
>> GNUNET_PROGRAM_run() will only terminate once all activities of your
>> process have terminated. Usually, the issue behind such non-termination
>> is that you need to install a shutdown task and use it to explicitly
>> stop ongoing actions.
> This is exactly what I did. I implemented a shutdown task (registered
> with GNUNET_SCHEDULER_add_shutdown) which is called in case of errors
> and e.g. by interrupting the main loop through SIGTERM. When GNUNET
> services are running, everything terminates fine. Otherwise the control
> also left this shutdown task but the calling GNUNET_PROGRAM_run() does
> not terminates while trying to connect to ARM service. As a workaround I
> can call exit(GNUNET_OK) in the shutdown task, but I guess this is not
> intended?

Indeed. It is likely that without GNUnet ARM running the other services,
your program is "stuck" somewhere and failed to complete some operation,
and that one is what your current shutdown-routine fails to clean up.

A common way to diagnose is to go into gdb and to inspect the
pending*-DLLs in scheduler.c that are keeping the process alive.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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