js-IPFS 0.50.0在共享的Webworkers中运行,并且固定速度更快

2020-09-15 15:59:44

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

   亮点

  在多个选项卡和固定文件之间共享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,并且随着回购中固定块的数量增加,速度也相应提高:


js-IPFS@0.50.0 大大提高了固定性能


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

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


   Uint8Arrays

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

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

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

  这些类型的数组保存的数字范围为0-255的整数,并且支持与Node.js Buffers非常相似的API,这并不奇怪,因为Node.js v3.0.0自此以来,Buffers是子类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默认情况下的编码参数,因此以下代码有效,但仅出于巧合:

  const { cid } = await ipfs.add(Buffer.from('Hello'))for await (const chunk of ipfs.cat(cid)) {

  console.info(chunk.toString()) // prints 'Hello'

  }

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

  const encoder = new TextEncoder()const decoder = new TextDecoder()const { cid } = await ipfs.add(encoder.encode('Hello'))for await (const chunk of ipfs.cat(cid)) {

  console.info(decoder.decode(chunk)) // prints 'Hello'

  }


   新功能

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

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

      •IPNS在浏览器示例(#3207)中发布(91faec6)

      •将hapi更新到v20(#3245)(1aeef89)

      •更新到libp2p@0.29.0(63d4d35)

  changes重大变化

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

  核心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


  ✨ 接下来是什么?

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

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


  ✨  想贡献吗?

  您想为IPFS项目做贡献,又不知道如何做吗?好吧,有几个地方可以开始使用:

      •检查js-IPFS存储库中help wanted标签的问题

      •加入IPFS众志成城,自我介绍,并让我们知道您想在哪里做出贡献:https://github.com/ipfs/team-mgmt/#weekly-ipfs-all-hands

      •用IPFS破解并向我们展示您的成就!All Hands呼叫也是演示的理想场所,请加入并向我们展示您的构建内容

      •通过https://discuss.ipfs.io/加入讨论,并帮助用户找到答案。

      •加入并参与其中!


   你有问题吗?

  最好的地方要问你关于IPFS的问题,它是如何工作的,以及你可以用它做的是在discuss.ipfs.io。我们也可以在#ipfsFreenode上的频道上找到。


最新推荐