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:02:04 +0100

As far as I can see, the head element of a DLL is removed.
Unless elements are inserted at the tail (not the default) then the most 
recently cached message is evicted from the buffer.

Can you point me to the code you think this is happening?

> On 24. Feb 2019, at 21:56, Christian Grothoff <address@hidden> wrote:
> 
> Signed PGP part
> I agree with both of you, (1) default is in-order, so we may skip
> messages, but not break the order. But if t3sserakt is right that the
> code drops a more recent message in favor of an older message, that is
> also terrible and should not happen.
> 
> That said, I do remember that that entire unreliable messaging was never
> properly tested...
> 
> On 2/24/19 9:50 PM, 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
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> _______________________________________________
>> GNUnet-developers mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnunet-developers
>> 
> 
> 
> 

Attachment: signature.asc
Description: Message signed with OpenPGP


reply via email to

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