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: t3sserakt
Subject: Re: [GNUnet-developers] Cadet bug: blocked cadet channel in case of non reliablle channel
Date: Sun, 24 Feb 2019 22:41:29 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

Ok, I understood your point.

If the message we waited for in the first place will appear, it would be received out of order.

We just drop it :-) Some message would be dropped anyway.

If we do not do this the channel is blocked for ever if that message will never appear.

On 24.02.19 22:09, t3sserakt 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






      
_______________________________________________
GNUnet-developers mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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