存储网络通信【免费下载链接】js-ipfsIPFS implementation in JavaScript项目地址https://gitcode.com/gh_mirrors/js/js-ipfs点击查看免费下载导读ipfs-message-port-client是 js-IPFS 生态中一套基于 WebMessageChannel/MessagePort的 IPFS 客户端库其核心价值在于把运行在SharedWorker中的 IPFS 节点能力通过消息通道暴露给多个浏览上下文标签页、iframe实现单节点、多消费端的共享架构。本文以该库的 README 为主线结合仓库源码packages/ipfs-message-port-client及其配套的ipfs-message-port-server、ipfs-message-port-protocol深入讲解安装方式、API 子集、两种客户端实例化模式from与detached、transfer传输优化机制及底层 RPC 原理帮助你掌握在浏览器多上下文场景下接入 IPFS 的完整实战方案。一、库的定位与安装1.1 它解决什么问题浏览器默认的隔离模型决定了每个标签页、iframe 各自拥有独立的 JS 运行时与内存空间。如果每个上下文各自初始化一个 IPFS 节点会造成 CPU、内存与网络资源的重复消耗。ipfs-message-port-client的解法是在SharedWorker中只运行一个 IPFS 节点由ipfs-message-port-server提供各个浏览上下文通过MessagePort与该节点通信从而复用同一个节点的区块存储、Bitswap 网络与 DHT 等能力。从仓库代码可以看到客户端的整体架构由三层包协作完成ipfs-message-port-client本文主角面向最终用户的客户端 APIipfs-message-port-server在SharedWorker中承载真实 IPFS 节点的服务端ipfs-message-port-protocol定义两端通信的消息协议CID、DAG 节点、错误对象的编解码。1.2 安装$ npm i ipfs-message-port-client该包通过 npm 独立分发安装后即可在浏览器环境中直接import。二、提供的 API 子集客户端并不暴露 js-IPFS 的全部接口而是聚焦于一组跨上下文共享最常用、且便于消息化编码的能力子集命名空间方法对应 js-IPFS 核心 APIipfs.dagput/get/resolveDAG APIipfs.blockput/get/rm/statBLOCK APIipfs.add单文件导入FILES API 之ipfs.add(data, options)ipfs.addAll批量/流式导入FILES API 之ipfs.addAll(source, options)ipfs.cat读取内容寻址数据FILES API 之ipfs.cat(ipfsPath, options)ipfs.files.stat路径/文件状态查询FILES API 之ipfs.files.stat(path, options)这个子集的划分与源码结构完全对应。在 IPFSClient 主类 的构造函数中客户端被组装为四个可独立使用的子客户端export class IPFSClient extends CoreClient { constructor (transport) { super(transport) this.transport transport this.dag new DAGClient(this.transport) // dag 命名空间 this.files new FilesClient(this.transport) // files 命名空间 this.block new BlockClient(this.transport) // block 命名空间 } }而 CoreClient 继承自基类Client注册了core命名空间下的add、addAll、cat、ls四个方法super(core, [add, addAll, cat, ls], transport)同理BlockClient 注册block命名空间的put/get/rm/statDAGClient 注册dag命名空间的put/get/resolveFilesClient 注册files命名空间的stat。需要留意这里的ipfs.files.stat与根级ipfs.stat不同后者不属于该子集同时根级ipfs.ls在客户端中已实现core命名空间但 README 未将其列入对外承诺的 API 子集。三、两种客户端实例化模式3.1 模式一IPFSClient.from(port)—— 直接绑定端口客户端可以从一个现成的MessagePort实例直接实例化。最常见的场景是ipfs-message-port-server被单独打成 bundle加载进SharedWorker主线程通过worker.port拿到通信端口。import { IPFSClient } from ipfs-message-port-client // 指向包含 ipfs-message-port-server 的脚本 URL const IPFS_SERVER_URL /bundle/ipfs-worker.js const main async () { const worker new SharedWorker(IPFS_SERVER_URL) const ipfs IPFSClient.from(worker.port) const data ipfs.cat(/ipfs/QmdfTbBqBPQ7VNxZEYEj14VmRuZBkqFbiwReogJgS1zR1n) for await (const chunk of data) { console.log(chunk) } }cat返回的是异步迭代器AsyncIterable因此必须用for await逐块消费。这也说明cat等流式接口在消息通道上同样以流的形态返回而非一次性整块加载。从源码看from静态方法 只是将端口包装进MessageTransportstatic from (port) { return new IPFSClient(new MessageTransport(port)) }3.2 模式二IPFSClient.detached()—— 延迟挂载的分离客户端有些场景下端口并非在初始化时就能拿到——例如端口是另一个 JS 上下文如 iframe通过window.postMessage的ports参数异步送来的。此时可以先创建分离客户端之后再挂载import { IPFSClient } from ipfs-message-port-client const ipfs IPFSClient.detached() const main async () { const data ipfs.cat(/ipfs/QmdfTbBqBPQ7VNxZEYEj14VmRuZBkqFbiwReogJgS1zR1n) for await (const chunk of data) { console.log(chunk) } } window.onload main window.onmessage ({ports}) { IPFSClient.attach(ports[0]) }关键行为分离客户端会把所有 API 调用排队queue只有在通过attach挂载到端口后才会真正执行——除非这些调用在此之前超时或被 abort 中止。这一行为在传输层有完整实现。MessageTransport构造时若未传端口则this.port null见 transport.js 构造器execute会把查询写入this.queries字典仅当this.port存在时才真正postQuery发出而connect被调用时会遍历所有 pending 查询一次性 flushconnect (port) { if (this.port) { throw new Error(Transport is already open) } else { this.port port this.port.addEventListener(message, this) this.port.start() // 遍历并补发所有在连接前入队的查询 for (const [id, query] of Object.entries(this.queries)) { MessageTransport.postQuery(port, id, query) } } }注意两点重复attach会抛出Error(Transport is already open)disconnect()会让所有 pending 查询以DisconnectError失败并关闭端口且不可重连源码刻意保留this.port引用以阻止重连。四、性能优化transfer与结构化克隆4.1 问题背景结构化克隆的开销由于客户端与服务端之间所有数据都要经过MessagePort任何postMessage传输的数据都会被 结构化克隆算法复制一份。对于Uint8Array这类大数据块复制会造成明显的内存与时间开销成为跨上下文共享节点的性能瓶颈。4.2transfer选项转移而非复制为规避不必要的复制所有 API 选项都被扩展了一个可选的transfer属性允许你显式提供 Transferable 列表。这些对象会被**转移move**到对端而不是复制。/** * param {Uint8Array} data - 大数据块 */ const example async (data) { // 传入 data.buffer 会把底层 ArrayBuffer 转移走data 在本地上下文被清空 ipfs.add(data, { transfer: [data.buffer] }) }⚠️ 注意转移会清空发送方的数据。如果之后还要继续使用该数据就会出错。因此transfer选项设计为让用户在确认安全放弃引用时显式让出——这是一种显式所有权移交而非隐式行为。这一机制在源码中贯穿始终传输层Query类持有transfer()方法返回input.transferpostQuery将其作为postMessage的第二个参数传入实现真正的转移语义各 API 实现中add/addAll会把用户传入的transfer收集进一个Set并在编码输入如encodeCID(cid, transfer)时持续追加需要转移的缓冲区见 core.js 的 add/addAllblock.js 的 get/rm/stat 同样将options.transfer传递给encodeCID确保 CID 编码过程中涉及的字节缓冲区可被转移。4.3 更推荐的做法直接传Blob/File虽然transfer能优化二进制数据的传递但 README 更推荐优先使用 Web 原生Blob/File实例——大多数 Web API 天然以它们作为输入并且这些类型在结构化克隆时可以不复制底层内存地跨上下文传递const example async (url) { const request await fetch(url) const blob await request.blob() ipfs.add(blob) }结合 core.js 的输入编码逻辑 可以看到encodeAddInput对Blob、string、ArrayBuffer、ArrayBufferView均采用原样直传的最优策略只有面对异步可迭代对象、ReadableStream或FileObject时才会走encodeIterable/encodeFileObject的逐步编码路径。五、底层通信原理一次 API 调用的完整链路理解 RPC 链路能帮你更好地排查问题与评估性能边界。一次ipfs.add(...)调用的完整旅程如下方法包装Service基类client/service.js根据注册的命名空间与方法名列表为每个方法生成input transport.execute(new Query(namespace, method, input))的调用包装。构造查询Query封装namespace、method、input并创建承载结果的Promise同时解析timeout默认Infinity与signal。执行与超时/中止MessageTransport.execute为查询生成全局唯一 IDMath.random().toString(32)前缀 自增序号确保多标签页共享同一 SharedWorker 时 ID 不冲突注册超时定时器与AbortSignal监听然后postMessage发出{ type: query, namespace, method, id, input }消息并附带transfer列表。服务端处理ipfs-message-port-server侧接收消息后按命名空间分派。从 IPFSService 可以看到服务端同样由dag/core/files/block四个命名空间服务组成与客户端一一对应。响应回流服务端返回{ id, result: { ok, value | error } }后客户端的handleEvent按id找到 pending 查询成功则query.succeed(value)失败则query.fail(decodeError(result.error))——错误对象同样经由协议层 error 编解码 还原。若查询已被中止/超时移除则响应会被静默丢弃。这一链路同时保证了超时setTimeout触发后查询以TimeoutError失败并向服务端补发{ type: abort, id }取消AbortSignal触发后查询以AbortError失败并同步通知服务端且清除定时器错误传递服务端异常通过协议层编码为可克隆结构跨上下文回传客户端解码后还原为错误对象。六、兼容性与已知边界从 interface 测试 可以看出该客户端通过interface-ipfs-core标准测试套件验证兼容性测试中显式声明了一批已知未实现/受浏览器限制的能力实际使用时应避免踩坑ipfs.object.get相关能力未实现导致only-hashtrue添加、URL 导入等测试被跳过process.hrtime在浏览器中不存在mtime as hrtime场景不支持以Uint8Array形式传 CID 不支持cat等接口需传 CID 对象或字符串路径从 HTTP URL 直接导入存在限制对应 js-IPFS 已知 issueaddAll、get、refs、refsLocal在接口测试中标记为 Not implementedDAG 节点不会转换成dag-pb的DAGNode实例以字符串形式传 CID 给dag.get等接口不受支持需传 CID 实例。这些边界恰好说明了消息通道客户端的取舍优先保证高频、数据流友好的能力add/cat/block/dag牺牲一部分低频或依赖本地对象形态的能力。七、总结与选型建议ipfs-message-port-client为浏览器多上下文场景提供了一条清晰的 IPFS 接入路径架构上单节点部署于SharedWorker多标签页/iframe 通过MessagePort共享避免资源重复API 上提供dag/block/add/addAll/cat/files.stat六个核心能力子集形态与 js-IPFS 标准 API 保持一致性能上以结构化克隆为默认传输方式以transfer显式转移为优化手段以Blob/File原生类型为推荐输入生命周期上from直接绑定、detachedattach延迟挂载两种模式覆盖了端口获取时机不同的两类场景。如果你的产品形态是浏览器内嵌 IPFS 多标签页共享内容并且能接受 README 与测试中列出的 API 边界如不支持ipfs.object、get、refs那么这套 message-port 方案就是为你的场景量身定制的。若需要更完整的 js-IPFS 能力则仍应回归 js-IPFS 主库 或参考 核心 API 文档 选取合适的接入方式。许可与贡献该包以 Apache-2.0 与 MIT 双许可方式发布详见 LICENSE-APACHE 与 LICENSE-MIT。欢迎通过仓库 issues 参与贡献所有交互均需遵守 IPFS 社区的贡献规范与行为准则。赞分享存储网络通信【免费下载链接】js-ipfsIPFS implementation in JavaScript项目地址https://gitcode.com/gh_mirrors/js/js-ipfs点击查看免费下载相关推荐js-ipfs ipfs-message-port-server 全解析用 MessagePort 在浏览器多 Tab 间共享 IPFS 节点的实现与版本演进js ipfs ipfs message port server 全解析用 MessagePort 在浏览器多 Tab 间共享 IPFS 节点的实现与版本演进存储网络通信ipfs-message-port-server 实战指南通过 MessageChannel 将 js-IPFS 节点暴露给多客户端ipfs message port server 实战指南通过 MessageChannel 将 js IPFS 节点暴露给多客户端 ipfs message存储网络通信js-IPFS 消息端口协议详解基于 ipfs-message-port-protocol 的跨线程 IPFS 编解码实战js IPFS 消息端口协议详解基于 ipfs message port protocol 的跨线程 IPFS 编解码实战 本篇技术指南围绕 packages存储网络通信上一篇如何彻底修复DWPose姿态估计器报错从根源到实战的完整解决方案下一篇终极指南如何快速解决ComfyUI ControlNet Aux中DWPose姿态估计器报错问题创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考