Quiz: half-close and response preservation

클라이언트가 원고를 보낸 뒤 SHUT_WR만 호출했다. 서버가 EOF를 받은 다음 해야 할 일은?

• 서버 소켓을 즉시 닫아 두 방향의 자원을 함께 회수한다
• 읽기 관심을 끄고 준비한 답장의 송신을 계속 진행한다
• 읽기 관심을 유지해 EOF가 없어질 때까지 기다린다
• 새 연결을 받아 이전 소켓의 답장 큐를 그쪽으로 옮긴다

요청 상한을 정확히 채웠다. 다음 recv의 길이를 0으로 계산하면 무엇이 잘못되는가?

• 읽기 준비를 커널이 쓰기 준비로 바꿔 통지한다
• TCP가 자동으로 요청 상한을 한 바이트 늘린다
• 상대의 FIN 없이도 빈 반환값을 EOF로 오해한다
• 송신 큐의 내용이 수신 버퍼 뒤에 자동 연결된다

답장 4바이트 중 send가 2를 반환하고 다음 호출은 BlockingIOError다. 올바른 상태는?

• 남은 2바이트를 보관하고 WRITE 관심을 유지한다
• 4바이트 전부를 다시 넣어 응답 누락을 방지한다
• 남은 2바이트를 지우고 complete로 종료한다
• 수신 EOF를 해제하고 원고를 다시 수신한다

손님이 제한 시간 직전에 한 바이트씩 보낸다. 생성 시 고정한 총수명 마감의 효과는?

• 연결 수 제한이 없어도 전체 메모리 사용을 보장한다
• 유휴 시계만 갱신해 응답 완료까지 무기한 보장한다
• EOF 이전에만 적용되어 송신 대기는 계속 허용한다
• 활동이 있어도 정해진 시각에 해당 연결을 종료한다

종료 처리에서 finish가 소켓을 직접 닫지 않고 반복문에 회수를 맡기는 이유는?

• 선택기가 닫힌 소켓의 송신 버퍼를 대신 비워 주기 때문이다
• 종료 사유 표시와 등록 해제·close 순서를 분리하기 위해서다
• 소켓 close를 생략해 다음 요청에 같은 FD를 보존하기 위해서다
• EOF가 와도 READ 관심을 영구 유지하는 것이 필요하기 때문이다

서버의 complete 사유가 뜻하는 범위를 가장 정확히 설명한 것은?

• 클라이언트 업무 처리와 데이터 영구 저장까지 끝났다
• TCP 송신 경로 전체가 앞으로도 오류 없이 유지된다
• 로컬 출력 큐가 비었으며 상대의 처리 확인은 별개다
• 클라이언트가 서버의 마지막 FIN을 읽었다는 뜻이다