クイズ: 4種類の呼び出しと失敗の仕方

rpc Chat (stream Msg) returns (stream Msg); 에서 gRPC 가 보장하는 것은?

• 클라이언트가 보낸 순서대로 서버가 응답을 하나씩 돌려준다
• 각 스트림 안의 메시지 순서는 지켜지지만 두 스트림 사이의 순서는 없다
• 서버는 클라이언트 메시지를 전부 받은 뒤에만 쓰기 시작할 수 있다
• 양쪽 스트림의 메시지 개수가 같아야 호출이 OK 로 끝난다

클라이언트가 INVALID_ARGUMENT 를 받았다. 확실히 말할 수 있는 것은?

• 네트워크가 끊겨 gRPC 라이브러리가 만든 코드다
• 서버가 내려가는 중이라 라이브러리가 대신 돌려준 것이다
• 잠시 뒤 같은 요청을 다시 보내면 성공할 가능성이 높다
• 라이브러리는 이 코드를 만들지 않으므로 서버 애플리케이션 코드가 돌려준 것이다

읽고-고치고-쓰기 순서에서 테스트-앤드-셋이 실패해 클라이언트가 처음부터 다시 해야 할 때 문서가 권하는 코드는?

• ABORTED — 상위 수준에서 재시도하라는 뜻
• UNAVAILABLE — 이 호출만 다시 하면 된다는 뜻
• FAILED_PRECONDITION — 상태를 고치기 전엔 재시도하지 말라는 뜻
• RESOURCE_EXHAUSTED — 동시성 한도에 걸렸다는 뜻

사용자 서버가 클라이언트에게 받은 데드라인을 과금 서버로 전파할 때 gRPC 가 시각 대신 타임아웃으로 바꿔 넘기는 이유는?

• HTTP/2 헤더에는 정수만 실을 수 있어서
• 두 서버의 시계가 어긋나도 남은 시간이 정확하도록
• 과금 서버가 데드라인을 다시 계산하지 않도록 하는 성능 최적화
• 타임아웃이 짧을수록 재시도 토큰을 아낄 수 있어서

채널에 재시도 정책을 전혀 적지 않았을 때 UNAVAILABLE 로 실패한 호출에 일어나는 일은?

• 기본 정책대로 최대 4 번까지 지수 백오프로 재시도한다
• 서버가 처리했을 가능성이 있으면 재시도하지 않고, 투명 재시도만 제한적으로 한다
• 재시도가 기본으로 꺼져 있어 어떤 경우에도 다시 보내지 않는다
• UNAVAILABLE 은 항상 안전하므로 성공할 때까지 무한히 재시도한다

gRPC 메타데이터 키의 규칙으로 맞는 것은?

• 대소문자를 구별하며 grpc- 로 시작해야 gRPC 가 전달한다
• UTF-8 어떤 문자든 되고 값은 항상 base64 로 인코딩된다
• ASCII 이고 대소문자를 구별하지 않으며 grpc- 로 시작할 수 없고 바이너리 값 키는 -bin 으로 끝난다
• 숫자로만 이루어져야 하며 HTTP/2 헤더와 별도 채널로 전송된다