Retry 로직

[dodo849]

⚠️ 문제 1. Retrier 동작 순서

• 현재 동작: CONNECT -> if ERROR -> connect close -> Retrier 실행 -> 이미 socket level에서 close 되어 전송 불가능.
• 해결방안: ERROR 프레임 받을 시 자동으로 disconnect 되기때문에 connect 시도부터 다시해야한다.

⚠️ 문제 2. Retrier 실행 횟수

상황

• 현재 동작: Retry시 1번 재시도하고 그래도 에러 발생시 error 리턴.
• Alamofire 동작: Retry시 해당 retry가 성공할때까지 무한 재시도.

Alamofire동작 방식으로 바꿀 시 문제점

• 소켓 에러 발생시 정확한 에러 원인별로 분기가 어려움.

• 해결방안 1. Stomp ERROR frame일때만 retry를 시도한다. 웹소켓 에러는 Log로 표시한다.

  • 단, 문제 1동작이 선행적으로 해결되어야함.

• 단점: 서버에 에러명세가 명확하지 않을 경우 무한 호출 가능성 -> 단, Alamofire도 이렇게 동작함.

[dodo849]

✅ 문제 1 부분 해결

• WebSocket client 단에서 소켓 연결이 종료된 후 연결 재시도 시 URLSessionWebSocketTask를 재생성하도록 변경.
• 단, CONNECT 프레임은 보내지 않은 상태이기 때문에 SEND 시도 전 CONNECT 프레임 전송

WebSocketClient	StompClient	StompProvider
socket connect에 대해 보장	Stomp CONNECT frame에 대해 보장	엔드포인트 연결

• receipt에 따른 재시도 로직

프레임	CONNECT	DISCONNECT	SUBSCRIBE, SEND, etc
동작	Error frame + 소켓 연결 없으면 재시도 > 이후 Subscription 복구	재시도 X 단순 소켓 종료 및 컴플리션 초기화	Error frame + receipt-id 확인 후 일치하는 요청에 대해서만 재시도 > 이후 Subscription 복구
비고	receipt-id가 없는 Error frame은 Connect 재시도로 동작함

✅ 문제 2 해결

• 소켓 에러는 log로 출력하고 서버의 error frame에 대해서만 동작하도록 변경.
• RetryType에 횟수를 지정할 수 있도록 설정. > 여러번 재시도가 가능하면서 무한호출 되지 않도록 구현

  public enum InterceptorRetryType {
  case retry(count: Int = 1, delay: TimeInterval = 0.0)
  case doNotRetry
  case doNotRetryWithError(Error)
  }

[dodo849]

전체 흐름