javascript - 与 IPFS 相比，JS-IPFS 的性能较低

Question

我正在使用 js-ipfs 服务器端在 IPFS 上“上传”文件，但它的效率似乎不如命令行 ipfs daemon 和 ipfs add someFile.

服务器端，我实例化了一个 Ipfs 对象，然后我尝试使用文件内容的路径和缓冲区来 storeData。当我的服务器启动时，我连接到三个群:

Swarm listening on /ip4/127.0.0.1/tcp/4003/ws/ipfs/QmTBoDWXviw7eRKeDGbp3wU2PxAw1epPxax6mp8uY6CEEW
Swarm listening on /ip4/127.0.0.1/tcp/4002/ipfs/QmTBoDWXviw7eRKeDGbp3wU2PxAw1epPxax6mp8uY6CEEW
Swarm listening on /ip4/10.19.77.89/tcp/4002/ipfs/QmTBoDWXviw7eRKeDGbp3wU2PxAw1epPxax6mp8uY6CEEW

我是这样使用 IPFS 的:

const IPFS = require('ipfs');
const node = new IPFS();

class Ipfs {

    constructor() {
        node.on('error', e => console.log(e))
        node.on('start', () => console.log('Node started !'))
        node.on('ready', () => console.log('Node is ready !'))
    }

    storeData(content, path) {
        return new Promise((resolve, fail) => {
            let encData = {
                path: path,
                content: content,
            };
            node.files.add(encData, (err, data) => {
                if (err) return fail(err);
                return resolve(data);
            })
        })
    }
}

当我从我的对象调用 storeData 时，IPFS 会返回一个哈希值让我可以获取我的文件，但是 https://ipfs.io/ipfs/[hash] 从不加载。

我想强调一个事实，即 ipfs add 命令行给出的哈希立即生效

提前致谢

Answer 1

在命令行中，当您运行 ipfs add <some file> 时它会将文件分块，并将其添加到本地 ~/.ipfs目录。在运行时，它会打印出 block 的 CID，最后是根 CID。

如果您尝试通过运行 ipfs cat <root CID> 从 IPFS 获取文件使用您刚从运行中获得的 CID ipfs add然后它也会很快，因为它会从您的本地存储库中提取 block 。如果你运行 ipfs cat使用您当前没有的 CID，然后它会向您连接的对等方询问。如果当前没有连接到为该 CID 提供数据的人，这可能需要一段时间。

在js-ipfs打电话node.files.add工作方式类似于运行 ipfs add从命令行。一旦完成文件分块并将它们存储在本地(默认情况下在 ~/.jsipfs 中)，它将返回根 CID。

尝试通过 https://ipfs.io/ipfs/[CID] 从公共(public)网关获取根 CID如果在 ipfs.io 操作的网关机器上运行的 IPFS 节点需要一段时间才能找到该 CID 的提供者，则可能会很慢。它是一台远程机器，它必须首先找到提供该 CID 的本地对等机，并从中获取数据。

当您使用 ipfs daemon 启动 ipfs 节点时，初始输出告诉您节点正在监听哪些本地网络接口(interface)和端口，因此

Swarm listening on /ip4/127.0.0.1/tcp/4003/ws/ipfs/QmTBoDWXviw7eRKeDGbp3wU2PxAw1epPxax6mp8uY6CEEW
Swarm listening on /ip4/127.0.0.1/tcp/4002/ipfs/QmTBoDWXviw7eRKeDGbp3wU2PxAw1epPxax6mp8uY6CEEW
Swarm listening on /ip4/10.19.77.89/tcp/4002/ipfs/QmTBoDWXviw7eRKeDGbp3wU2PxAw1epPxax6mp8uY6CEEW

...意味着您的本地 ipfs 节点正在监听 ipv4 地址 127.0.0.1和 10.19.77.89 .它不会告诉你有多少同龄人。要了解您有多少对等点，请运行 ipfs swarm peers

$ ipfs swarm peers
/ip4/1.64.206.172/tcp/42707/ipfs/QmUDGjCUDePrxWbpohHLuW8Hy1uGKXi4tJXaN6z7FuNszb
/ip4/100.24.159.221/tcp/46757/ipfs/QmQjGfZq3MvgykH5oXeQaZvU6TGMCD7xtRtUXz1sK4u8nG
/ip4/101.200.58.57/tcp/4001/ipfs/QmRXcRwhbjtgE2E3hF4rRhM3xaGRrjfieUE5iXGCAwrZ9d
...

...为了找到您所连接的对等点的数量，您可以将输出通过管道传输到 wc -l

$ ipfs swarm peers | wc -l
     755

...并回答您的基本问题 由于语言的差异，js-ipfs 仅比 go-ipfs 慢。它们都是同一规范的实现，并且它们都使用相似的算法实现。如果您想从 JS 使用 go-ipfs，出于任何原因，您也可以通过运行 go-ipfs 守护进程并使用 js-ipfs-http-client 通过 HTTP API 与其通信来实现。与 js-ipfs 具有相同 API 的库