Skip to content

Merge "all" and "flat" reprovider strategies #10864

@guillaumemichel

Description

@guillaumemichel

Checklist

  • My issue is specific & actionable.
  • I am not suggesting a protocol enhancement.
  • I have searched on the issue tracker for my issue.

Description

Background

From the Reprovider.Strategy config

  • "all" - announce all CIDs of stored blocks
    Order: root blocks of direct and recursive pins and MFS root are announced first, then the rest of blockstore
  • ...
  • "flat" - same as all, announce all CIDs of stored blocks, but without prioritizing anything.

[...] The flat strategy can be used to lower memory requirements, but only recommended if memory utilization is too high, prioritization of pins is not necessary, and it is acceptable to announce every block cached in the local repository.

Since the reprovider strategy defines which KeyChanFunc to use for reprovides, it means that the prioritization happens only during reprovides, and not during provides.

Prioritization could make sense during the provide, but the current provide behavior doesn't depend on the reprovider strategy.

Problem

Since reprovides happen at regular intervals, before the records expire from the DHT swarm, prioritization isn't useful. It only matters that a key is reprovided before its provider record expires. (reprovide every 22h, provider record TTL 48h)

Furthermore, the prioritization of the all strategy consists in reproviding first pinned cids, then MFS cids, and finally all the cids from the blockstore (including pinned and MFS). Hence their is a lot of duplication that could be avoided by using the flat strategy (only provide cids from blockstore).

Suggestion

Use the flat strategy for all, since it reprovides the same set of keys, only with duplicates. It lowers the memory requirement, reduces network usage and shortens reprovide duration (since we don't reprovide duplicate keys).

We can mark flat as deprecated afterwards.

Alternatively, we can deprecate all and use flat as default. But all is more meaningful than flat if we are to keep only one.

Metadata

Metadata

Assignees

Labels

P2Medium: Good to have, but can wait until someone steps upeffort/daysEstimated to take multiple days, but less than a weekexp/expertHaving worked on the specific codebase is importantkind/enhancementA net-new feature or improvement to an existing feature

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions