Skip to main content
전달은 최대 한 번입니다 — 재생되지 않습니다. 연결이 끊긴 동안 확인된 내용은 다시 전송되지 않으므로, 프로덕션 클라이언트는 간극을 감지하고 백필할지 결정해야 합니다. 그 신호는 context.slot입니다: 이는 연결이 끊기면서 놓친 창을 제한합니다. 이 가이드는 연결이 왜 닫히는지, 어떻게 깨끗하게 재연결하는지, 그리고 이를 사용하는 방법을 다룹니다.

연결이 닫히는 이유

모든 닫힘에는 무슨 일이 일어났는지와 다음에 무엇을 해야 하는지 알려주는 WebSocket 닫힘 코드가 있습니다: 서버는 15초마다 핑을 보내므로, 건강한 조용한 연결도 여전히 트래픽을 처리합니다. 1분 넘게 아무런 알림이나 핑이 보이지 않으면, 소켓에서 알려주기를 기다리는 대신 연결이 죽었다고 가정하고 재연결하십시오.

연결 유지하기

필터가 충분히 좁아서 10분 동안 매치가 없을 수 있다면, 그보다 짧은 간격으로 명시적으로 JSON-RPC ping를 보내십시오:
현재 슬롯을 반환하며, 더 중요한 것은 유휴 타이머에 대한 클라이언트 메시지로 계산됩니다. 라이브러리 수준의 WebSocket 핑 프레임은 그렇지 않습니다.

재연결 및 간극 감지

1

지연시간을 두고 재연결

어떤 닫힘에서도 — 예상치 못했든 간에 — 지수 백오프로 재연결합니다. 구독 ID는 재연결 후에도 남지 않으므로 열려 있던 모든 필터에 대해 parsedTransactionSubscribe를 다시 보냅니다.
2

연결 끊김 간 context.slot 추적

연결 끊김 전에 본 마지막 context.slot를 유지합니다. 재연결 후 보이는 첫 슬롯과 그 슬롯 사이의 간극이 바로 놓친 창입니다 — 그 이상도 그 이하도 아닙니다.
3

필요 시 백필

애플리케이션이 간극을 용납할 수 없다면, RPC에서 그 슬롯 창을 백필하십시오: 범위 내 트랜잭션을 열거하려면 getSignaturesForAddress를 사용하고, 각각의 트랜잭션을 가져오려면 getTransaction를 사용합니다. 이는 수동 조정 단계이며, 파싱된 스트림 자체는 재생하지 않습니다.
context.slot는 재연결 후에도 남습니다: 연결 끊김 전 완전히 처리한 가장 높은 슬롯을 추적하고, 그 이후의 모든 것을 백필 창으로 취급합니다.

JSON-RPC 오류 처리

실패한 요청은 결과 대신 JSON-RPC 오류를 반환하므로, error.code에 따라 분기할 수 있습니다: -32602-32000는 요청 자체가 잘못되었음을 의미합니다 — 필터를 수정하고 그대로 다시 시도하지 마십시오. -32001-32002는 일시적입니다; 재연결에 사용하는 같은 지연 시간을 두고 다시 시도하십시오.

다음 단계

빠른 시작

전체 프로토콜 참조: 메서드, 필터 필드, 제한.

Jupiter 스왑 추적

이 연결이 구독할 수 있는 필터를 구축합니다.