I think changes in the queue eviction are unproblematic. The bulk transmission of messages makes me worry a bit as CADET seems to have a special logic for that including (local) client ACKs so you needn't worry about that at that point anyway.
> On 24. Feb 2019, at 22:09, t3sserakt <t...@posteo.de> 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 <t...@posteo.de> 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
_______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers