Revert random and long `rule_id` to integer and sequential `rule_id`

[Chibikuri]

Is your feature request related to a problem? Please describe. In the current implementation, I defined rule_id with unsigned long and random assigned variables, but it turns out we don't have to make it long and random. As long as ruleset_id is unique, we can guarantee the rule_id is unique.

Describe the solution you'd like Change all unsigned long rule_id into int rule_id with the proper sequential assignment.

[zigen]

we should use type alias https://en.cppreference.com/w/cpp/language/type_alias like using RuleID = unsigned int

and rule_id should be unsigned. no reason to use the signed type.

[Chibikuri]

ah, that's a good idea

[pfittipaldi]

Hi there! I've been working on this issue but I had some questions, if you don't mind.

• In Rule.h, line 26, you set a Rule ID to -1. This will not be possible with the new uint type. I get this is used for incomplete rules, and doing that on a uint sets it to 4294967295. This makes no difference in practice as the checks on (rule_id == -1) still work properly, but I wanted to ask you if there's any "cleaner" way of addressing this, since I don't have a deep computer science background.

• I think I've found a small bug, that is easily spotted and fixed through this issue: in HardwareMonitor.cc, line 616, there is a funcion, sendLinkTomographyRuleset, that takes a rule_id as input. However, in its prototype in HardwareMonitor.h line 81 it takes a ruleset_id. This bug was unnoticed because rule_id and ruleset_id were the same type, but I think the correction would be to have both the prototype and the function take a ruleset_id.

• Probably the shared_tag variable in Rule.cc should be a RuleID. I am not completely sure of what it does so I didn't touch it for now but it seems to be related to the ID of another rule.

• Finally, concerning the "making rule id sequential" part of the issue, do you mean the hardcoded rule_id's you have in some examples? If not, I have been looking for the piece of code responsible for generating rule_id's but I cannot find it. Speaking of this, bit of a broader question: I would be interested in seeing what a Ruleset looks like while a simulation is running. Is there a way to do so? From the code I gather that I'm supposed to look for .json files, but I haven't found where they are.

Thank you very much!

[zigen]

1. For the first question, do we really need to set rule_id as -1 ? This denotes that the rule is not initialized but seems like bad practice. If we need to check whether the rule is valid, we should do it another way. I think we don't need to initialize it with -1, and we can remove the checks.

2. for the HardwareMonitor, It seems a bug, and it should be a ruleset id. It would be nice if you fix it.

3. the shared_tag is different from RuleID. We use the shared_tag for purification rules to find which rule corresponds to which rule across the QNodes. So please leave it.

4. for the RuleID generation, the Runtime treats this and make it sequential. so you can ignore it for now. FYI, the rule id generation is here, wait it's already sequential...

to check the content of the RuleSet, you can see it on wasm version. the Rulesets are generated by the responder, and the SetupConnectionResponse packet transfers it to the intermediate nodes and the initiator. then open the results jsonl file, and you can check it like this screenshot. see also this guide

thanks!

[Naphann]

@zigen is this issue still relevant? I think rule_id is now assigned sequentially inside the Runtime and we no longer assigned them manually or randomly assigned them.