Pascal Thubert (pthubert) writes: > But this is another discussion entirely. It is about the transaction > that associates new timeslots to a bundle and why we need a > correlator, or transaction ID. I was explaining that if the parent > wait for the ack to allocate a slot that was negotiated, and there > is no flow after that, then if the ack is lost the child thinks the > slot is allocated and the parent does not. The child may start using > it wrongly.
Which is why you should not use ACK for anything like that, but instead use application level messages for that kind of things. > The point behind this is that if the transaction does not complete, > it must be retried from scratch with the same sequence, or it must > time out and roll back. Receiving or not receiving ACK should not cause transaction to complete or not to complete, there must be some kind of application level message to indicate that it was successful if that information is needed in the peers. -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
