Skip to main content
传递是最多一次 — 没有重播。在断开连接时已确认的内容不会重新发送,因此生产客户端需要检测缺口并决定是否进行补填。其信号是 context.slot:它界定了断开连接时错过的窗口。本指南涵盖了连接为何关闭、如何干净地重新连接以及如何使用它。

为什么连接会关闭

每次关闭都有一个 WebSocket 关闭代码,告诉您发生了什么以及接下来该怎么做: 服务器每15秒发送一次 ping,因此健康但安静的连接仍然会有流量。如果超过一分钟完全没有看到任何东西——没有通知,没有 ping——假定连接已断开,并重新连接,而不是等待套接字告诉您。

保持连接活跃

如果你的过滤器足够窄,可以合法地在10分钟内没有匹配,则在比这个时间间隔更短的时间内发送一个明确的 JSON-RPC ping
它返回当前的 slot,更重要的是,它算作闲置计时器的客户端消息。库级别的 WebSocket ping 帧则不算。

重新连接并检测间隙

1

带退避的重新连接

无论任何关闭——预期的或非预期的——都使用指数退避重新连接。订阅 ID 无法在重新连接中保留,因此请为您打开的每个过滤器重新发送 parsedTransactionSubscribe
2

跟踪跨断开的 context.slot

保留您在断开连接前看到的最后一个 context.slot。在该插槽与重新连接后看到的第一个插槽之间的差距正是您错过的窗口——不多不少。
3

如果需要,请进行补填

如果您的应用程序无法容忍此差距,请从 RPC 填补该插槽窗口:使用 getSignaturesForAddress 枚举范围内的交易,然后使用 getTransaction 获取每个交易。这是一个手动对帐步骤——Parsed Streams 本身不进行重播。
context.slot 是重新连接后仍然存在的内容:跟踪断开连接前您已完全处理的最高插槽,并将其后的所有内容视作补填窗口。

处理 JSON-RPC 错误

失败的请求会返回 JSON-RPC 错误而不是结果,因此你可以基于 error.code 进行分支: -32602-32000 意味着请求本身有误—修复过滤器,不要重试相同请求。-32001-32002 是暂时的;使用与重连接相同的退避重试。

下一步

快速开始

完整协议参考:方法、过滤器字段、限制。

跟踪Jupiter互换

构建此连接可以订阅的过滤器。