gnunet-developers
[Top][All Lists]
Advanced

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

Re: [GNUnet-developers] Cadet bug: blocked cadet channel in case of non


From: Schanzenbach, Martin
Subject: Re: [GNUnet-developers] Cadet bug: blocked cadet channel in case of non reliablle channel
Date: Sun, 24 Feb 2019 22:36:59 +0100

I think changes in the queue eviction are unproblematic.
The bulk transmission of messages makes me worry a bit as CADET seems to have a 
special logic for that including (local) client ACKs so you needn't worry about 
that at that point anyway.

> On 24. Feb 2019, at 22:09, t3sserakt <address@hidden> wrote:
> 
> Hey Martin,
> 
> my proposal will not deliver messages out of order.
> 
> It just will not wait for a message to appear and drop another message
> we already received instead.
> 
> On 24.02.19 21:50, Schanzenbach, Martin wrote:
>> Hi,
>> 
>> a quick look into the bug (not a CADET expert) makes me questions the 
>> proposed behaviour:
>> 
>> "Proposal how to change that behavior:
>> 
>> We will not drop the oldest message in the queue, but we send as much 
>> messages from the queue as we have messages with consecutive MIDs. After 
>> that the queue is empty, or we again wait for the message that is missing 
>> now. Means we have to set the expected MID to that MID, because we are now 
>> waiting for another message to arrive."
>> 
>> Now, looking at the API of CADET, this channel has the following description:
>> 
>> /**
>>   * Default options: unreliable, default buffering, not out of order.
>>   */
>>  GNUNET_CADET_OPTION_DEFAULT    = 0x0,
>> 
>> 
>> Ergo, messages are _not_ delivered out of order. But that seems to be what 
>> you propose?
>> The transport is unreliable. So if you need any other behaviour, don't you 
>> just want a different OPTION? There are a few to choose from with that 
>> behaviour, no?
>> 
>> BR
>> 
>>> On 24. Feb 2019, at 21:33, t3sserakt <address@hidden> wrote:
>>> 
>>> Signed PGP part
>>> Hey *,
>>> 
>>> please have a look onto this finding:
>>> 
>>> https://bugs.gnunet.org/view.php?id=5597
>>> 
>>> If nobody has a veto, I would change the behavior of non reliable cadet
>>> channels, as I proposed in the bug description.
>>> 
>>> 
>>> Cheers
>>> 
>>> 
>>> t3sserakt
>>> 
>>> 
>>> 
>>> 
>>> 
> 

Attachment: signature.asc
Description: Message signed with OpenPGP


reply via email to

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