Hi, On 01/14, Gix, Brian wrote: > I have some serious discomfort with an API to increase sequence numbers. On import, > the sequence number should be part of the data being imported, so I don't see a > direct need there to bump up the value afterwards. > > Plus, we handle sequence numbers differently than many other settings in the > system. To prevent storage thrashing, we "Pre-Reserve" a chunk of sequence > numbers that we store in node.json, and then real-time use these sequence > numbers for outbound packets without having to write to storage each time > (a power failure or other reset would then pick up after the reserved chunk). > And then it also feeds into the IV Index update feature as well. > > Giving an App the ability to arbitrarily increase it's sequence number puts > it into conflict with the natural usage of sequence numbers, and when we request > the IV Index Update. Ok, I appreciate that. Let's take a look from a different angle. As I mentioned some time ago, we're working on an automated test suite for the daemon. We need to know the current value of sequence number to verify payloads send to radio adapter. One can say that we're *eventually* aiming for, is a "test mode" of sorts. A significant part of the suite is checking the IV Update logic. As you've seen, there was/is a fair number of issues with the current implementation. We know from (painful) experience, that this part of the system is notoriously difficult to implement correctly and efficiently. One of the problems is verifying time-based behaviour. Mesh spec actually mandates that the device shall implement the test mode by removing state timers, but it doesn't say anything about triggering the node to start IV Update. So maybe we in the end we could enable SequenceNumber etc. access only when daemon is running with a certain configuration option (either commandline, of from the file)? regards -- Michał Lowas-Rzechonek <michal.lowas-rzechonek@xxxxxxxxxxx> Silvair http://silvair.com Jasnogórska 44, 31-358 Krakow, POLAND
