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

[Schanzenbach, Martin]

Ah the DLL is sorted by message ID. Well. Then eviction in this order does not 
make sense, I guess ;)

> On 24. Feb 2019, at 22:02, Schanzenbach, Martin <address@hidden> wrote:
> 
> Signed PGP part
> 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
>>> 
>> 
>> 
>> 
> 
> 
>

signature.asc
Description: Message signed with OpenPGP