시스템 구성과 topology — 구조적 연결

수동 endpoint로 Client·Api·Play를 잇는다 (Redis Location·Relocation Store는 resource 표에서 설명)

시스템 구성과 topology — 구조적 연결 수동 endpoint로 Client·Api·Play를 잇는다 (Redis Location·Relocation Store는 resource 표에서 설명) Host Client · Architecture component Host Client Api A · Servers Api A tictactoe.api · Play A · Api 선택 · Servers tictactoe.api Play A · Api 선택 Play A · Servers Play A Play B · Servers Play B tictactoe.api · Play B · Api 선택 · Servers tictactoe.api Play B · Api 선택 Api B · Servers Api B Guest Client · Architecture component Guest Client Observer Client · Architecture component Observer Client HTTP STREAM Servers

연결 읽는 법

  • • 실선(HTTP·STREAM·RouteMesh)은 원문의 `---` 무방향 구조적 연결이다 — 요청 방향이 아니라 peer·ingress 연결 의도만 나타낸다(화살표 머리는 렌더 제약이며 방향 주장이 아니다). Api↔Play 네 실선은 모두 같은 tictactoe RouteMesh이고 Play A—Play B가 수동 RouteMesh peer다.
  • • 점선(tictactoe.api → Api)만 원문의 `-.->` 방향 연결이다. 각 Play의 독립 tictactoe.api ClientServer channel이 Api A/B endpoint를 받아 authentication request를 보낼 때 Api 하나를 선택한다.
  • • AC1·AC2 원문 라벨: 'Play A tictactoe.api / Api 하나 선택', 'Play B tictactoe.api / Api 하나 선택'. host는 HTTP로 Api A·STREAM으로 Play A, guest·observer는 HTTP로 Api B·STREAM으로 Play B에 연결한다.

역할과 경계

  • • Api A/B는 object client이며 room create request를 Play object server로 보낸다. Play A/B는 object server로 같은 object type·Entry Spot·Logical Multicast membership을 제공한다.
  • • Api A와 Api B 사이에는 object peer를 만들지 않는다. Play A/B와 Api의 peer 방향은 runner가 제공하는 수동 endpoint 설정으로 구성한다.
  • • CreateGameHttpRes의 PlayEndpoints는 ingress 선택용이며 room placement·owner 증거가 아니다. Redis Location·Relocation Store는 이 그림이 아니라 resource 표에서 설명한다.