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 <[email protected]> > 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 <[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 >> >> >> >> >> > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
