iarv/ipfs-blog
0
0
Fork 1
mirror of https://github.com/ipfs/ipfs-blog.git synced 2026-03-28 17:32:37 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update src/_blog/2023-05-multi-gateway-browser-client.md

Browse Source 
Co-authored-by: Steve Loeppky <stvn@loeppky.com>
This commit is contained in:
John Turpish
2023-05-30 06:40:33 -04:00
committed by GitHub
parent 02ce414503
commit b630ff5efd
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
src/_blog/2023-05-multi-gateway-browser-client.md
View File

@@ -54,7 +54,7 @@ In each case, you're delegating all the "IPFS stuff", including CID (hash) verif
If the gateway you're using happens to have the data you're seeking already on-hand, your performance will be great, since it can simply return to you what it already has. Perforance might even be better than the multi-gateway client, since no extraneous requests would be made. However, if you were unlucky, that gateway will have to spend more time querying the IPFS network to try to find the data you request before it gives up. The ideal gateway to use may very well depend on what you happen to be doing at the moment - and may differ from one of your tabs to another. A multi-gateway client will have the worst case performance more rarely.
It's also conceivable that for a sufficiently large file which exists on multiple gateways you're talking to, a verifying multi-gateway client might be able to beat a single-gateway client, since you might be pulling down parts of the file from different sources concurrently. [RAPIDE](https://pl-strflt.notion.site/RAPIDE-3c4fb9e159ae471bb426bb81855cee16) is a more advanced client which also makes use of this principle (along with other things).
It's also conceivable that for a sufficiently large file which exists on multiple gateways you're talking to, a verifying multi-gateway client might be able to beat a single-gateway client, since you might be pulling down parts of the file from different sources concurrently. [RAPIDE](https://github.com/ipfs/go-libipfs-rapide/issues/12) is a more advanced in development client which also makes use of this principle (along with other things).
And while we've been talking about "files" for the most part, IPFS breaks larger files down into "blocks". You can apply these same techniques at the block level. Rapide is an implementation of this which is showing promising results - watch a [recent talk from IPFS Thing by Jorropo](https://www.youtube.com/watch?v=Cv01ePa0G58) on it. Perhaps native browser implementations could integrate these approaches for further improving performance - perhaps even beating regular HTTP web performance.