퀴즈: stdio 서버

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. stdio 서버가 응답을 `sys.stdout.write()` 로 쓴 뒤 `flush()` 를 빠뜨리면 흔히 나타나는 증상은?

   1. 응답이 두 번 전송되어 클라이언트가 중복 id 오류를 낸다
   2. 응답이 버퍼에 갇혀 클라이언트가 답을 받지 못하고 기다린다
   3. stdout 이 자동으로 stderr 로 합쳐져 로그와 섞인다
   4. 줄바꿈이 사라져 두 응답이 한 줄로 붙는다

2. 메시지가 알림인지 판단할 때 `msg.get("id") is None` 대신 `"id" in msg` 를 권하는 이유는?

   1. `in` 이 `get` 보다 빨라서 초당 수천 건 처리에 유리하다
   2. `get` 은 딕셔너리가 아닌 메시지에서 예외를 던진다
   3. id 가 실제로 null 인 잘못된 요청과 id 가 없는 알림을 구분해야 한다
   4. JSON-RPC 는 알림에도 id 를 넣되 값을 null 로 하라고 정하기 때문이다

3. `json.loads` 가 실패한 줄에 대해 서버가 보내야 하는 응답은?

   1. `id: null`, `error.code: -32700` (Parse error)
   2. `id: 0`, `error.code: -32600` (Invalid Request)
   3. 응답 없이 그 줄을 버리고 다음 줄로 넘어간다
   4. `id: null`, `error.code: -32601` (Method not found)

4. `tools/call` 에 `count_orders` 를 `{"status": "banana"}` 로 불렀다. 서버의 올바른 답은?

   1. `error.code: -32601` — 그런 메서드는 없다
   2. `error.code: -32602` — 인자가 잘못됐으니 프로토콜 오류다
   3. `result.content` 에 빈 문자열을 넣고 `isError` 는 생략한다
   4. `result.isError: true` 와 '가능한 상태값' 을 설명하는 텍스트

5. 클라이언트가 `notifications/initialized` 를 보낸 직후 `readline()` 을 부르면?

   1. 서버의 확인 응답을 받아 세션이 정상 시작된다
   2. 답이 오지 않는 알림이라 클라이언트가 멈춘다
   3. 서버가 EOF 를 받아 종료된다
   4. 다음 요청의 응답이 앞당겨 도착한다

6. stdio 서버를 끝내는 순서로 라이프사이클 스펙이 클라이언트에 권하는(SHOULD) 것은?

   1. `shutdown` 요청을 보내고 `exit` 알림을 보낸다
   2. SIGKILL 을 보내 즉시 끝낸 뒤 파이프를 닫는다
   3. 먼저 stdin 을 닫고, 서버가 끝나길 기다리고, 안 끝나면 SIGTERM, 그래도 안 되면 SIGKILL
   4. stdout 을 먼저 닫아 서버가 더 쓰지 못하게 한 뒤 stdin 을 닫는다