/
TopicFormat.txt
30 lines (23 loc) · 1.83 KB
/
TopicFormat.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
MQTT uses a topic string to identify a resource (intentionally loose term) a client wants to
access or provide. A standard URI structured "slash path" gives a good way to represent a
topic hierarchy so many systems employ some variation of one.
Since topic structure and naming conventions impact how this implementation determines who
gets what messages and what code gets run by it, following a fairly rigid topic definition
format ends up being critical.
example: Client/E/ModApi.GameEvent.WindowClosed/20E9AD182A2D
<sourceid>/ the name of the source service (except for commands which use to target)
<msgclass>/ C=command, R=response, E=event, I=information, X=exception
<subjectid>/ the subject of the message (user topic string as dot path)
<clientid> a unique session identifier (currently the last 12 of a guid)
A bus partner subscribes to Command topics that it can or is expected to issue a Response
to that return data and/or change something. Events occur as a result of in-game actions
or may be issued as a result of async events occuring in a bus partner. When errors occur
exceptions are raised in the form of messages. Finally informational messages can be published
to facilitate logging, debugging, and similar non-actionable bus activity.
Some messages imply conversational semantics where a command is sent, a response (or exception)
is returned, and potentially future events are triggered. Bus partners can take observational
roles (like a logger) that consume but do not produce actionable messages.
The ESB uses the Application.Mode (SinglePlayer, Client, DedicatedServer, PlayfieldServer) as
the sourceid for these services. While in the lobby the player connection is considered as a
Client and it is only after entering the game that the determination this is a SinglePlayer
connection can be made.