测验：运维连接诊断器：预算、原因与回收

소켓을 미리 가진 Dial 100개에 limit=8을 주었다. 정확한 자원 설명은?

• 진행 중 연결뿐 아니라 모든 FD가 정확히 8개 이하이다
• 대기 중 Dial은 소켓을 가져도 FD 한도를 소비하지 않는다
• 제어 채널과 selector는 운영체제 자원을 사용하지 않는다
• 진행 중 상한과 전체 열린 FD 수를 별도로 계산해야 한다

정리 반복문 첫 close에서 예외가 났다. 다른 FD를 보호하는 설계는?

• 각 회수를 계속 시도하고 오류를 보관해 나머지 정리 후 전파한다
• 즉시 반환해 남은 소켓이 다음 호출에서 닫히기를 기대한다
• 오류를 무시한 뒤 회수하지 않은 항목도 성공으로 반환한다
• FD 한도를 늘려 회수되지 않은 소켓의 영향을 미룬다

결과 집계에서 error=0을 error or '없음'으로 바꾸면 무엇을 잃는가?

• 오류 숫자의 정렬 순서만 바뀌고 의미는 그대로 보존된다
• 성공을 나타내는 유효한 0과 정보 누락의 구분을 잃는다
• 오류가 모두 음수가 되어 연결 재시도가 자동으로 시작된다
• 연결이 취소되어 제어 채널이 다시 열리는 결과가 된다

완료 처리 예산을 검증하려면 어떤 시험이 중요한가?

• 연결이 항상 시작하자마자 하나씩 완료하는 경우만 반복한다
• 소스에 budget이라는 변수 이름이 등장하는지만 확인한다
• 완료 이벤트를 모아 한꺼번에 돌려주고 턴별 처리 수를 센다
• 모든 연결을 없애고 빈 결과가 빨리 반환되는지만 잰다

가득 찬 socketpair로 마감과 취소를 시험했다. 올바른 결과 보고는?

• 공인 인터넷의 SYN 유실과 원격 방화벽 장애를 재현했다
• TCP 재전송 알고리즘의 모든 시간 초과 분기를 검증했다
• 외부 서버의 지연 분포와 서비스 용량 한도를 측정했다
• 연결 상태는 합성했고 커널 쓰기 대기와 깨우기를 실제 검증했다

한 번의 진단 결과에 pending이 섞여 있다. 최종 summarize는?

• 미완료 입력을 거절하고 종료 결과만으로 집계한다
• pending을 connected에 더해 분모와 분자를 맞춘다
• pending을 무조건 failed로 바꿔 실행 이력을 끝낸다
• pending을 조용히 버려 합계가 작아져도 반환한다