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

연결이 닫히는 이유

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

제한적인 필터와 유휴 시간 초과

필터가 충분히 제한적이어서 일치 항목 없이 10분이 지나도 정상일 수 있다면 서버가 코드 1000으로 연결을 종료할 수 있습니다. 다른 연결 종료와 동일하게 처리하세요. 다시 연결하고 구독을 재개한 후 아래 설명에 따라 누락 구간을 백필하세요.

다시 연결하고 누락 구간 감지하기

1

Reconnect with Backoff

예상 여부와 관계없이 연결이 종료되면 지수 백오프를 적용해 다시 연결하세요. 구독 ID는 재연결 후 유지되지 않으므로 열어 두었던 모든 필터에 대해 parsedTransactionSubscribe을 다시 보내세요.
2

Track context.slot Across Disconnects

연결이 끊기기 전에 마지막으로 확인한 context.slot을 보관하세요. 해당 슬롯과 재연결 후 처음 확인한 슬롯 사이의 구간이 정확히 누락된 범위입니다. 그 이상도 이하도 아닙니다.
3

Backfill if You Need To

애플리케이션에서 누락 구간을 허용할 수 없다면 RPC를 사용하여 해당 슬롯 구간을 백필하세요. getSignaturesForAddress으로 범위 내 트랜잭션을 열거한 다음 getTransaction으로 각 트랜잭션을 가져오세요. 이는 수동 조정 단계이며 Parsed Streams 자체에서는 재생하지 않습니다.
재연결 후에도 활용할 수 있는 것은 context.slot입니다. 연결이 끊기기 전에 완전히 처리한 가장 높은 슬롯을 추적하고 그 이후의 모든 항목을 백필 구간으로 간주하세요.

JSON-RPC 오류 처리하기

실패한 요청은 결과 대신 JSON-RPC 오류를 반환하므로 error.code에 따라 분기할 수 있습니다. -32602과 -32000은 요청 자체가 잘못되었다는 의미입니다. 필터를 수정하고 그대로 재시도하지 마세요. -32001과 -32002은 일시적인 오류입니다. 재연결에 사용하는 것과 동일한 백오프를 적용해 재시도하세요.

다음 단계

Quickstart

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

Track Jupiter Swaps

이 연결에서 구독할 수 있는 필터를 구축하세요.