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

[Schanzenbach, Martin]

What I am trying to say is: The combination of an unreliable transport with in 
order message delivery inevitably leads to a "lock" (=wait for next "in oder" 
message).
If you want UDP behaviour and implement you own message queue/ordering on top, 
you should use a different option.

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

signature.asc
Description: Message signed with OpenPGP