Apply the record cap to the path store in Transport::start() - #76
Open
wet-bulb wants to merge 1 commit into
Open
Apply the record cap to the path store in Transport::start()#76wet-bulb wants to merge 1 commit into
wet-bulb wants to merge 1 commit into
Conversation
Transport::start() calls set_max_recs() for the packet-hashlist store and the known-destinations store, but never for the path store. microStore's policy_max_recs defaults to USTORE_DEFAULT_MAX_RECS, which is 0 and means "disabled", so the RNS_PATH_TABLE_MAX default of 100 never reaches the store. A consumer building directly on the library therefore runs with an uncapped path store unless it calls Transport::path_table_maxsize() itself. The same value gates compact_if_threshold(), where the dead-record percentage is computed relative to policy_max_recs. Leaving it unset therefore disables both the record cap and the threshold compaction that reclaims TTL-expired records nothing ever reads back. Lazy per-access removal in get()/exists() cannot help those, because nothing accesses them. Defaults are unchanged: 100 stays 100, it simply takes effect. Verified against a real BasicFileStore over a host filesystem: with the cap unset, 300 inserts leave 300 records; with it set to 100, 300 inserts leave exactly 100.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the path table size limit never being applied
Transport::start()callsset_max_recs()for the packet-hashlist store and the known-destinations store, but not the path store. microStore'spolicy_max_recsdefaults toUSTORE_DEFAULT_MAX_RECS(0, disabled), so theRNS_PATH_TABLE_MAXdefault of 100 never reaches the store.The same value is used by
compact_if_threshold(). Leaving it unset disables both the record limit and threshold compaction. Lazy cleanup inget()andexists()does not cover this case, since expired records that are never accessed remain in storage.The fix is to call
set_max_recs()for the path store duringTransport::start(), matching the other stores.Nothing changes for users overriding the limit. The default remains 100.
Against the Python reference
Checked against
b48b96e.Transport.py:115-path_table = {}, with no count limit.Transport.py:794andTransport.py:901- path entries areremoved by expiry.
Transport.py:177andTransport.py:656-hashlist_maxsize = 1000000, trimmed by count.The Python implementation limits paths by age. microReticulum limits them by count.
RNS_PATH_TABLE_MAXandTransport::path_table_maxsize()already existed, andmicroReticulum_Firmwarealready sets the value at boot withURTN_PATH_TABLE_MAX_RECS. This fixes the missing connection between that value and the store.Testing
Tested on
BasicFileStoreover a host filesystem.300 inserts leave 300 records without the limit, and 100 records with the limit set to 100.
Not tested