two Apis, two Plays as manual RouteMesh peers · each Play's tictactoe.api picks one Api
Guided views
Explore this system
Step through curated paths without changing the source diagram.
Beat
Next
ReadyChapter 01 / 01
Guided chapter
Diagram guideExplore this system
Inspecting compiled semantics
E ExportT ThemeS Style0 Reset+ Zoom in- Zoom outEsc Close
Find a node
⌕/
No matching nodes
Semantic passport
Verified source
Authored reach
Route probeChoose a start node
Pick two semantic nodes on the diagram
Choose the source, then the destination. Direction matters.
Semantic lensCompare system roles
Choose up to two semantic kinds. One reveals its real traffic; two compare only direct authored relationships.
Choose a kind to inspect its nodes and touching relationships.
Semantic radar
Building overview
Click nodeDrag to pan
Semantic radar needs more MAP space.
Client and server edges
• Clients (mermaid subgraph): Host, Guest, Observer. Host connects HTTP to Api A and STREAM to Play A; guest and observer connect HTTP to Api B and STREAM to Play B.
• Api A/B are object clients; Play A/B are object servers providing the same object type, Entry Spot, and Logical Multicast membership.
• All four Api↔Play solid links are the same tictactoe RouteMesh; Play A — Play B is the manual RouteMesh peer.
tictactoe.api channel (dashed) and location
• Each Play has an independent tictactoe.api ClientServer channel that receives the Api A and Api B endpoints and selects one Api for an authentication request.
• No object peer is created between Api A and Api B; the Play↔Api peer direction is set by the runner's manual endpoint configuration.
• The Location Store (in the §3 resource table) records the current owner of RoomId and ActorId; the Relocation Store holds only post-relocation pending-request recovery. CreateGameHttpRes.PlayEndpoints is for ingress selection, not owner evidence.