http://www.7klian.com

js-IPFS 0.48.0宣布 具有毗连性改造和较小的块存储

  利用js-IPFS 0.48.0,API要领的所有可选参数此刻都进入options工具。行为产生庞大变革的所有API均已分为更直观的呼吁。

  利用js-IPFS 0.48.0,ipfs.add此刻返回单个项目。这个看似无害的变动带来了很多可用性方面的改造,因为一个非经常见的问题是“我添加了一个文件,然后又返来了,那是什么?” 然后您必需拿出白板和笔,在不知不觉中,您已经作了很长的表明,而他们想要做的就是收回CID。

  default默认环境下启用署理节点

  带有可选参数的API

  JS IPFS 的完整DHT实施以及Go IPFS 0.5中举办的所有变动要到本年晚些时候才气宣布,可是临时您可以运行尝试性DHT实施。此实现尚不完整,因此某些成果大概无法按预期事情,可是您的节点大概会跟着时间的推移而低落机能,但您应该可以或许利用它来理会内容并查找对等工具。

  Go IPFS节点利用libp2p-autonat软件包来确定它们是否可以被外部网络上的对等方拨号 -假如可以,则它们将本身从DHT客户端进级到DHT处事器。JS IPFS正在支持Autonat ,但在它登岸之前,它将仅在客户端模式下运行,这是得到完全DHT支持的垫脚石。

  当您将诸如undefinedin的内容通报给可选的arg位置而且不通报options参数时,所有这些城市导致奇怪的行为和细微的错误,以及难以处理惩罚的,容易堕落的内部代码,,这些内部代码试图按照范例或范例揣摩您通报的内容范例沟通的工具的属性。

  

  亮点

  跟着版本的宣布js-IPFS 0.48.0,此刻所有块都针对从CID提取的base32编码的多哈希存储了。这意味着不再反复,也不再需要反复查找,但这是以需要从v7到v8举办回购迁移为价钱的,以确保所有块都存储在正确的密钥下。

  有多种要领可觉得欣赏器内IPFS节点提供更好的网络体验,个中一种是Delegate   Nodes。委托节点是一个网络对等体,代表网络上的其他节点执行某些操纵。在这种环境下,它将代表我们举办DHT查询,因此我们可以找到比以往更多的伙伴和更多的内容。

  js-IPFS 0.48.0 默认环境下在设置中启用委托节点,这意味着您应该看到比以前更多的对等节点,而且可以或许更快,更靠得住地找到内容。

  默认环境下,它利用民众委托节点为您提供最佳的即用型体验。这些节点是共享的民众点,但没有可用性担保,而且大概是资源争用的源头。假如要在出产情况中陈设JS IPFS,则应托管本身的委托节点并相应地设置JS IPFS。

  DHT对等方以客户端模式或处事器模式运行。DHT客户端可以举办查询以查找内容和其他对等方,但不会将本身宣传为内容的提供者或答复任何查询。您大概出于多种原因而处于客户端模式,但主要的原因是大大都DHT对等方都位于NAT防火墙之后,这意味着其他网络上的对等方无法通过ipfs.swarm.connect对其举办拨号。除非您知道您的节点将具有民众地点,不然应在客户端模式下运行它。

  block更小,更快的区块存储

  传统上,JS IPFS主要针对欣赏器,假如您想利用DHT,则欣赏器是一个糟糕的处所。凡是,您在页面上的时间不敷以举办或响应DHT查询,也无法拨号,因此纵然您可以或许宣传本身作为给定区块的提供者,也没有人可以与您成立接洽检索该块,导致每小我私家的处事质量下降。更糟糕的是,通过DHT查找更多伙伴和内容的方法使您陷入逆境。

  跟着时间的流逝,我们试图消除领略其他框架和开始利用IPFS的JavaScript语言独特方面的要求。我们删除了拉流,以使开拓人员可以专注于开拓情况的自然原语-譬喻,节点中的流以及欣赏器中的文件 / Blob。我们删除了将字符串转换为缓冲区的要求,使人们只需将字符串化的JSON作为文件添加到IPFS。

  跟着IPFS生态系统的成长,越来越多的开拓人员对该项目发生乐趣,并开始利用我们的API。跟着时间的流逝,个中很多有机增长,但并非所有人都有相等的时间投入个中。

  我们将整个API重构为从回调到Promises,然后从将Arrays返回到AsyncIterators,以答允在不利用外部库的环境下流式传输大量数据。

  在IPFS的早期,所有CID均为v0。这意味着它们只是一个简朴的多重哈希 -一个以一些前缀字节为前缀的字节数组,该字节数组汇报您其余代表的字节(sha2-256,blake2s-128等等)是哪种哈希,以及存在几多字节。所述multihash通过在散列数据建设块,然后将其存储在包括在内的块存储IPFS回购。

  ipfs.add()

  DHT设置

  块存储将CID转换为字节数组,并利用它们来生成块的密钥,这意味着大概会针对v0 CID和v1 CID存储同一块。由于块数据沟通,因此,回购还在每个通报的CID长举办两次查找-一次作为v0 CID,假如未找到该块,则再次作为v1 CID。

  厥后的v1 CID达到了,他们在字节数组中添加了版本号和编解码器,可是CID仍然包括multihash-一个块可以对应于多个CID,只要它们包括沟通的multihash即可。

  更直观的API

  js-IPFS 0.48.0 具有更好的默认毗连,更小的块存储和更直观的API的新闻

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。