You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since deploying parallel bitswap, we're seeing a huge spike in size of requested content from upstream providers.
I think this is cause Block Limits are really functioning the way we expect them to with preloading. Currently, we handle block limits directly in the HTTP handler / CAR streaming layer with the LimitStore. This worked when link loading matched 1:1 with sending blocks over the wire. But with the preloader, we can now load potentially infinite numbers of links ahead of time without affecting the blocks on the wire. We should pass the block limit into the link budgets used in Bitswap somehow (or maybe put the limit store on top of the preload store as well?).
The text was updated successfully, but these errors were encountered:
What
Since deploying parallel bitswap, we're seeing a huge spike in size of requested content from upstream providers.
I think this is cause Block Limits are really functioning the way we expect them to with preloading. Currently, we handle block limits directly in the HTTP handler / CAR streaming layer with the LimitStore. This worked when link loading matched 1:1 with sending blocks over the wire. But with the preloader, we can now load potentially infinite numbers of links ahead of time without affecting the blocks on the wire. We should pass the block limit into the link budgets used in Bitswap somehow (or maybe put the limit store on top of the preload store as well?).
The text was updated successfully, but these errors were encountered: