Re: Implementing a cancelable task

[Christian Grothoff]

Hi Alessio,

I would like to help, but I doubt I fully understand your question! From
what I get, you want to do some action based on another peer sending you
a reply. So associating a unique number with the request that the other
peer is to include in the reply is indeed the right way to do this.
Sure, you cannot trust that the other peer does this correctly, but here
you should simply check that the unique number is in the list of
(active) unique numbers you shared with that peer. That way, you should
be able to limit what 'bad things' the other peer can do to sending a
reply to the wrong request -- which you cannot really prevent ever.

Anyway, if this doesn't help -- as it was already pointed out -- you may
also have better luck on the gnunet-developers list for this.

Given that I am not sure I fully understand the question, an even better
forum might be the ~monthly Mumble (next on August 8th at 8pm CEST) on
gnunet.org, as a more interactive medium may help people understand your
problem in the first place ;-).

Happy hacking!

Christian

On 7/23/20 11:53 PM, Alessio Vanni wrote:
> Hello,
> 
> I have a service doing the following:
> 
> * waits for a client to send a specific message
> * when the message arrives it opens a CADET channel
> * this channel is left open until the client requests it to be closed
> * the client sends another specific message
> * when the message arrives it is "unpacked" and sent over the channel
> * the remote peer replies with some data
> * when the data arrives it is "packed" and sent to the client
> 
> I'd like to make the parts where the client waits for the service
> "cancelable tasks", i.e. have a "cancel" function that stops any further
> operations on the canceled message from being executed.  Basically
> something like `GNUNET_SCHEDULER_cancel' or what the GNS service
> provides.
> 
> I've peeked at the implementation of some of those functions, but there
> are few things troubling me (might be because I don't know how the code
> works, but still.)
> 
> The first thing I saw was that those tasks use a unique ID embedded in
> the message. I tried something like that, but the CADET part doesn't
> make it practical, as I'd have to send the ID to the remote peer and
> hope that said peer doesn't change its value and/or use it for some
> nefarious purpose.
> 
> Ultimately the problem is that I don't have a reliable way to associate
> a task with the execution of a certain callback.
> 
> I was hoping someone could provide some help on the matter, especially
> since GNUnet has a lot of those cancelable tasks.
> 
> Thank you,
> A.V.
> 
> P.S. I tried subscribing to this list, but I can't tell if it succeeded
> or not. If it requires a mail confirmation, I didn't get anything after
> requesting the subscription.  This is actually the second time I tried
> and still nothing.  In this second attempt it might simply be a late
> delivery, but the first time I got nothing and I didn't receive anything
> of what was sent to the list afterwards.  I can receive mails from other
> sources just fine (though it seems some places can't receive from me) so
> I really don't know what's going on.
>

signature.asc
Description: OpenPGP digital signature