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