웹 서버를 통해 클라이언트에 비동기 메시지를 보내는 토네이도를 사용하여 작성된 서버가 있습니다. 이 경우 Mac에서 Chrome에서 실행되는 자바 스크립트 앱입니다. 클라이언트가 강제로 연결이 끊어지면이 경우 클라이언트를 잠자기 상태로 둠으로써 서버는 여전히 클라이언트에 메시지를 보내는 것으로 생각합니다. 또한 클라이언트가 절전 모드에서 깨어날 때 메시지는 한꺼번에 전달됩니다.클라이언트 연결이 끊어지면 웹 소켓 메시지가 대기열에 추가됩니다.
이러한 메시지가 대기/버퍼 처리되는 메커니즘은 무엇입니까? 책임자는 누구입니까? 왜 그들은 여전히 배달됩니까? 누가 소켓을 다시 연결합니까? 내 직관은 웹 소켓이 HTTP와 같은 요청/응답이 아니더라도 TCP를 기반으로하므로 ACK 패킷이 필요하다는 것입니다. 모바일 시대의 일시적인 하락에 대해 프로토콜을보다 강력하게 만들기 위해이 작업이 의도적으로 수행되고 있습니까?
브라우저는 잠자기로 차단되지 않은 별도의 스레드에서 websocket 클라이언트 메시지를 처리 할 수 있습니다.
사용자 정의 응용 프로그램의 스레드가 활성 상태가 아니더라도 sleep (100)과 같이 강제로 잠자기하면이 경우 TCP 연결이 닫히지 않습니다. 소켓 핸들은 여전히 OS 커널에 의해 관리되며 TCP 클라이언트는 TCP 클라이언트의 수신 창 오버 플로우에 도달 할 때까지 계속 메시지를 보냅니다. 그리고이 후에도 서버 쪽 응용 프로그램은 새 메시지를 성공적으로 제출할 수 있습니다.이 메시지는 TCP 송신 버퍼가 오버플로 될 때까지 서버 측의 TCP 수준에서 버퍼링됩니다. 보내는 버퍼가 가득 차면 응용 프로그램은 "더 이상의 공간 없음"과 같은 요청 보내기에서 오류 코드를 가져와야합니다. 나는 나 자신을 시도하지 않았지만, 이런 식으로 행동해야한다.
클라이언트를 닫으려고하면 (프로세스를 종료하십시오) 완전히 다른 그림을 볼 수 있습니다 - 서버 연결이 끊어집니다.
연결이 끊어 지거나 오버플로되는 경우에도 매우 안정적인 시나리오를 위해 서버 쪽에서 처리하기가 어렵습니다. 연결 해제 케이스는 오버 플로우 경우로 변환 될 수 있습니다 (클라이언트가 다시 연결되는 동안 websocket 서버는 사용자 공간의 일부 한계까지 메시지를 버퍼링 할 수 있음). 그러나 송신 버퍼 한계의 오버 플로우를 안정적으로 처리하는 쉬운 방법은 없습니다. 하나의 솔루션 만 보입니다. 오버플로로 인해 버려진 메시지를 제기 한 이벤트의 작성자에게 오버플로 오류를 전파합니다.
흥미 롭습니다. 애플리케이션 잠자기로 인해 클라이언트에서 메시지를 처리하지 않는다면 그럴 가능성이 있습니다. 그러나 전체 클라이언트 컴퓨터가 절전 모드입니다. 내가 아는 한 네트워크 어댑터의 전원이 꺼지고 패킷을받을 때 ACK가 전송되지 않습니다. –
오오 .. 이것은 다른 종류의 수면입니다.이 경우 wireshark 또는 유사한 도구를 사용하여 패킷의 시퀀스를 추적하여 그림을 이해할 수 있습니다. – Andrew