adam/ipfs-blog
1
0
Fork 0
mirror of https://github.com/ipfs/ipfs-blog.git synced 2026-08-09 10:22:56 +02:00
Code Issues Packages Projects Releases Wiki Activity

With the latest code PR we do actually enforce a limit.

Browse Source
This commit is contained in:
John Turpish
2023-05-22 14:24:10 -04:00
parent 854807950f
commit e5d65455e1
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/_blog/2023-05-multi-gateway-browser-client.md
+1 -1
View File
@@ -130,7 +130,7 @@ These nodes each have a `data` byte array that is the contents of a file. We'll
In UnixFS a node can represent a file as the concatenation of other file nodes, to which it has `links`. The decision to use this kind of node generally has to do with the size of the file. A single node can't be much more than a megabyte, so files larger than that get cut into chunks and handled as a tree of nodes. There are a couple of reasons for that:
* Data deduplication (it's possible the same sequences of bytes, and thus same CID, appears in multiple files or even within the same file)
* In the case that a gateway were malicious, we wouldn't want to wait until a file of potentially unbounded size finishes downloading before we verify that it's correct. It is worth mentioning that as of today ipfs-chromium does not enforce this limit.
* In the case that a gateway were malicious, we wouldn't want to wait until a file of potentially unbounded size finishes downloading before we verify that it's correct. "ipfs-chromium" enforces a limit of 2MB per block.
* It enables the possibility that one could concurrently fetch different parts of the file from different gateways.
If we have all the nodes linked-to already, we can concatenate their data together and make a response body out of it. If we don't, we'll convert the missing links to CIDs and request them from gateways.