[{"data":1,"prerenderedAt":9},["ShallowReactive",2],{"api-documentation:websocket\u002Frecovery":3},{"title":4,"slug":5,"group":6,"version":7,"html":8},"WS 복구","websocket\u002Frecovery","WebSocket API","0.4.0","\u003Ch1 id=\"재연결과-상태-복구\">재연결과 상태 복구\u003C\u002Fh1>\n\u003Cp>외부 WS는 연결별 sequence를 제공합니다. 과거 이벤트를 다시 받는 영구 replay cursor는 제공하지 않습니다. 재연결은 이전 연결의 연장이 아니라 새로운 상태 동기화입니다.\u003C\u002Fp>\n\u003Ch2 id=\"공개-스트림\">공개 스트림\u003C\u002Fh2>\n\u003Col>\n\u003Cli>연결 종료 또는 데이터 sequence 누락을 감지합니다.\u003C\u002Fli>\n\u003Cli>지수 백오프와 jitter를 적용해 새로 연결합니다.\u003C\u002Fli>\n\u003Cli>사용 중이던 ticker 구독을 다시 보냅니다.\u003C\u002Fli>\n\u003Cli>구독 확인 후 도착하는 현재 ticker부터 상태를 새로 구성합니다.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>구독 확인에는 sequence가 없고, 데이터 sequence는 새 연결에서 1부터 시작합니다.\u003C\u002Fp>\n\u003Ch2 id=\"개인-스트림\">개인 스트림\u003C\u002Fh2>\n\u003Col>\n\u003Cli>아직 결과를 받지 못한 생성·취소 명령을 \u003Cstrong>결과 불명\u003C\u002Fstrong> 상태로 기록합니다.\u003C\u002Fli>\n\u003Cli>새로운 timestamp와 HMAC 서명으로 개인 스트림에 다시 연결합니다.\u003C\u002Fli>\n\u003Cli>첫 프레임이 \u003Ccode>snapshot\u003C\u002Fcode>, \u003Ccode>sequence: 0\u003C\u002Fcode>인지 확인합니다.\u003C\u002Fli>\n\u003Cli>snapshot으로 주문·잔고 상태를 구성하고, 이후 모든 sequence를 연속 처리합니다.\u003C\u002Fli>\n\u003Cli>끊긴 시각을 포함하도록 REST \u003Ccode>\u002Fv1\u002Ffills\u003C\u002Fcode>를 조회해 누락 체결을 대조합니다. 실시간 \u003Ccode>executionId\u003C\u002Fcode>와 REST \u003Ccode>fillId\u003C\u002Fcode>가 다르므로 두 값을 같은 ID로 조인하지 마세요.\u003C\u002Fli>\n\u003Cli>결과 불명 주문은 미체결·주문 이력·체결 이력으로 확인한 후 후속 행동을 결정합니다.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>복구 중 발생하는 새 이벤트도 계속 수신·반영해야 합니다. REST 조회가 반환됐다는 이유로 더 최신 WS 상태를 오래된 값으로 덮어쓰지 마세요. snapshot의 \u003Ccode>ordersHasMore\u003C\u002Fcode>가 true이면 잘린 주문 집합을 전체 상태로 간주하지 않습니다.\u003C\u002Fp>\n\u003Ch2 id=\"재접속해도-해결되지-않는-오류\">재접속해도 해결되지 않는 오류\u003C\u002Fh2>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>상황\u003C\u002Fth>\n\u003Cth>다음 행동\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>INVALID_API_KEY, NO_PERMISSION, close 1008\u003C\u002Ftd>\n\u003Ctd>키·권한 확인 후 필요하면 재발급\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>INVALID_SIGNATURE\u003C\u002Ftd>\n\u003Ctd>서명할 경로·쿼리·본문 바이트 확인\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>TIMESTAMP_OUT_OF_RANGE\u003C\u002Ftd>\n\u003Ctd>호스트 시간 동기화와 receive window 확인\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>업그레이드 HTTP 404\u003C\u002Ftd>\n\u003Ctd>외부 호스트 \u003Ccode>api-ws.btxpro.co.kr\u003C\u002Fcode>와 스트림 경로 확인\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>close 1013 \u002F EVENT_BUFFER_OVERFLOW\u003C\u002Ftd>\n\u003Ctd>수신 처리 속도 개선 후 새 snapshot 구성\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>명령 ENGINE_TIMEOUT\u003C\u002Ftd>\n\u003Ctd>주문 결과 대조. 동일 명령 자동 재전송 금지\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>인증 오류를 무한 재접속으로 처리하지 마세요. HTTP 업그레이드와 WS 명령 모두 IP 기준 예산을 소비합니다.\u003C\u002Fp>\n\u003Ch2 id=\"go-sdk의-차이\">Go SDK의 차이\u003C\u002Fh2>\n\u003Cp>\u003Ccode>StreamTickers\u003C\u002Fcode>·\u003Ccode>StreamUser\u003C\u002Fcode>의 \u003Ccode>Reconnect: true\u003C\u002Fcode>는 연결·sequence 오류에 백오프 재연결을 수행합니다. 개인 스트림은 새 snapshot을 받습니다. 인증·콜백 오류는 종료됩니다.\u003C\u002Fp>\n\u003Cp>양방향 \u003Ccode>OpenUserStream\u003C\u002Fcode> 세션은 자동으로 재연결하거나 주문 명령을 다시 보내지 않습니다. 호출자가 새 세션을 열고 상태를 대조해야 합니다.\u003C\u002Fp>\n",1793249660045]