To be honest I did not checked if the oldest or the newest message is removed. I only looked onto the comment stating "Drop the oldest message in the buffer"
On 24.02.19 22:02, Schanzenbach, Martin wrote: > 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 <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/gnunet-developers >>> >> >> > > _______________________________________________ > GNUnet-developers mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
