Are you talking about the bulk transmission when the client is sending his "I am ready for new messages"? Yes, maybe I have to be careful not to interfere with that.
On 24.02.19 22:36, Schanzenbach, Martin wrote: > 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 <[email protected]> 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 <[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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
