js清空本地存储_「IPFS红岸智能」js-IPFS 0.50.0性能再次提升

原创：Alex Potsides

原文链接：https://blog.ipfs.io/2020-09-14-js-ipfs-0-50/

由红岸智能编译

亮点

在多个选项卡和密码文件之间更快地共享IPFS节点

js-IPFS@0.50.0 具有在多个浏览器选项卡之间共享节点的功能，并大大提高了固定性能。

我们还将逐步淘汰使用Node.js缓冲区作为数据类型，而使用标准JavaScript Uint8Arrays。

继续阅读以获取全部详细信息！

browser在浏览器选项卡之间共享节点

IPFS节点与网络上的其他节点建立了很多连接，而且由于默认情况下已打开了代理节点，因此建立了更多连接。这是为了确保您有最大的机会在网络上找到内容，因此其他人也有最大的机会在网络上找到您的内容。

但是，这并非没有代价，维护多个连接可能会占用大量资源，并且在某些情况下，浏览器会限制您可以拥有的并发连接数。

如果用户在两个选项卡中打开您的应用，这可能会在Web浏览器中出现问题，突然您有两个运行的节点的打开连接数是打开的两倍。更糟糕的是，他们共享一个数据存储和相同的对等ID。

ipfs-message-port-client和ipfs-message-port-server形式的帮助就在眼前，这使您可以在SharedWorker中运行一个IPFS节点并在应用程序中的多个选项卡之间共享它。

不久将在此主题上发表更深入的文章，但与此同时，请查看browser-sharing-node-across-tabs示例以了解如何使用它！

固定性能

在向本地IPFS节点添加内容时，会将其固定在适当的位置，以防止在垃圾回收期间删除构成文件的块。将该引脚放置在一组称为引脚集的引脚中。

该引脚集后面的数据结构是DAG，非常类似于代表您添加到IPFS的文件和文件夹的结构。根CID的的DAG存储在数据存储和所有补块DAG存储在blockstore。

该引脚集由许多树形结构的存储桶组成，每个存储桶最多包含8,192个项目，每个图层最多包含256个存储桶。第一个存储桶装满后，引脚将在存储桶之间分配。

运行垃圾回收时，将遍历DAG中的所有节点，并免除与其CID对应的块。

在添加和移除销时，此DAG会增长和收缩。随着结构的更改，将重新计算DAG中的中间节点的CID。随着DAG的变大，这可能变得昂贵，并且会损害非常大的Pinets的应用程序性能。

js-ipfs@0.50.0已更改了默认的引脚存储，以使用数据存储区而不是DAG，并且随着回购中固定块的数量增加，速度也相应提高：

在上图中，您可以看到随着固定项目数量的增加，添加下一个引脚所需的时间也增加了。在8,192个引脚处急剧增加，这是当第一个存储区被认为已满并且创建了多个存储区时，然后涉及更多的操作来添加下一个引脚。

js-ipfs@0.50.0采用的方法的性能与以前的版本相比非常优越，并且基本上仅受基础数据存储性能的限制，因为它已切换到简单的放置和获取操作，而没有创建数据的开销结构体。

Uint8Arrays

最初有数组。可以容纳各种混合类型的简单数组无法很好地优化，并且是对内存块的抽象。

然后Node.js出现并引入了Buffer-突然，JavaScript开发人员可以直接访问内存！这些东西持有的数字范围为0-255，并且速度非常快。JavaScript开始看起来像是一种可以用来进行资源密集型工作的语言。

ECMAScript标准的作者注意到并介绍了TypedArray，其中有很多变体，但我们最感兴趣的是Uint8Array。

这些类型的数组保存的数字的整数值范围为0-255，并支持与Node.js缓冲区非常相似的API，这并不奇怪，因为从Node.js v3.0.0开始，缓冲区一直是子类Uint8Arrays。

这是一段激动人心的时刻，因此随着JavaScript的功能增强和浏览器支持的发展，我们正在减少对核心Node.js库和实用程序的依赖。其中一部分是在我们的代码库中删除对Node.js缓冲区的所有使用。

使用js-ipfs@0.50.0时，您应该不再依赖从Core-API的任何部分返回的Node.js缓冲区，而应该针对Uint8Array接口进行编码。

我们依赖的某些模块仍将返回Buffer，我们将其传递以避免任何转换成本，但我们希望随着时间的推移删除或重构它们。为了保持向前兼容，您不应在这些返回值中的任何一个上使用Node.js Buffer方法。

例如，在下面的代码中，我们从字符串“ Hello”创建一个Buffer，将其添加到IPFS，然后立即对其进行分类并调用toString()这些块。这利用了我们添加的缓冲区已utf8编码的事实。Buffer.toString()采用utf8默认情况下的编码参数，因此以下代码有效，但仅出于巧合：

相反，我们将使用TextEncoder和TextDecoder类。这些在其使用的编码/解码中也是显式的(也是utf8默认情况)，因此使用起来更安全：

新功能

● 将引脚存储在数据存储中而不是DAG(＃2771)(64b7fe4)

● 将协议列表添加到ipfs id输出(＃3250)(1b6cf60)

● IPNS在浏览器示例(＃3207)中发布(91faec6)

● 将hapi更新到v20(＃3245)(1aeef89)

● 更新到libp2p@0.29.0(63d4d35)

重大变化

节点缓冲区已被Uint8Arrays(＃3220)取代

API变更

核心API和HTTP API客户端

● 现在的返回值ipfs.id包括节点可理解的协议列表

● 重大更改 previously Buffer以前返回Node.js 对象Uint8Arrays的位置，现在位于它们的位置。这会影响：

○ ipfs.block.*现在.data，块对象的属性为Uint8Array

○ ipfs.dag.get 根据返回的节点类型：

○ ipld-raw节点现在返回为Uint8Arrays

○ 现在.data，返回ipld-dag-pb节点的属性为Uint8Array

○ ipfs.dht.get 返回一个 Uint8Array

○ ipfs.cat文件数据现在以Uint8Arrays 返回

○ ipfs.files.read文件数据现在以Uint8Arrays 返回

○ ipfs.object.data 对象数据现在作为 Uint8Array

○ ipfs.pubsub.subscript 发布到主题的数据现在作为 Uint8Array

有关更多阅读，请参阅Core API Docs。

接下来是什么？

查看js-IPFS 项目路线图，其中包含标题功能，这些标题功能按我们希望它们登陆的顺序进行了组织。

路线图中只标注了较大的功能，期望在路线图项目之间发布许多小的错误修正！