[Top][All Lists]

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

Re: CADET API: Obtaining the CADET channel closure?

From: Schanzenbach, Martin
Subject: Re: CADET API: Obtaining the CADET channel closure?
Date: Tue, 1 Jun 2021 20:17:29 +0000

Hi Alessio,

> On 1. Jun 2021, at 21:23, Alessio Vanni <> wrote:
> Christian Grothoff <> writes:
>> Hi Alessio,
>> You should store a copy of the 'cls' together with your channel handle.
>> Typically, the 'cls' would actually point to the struct in which you
>> store your channel handle. So if you do this in any reasonable way, you
>> should not need an API to lookup the 'cls' from the handle.
>> If you can point me to your code and where you need the 'cls', I might
>> be able to suggest how to do this...
> Apologies for the late reply, I had some personal troubles I had to take
> care of and it took a few days.
> Getting the code out of context is a bit hard, but essentially currently
> it does this, at a very high level:
> - on demand, open a channel to some place
> - stash the channel somewhere until it's requested again or closed
> - when appropriate, operate on the channel (sending or receiving)
> - close the channel on demand or after some heuristics decide to
> Those actions in themselves are not issues conceptually, but as it is
> I've found myself that in some places I have only the channel but I also
> need e.g. some informations about the place it was stored in, and those
> informations are not available "externally", at least for now, thus the
> attempt at extracting the closure.
> I'm trying to redesign the thing so that it doesn't depend on that, but
> so far it's been a bit difficult, which is why I asked if it was
> possible to get the closure somehow.
> This was mostly a question about style or best practices, I guess, more
> than something technical.  If it's really "not the right thing" to do,
> I'll try to depend less on the closure on the channel and see if I can
> use some other data type somehow.

As Christian said it is quite common to "wrap" the "bare" handle into a struct 
has a reference to the closure data.
So in this case, the "struct GNUNET_CADET_Channel" is the "bare" handle, so 
when you
create it using "GNUNET_CADET_channel_create" (where you also provide the 
instead of "storing" the handle, you create a new helper struct instance. For 

struct MyChannelHandle
  struct GNUNET_CADET_Channel *handle;
  void *cls; // This does not have to be void. its your context data/closure

So, in your application/service context, the handle to a CADET channel is not 
only the bare
handle. At least if you plan to use a closure. It is the handle AND the 
closure. So you need
such a helper struct.
In fact, it is very likely that you need such a struct anyway in order to 
"cleanup" if your
process is shut down: You must have a way to iterate and destroy all handles.
So often, the helper struct actually looks like this:

struct MyChannelHandle
  struct MyChannelHandle *prev; // DLL
  struct MyChannelHandle *next; // DLL
  struct GNUNET_CADET_Channel *handle;
  void *cls; // This does not have to be void

This allows you to use the struct as a DLL (gnunet_container_lib.h).
When you "manually" handle a CADET connection in your code, you should always
handle a MyChannelHandle.

Now one trick you can do is to use the MyChannelHandle as the closure to the 
CADET API itself.
This way, you do not need to iterate over the DLL when being called with the
closure only. (helpful for cleanup)


> Thanks,
> A.V.

Attachment: signature.asc
Description: Message signed with OpenPGP

reply via email to

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