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

[Christian Grothoff]

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.

signature.asc
Description: OpenPGP digital signature