クイズ：stdioサーバー

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

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

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

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

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

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

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

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

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

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

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

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