Skip to content

Commit 25a3abd

Browse files
TwoTenPvPTwoTenPvP
committed
Added temp protocol docs & update API reference to 1.0
1 parent c10e79a commit 25a3abd

File tree

274 files changed

+2594
-1301
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

274 files changed

+2594
-1301
lines changed

‎Protocol.md

Lines changed: 216 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,216 @@
1+
# MLAPI Protocol
2+
The MLAPI protocol is layered. The layers can be seen below.
3+
4+
The first layer is the UDP IP layer. Ontop of the UDP layer, the Unity Network Transport layer is built. And just after that, the MLAPI's protocol starts to appear. The MLAPI has two protocol stages. The first stage is the generic MLAPI message protocol. This is the protocol all messages use that is sent by the user or the MLAPI library.
5+
6+
The structure can be seen below, note that all messages use little endian format.
7+
8+
## MLAPI Generic Message Format
9+
The first two bytes define what message type the message is. This message type is represented as a unsigned int16. The first 32 values are reserved for MLAPI messages. As of version 0.1.7, 10 messages are used. The rest of the message types are reserved for use by the user. That means the user can define ((2^16)-32)=65504 different messageTypes.
10+
11+
The next byte defines if the message is "targeted", see the targeted section on the wiki for more information. The byte is treated as a bool.
12+
13+
**If** the message is targeted (the previous byte was 1)
14+
15+
The next 4 bytes define the target networkId, a unsigned int32.
16+
17+
The next 2 bytes define the networkBehaviour orderId from the root networkObject root. That is, the first networkBehaviour under the networkObject we target (defined by previous 4 bytes) would be a 0, the second one would be a 1 and so on.
18+
19+
**Endif**
20+
21+
The next byte represents wheter or nor the message is a passthrough message, see the passthrough section on the wiki for more information. If the byte is 1, it's true, if it's 0 it's false.
22+
23+
**If** the message is a passthrough message (the previous byte was 1)
24+
25+
The next 4 bytes is a unsigned int32 specifying the clientId this message targted at.
26+
27+
**Endif**
28+
29+
The next two bytes is a unsigned int16 representing the size of the message payload (next field). If the channel this message is sent on is an encrypted channel, this will be the size of the encrypted payload.
30+
31+
The last field is the message payload. It has the size specified in the previous field. This is where the next layer sits. This is the messageData. If it's a user messageType, this is the data you send with your message. Otherwise, see the next section for the MLAPI internal message formats
32+
33+
34+
## MLAPI Internal Messages
35+
36+
### MLAPI_CONNECTION_REQUEST (MessageType 0)
37+
This message type is sent Client to Server. It's purpose is to ask the Server to join by providing information that help the server decide. This is the first message of the MLAPI Handshake
38+
39+
The first 32 bytes is a SHA256 hash of certain fields in the NetworkConfig.
40+
41+
**If** encryption is turned on
42+
43+
The next two bytes represents a unsigned int16 specifying the size of the public diffie hellman key.
44+
45+
The next bytes has the size specified above and contains the diffie hellman public key of the client.
46+
47+
**Endif**
48+
49+
**If** conectionApproval is turned on
50+
51+
The next two bytes represents a unsigned int16 specifying the size of the connectionData.
52+
53+
The next bytes has the size specified above and contains the connectionData.
54+
55+
**Endif**
56+
57+
### MLAPI_CONNECTION_APPROVED (MessageType 1)
58+
This message is sent Server to Client, it's purpose is to notify Client's that their request has been approved and they are now fully joined. This is the last handshake message. (The request being MessageType 0)
59+
60+
The first two bytes represents a unsigned int32 containing the clientId the server has assigned to the recepient.
61+
62+
**If** scene management is enabled
63+
64+
The next 4 bytes represents a unsigned int32 containing the sceneIndex the server is currently using.
65+
66+
**Endif**
67+
68+
**If** encryption is enabled
69+
70+
The next two bytes represents a unsigned int16 specifying the size of the next field.
71+
72+
The next bytes have the size of the previous field and represents the diffie hellman public key.
73+
74+
**If** sign keyexchange is enabled
75+
76+
The next two bytes represents a unsigned int16 specifying the size of the next field.
77+
78+
The next bytes have the size of the previous field and contains a RSA signature of a SHA512 hash of the diffie hellman public key.
79+
80+
**Endif**
81+
82+
**Endif**
83+
84+
The next 4 bytes represents a single precision floating point value containing the current networkTime.
85+
86+
The next 4 bytes represents a signed int32 and contains a network timestamp generated by the NetworkTransport.
87+
88+
The next 4 bytes represents a signed int32 and contains the number of connected clients.
89+
90+
The next (4 * previousField) bytes is a sequence of unsigned int32 containing the clientId of a client.
91+
92+
**If** handle object spawning is turned on
93+
94+
The next 4 bytes represents a signed int32 containing the amount of networkedObjects is spawned.
95+
96+
The next (39 * previousField) represents information about each networkedObject. That is, each NetworkedObject has 39 bytes sent about it. A NetworkedField structure looks like this:
97+
98+
First byte specifies if the object is a playerObject. If the byte is 1, it's true, if it's 0, it's false
99+
100+
The next 4 bytes is a unsigned int32 containing the networkId of the object
101+
102+
The next 4 bytes is a unsigned int32 containing the ownerId of the object
103+
104+
The next 4 bytes is a signed int32 containing the networkedPrefabId to create the object from
105+
106+
The next byte is a boolean specifying if the object is active in the hierarchy
107+
108+
The next byte is a boolean specifying if the object is a sceneObject
109+
110+
The next 4 bytes is a single precision floating point value containing the x position of the object
111+
112+
The next 4 bytes is a single precision floating point value containing the y position of the object
113+
114+
The next 4 bytes is a single precision floating point value containing the z position of the object
115+
116+
The next 4 bytes is a single precision floating point value containing the x rotation of the object
117+
118+
The next 4 bytes is a single precision floating point value containing the y rotation of the object
119+
120+
The next 4 bytes is a single precision floating point value containing the z rotation of the object
121+
122+
**Endif**
123+
124+
### MLAPI_ADD_OBJECT (MessageType 2)
125+
Sent server to client
126+
127+
**If** handle object spawning
128+
129+
The first byte is a boolean, represents if it's a player object or not
130+
131+
The next 4 bytes is a unsigned int32 representing the networkId
132+
133+
The next 4 bytes is a unsigned int32 representing the ownerId
134+
135+
The next 4 bytes is signed int32 represents the prefabId
136+
137+
The next byte is a bool representing if it's a sceneObject
138+
139+
The next 4 bytes is a single precision floating point value containing the x position of the object
140+
141+
The next 4 bytes is a single precision floating point value containing the y position of the object
142+
143+
The next 4 bytes is a single precision floating point value containing the z position of the object
144+
145+
The next 4 bytes is a single precision floating point value containing the x rotation of the object
146+
147+
The next 4 bytes is a single precision floating point value containing the y rotation of the object
148+
149+
The next 4 bytes is a single precision floating point value containing the z rotation of the object
150+
151+
**Else**
152+
153+
The first 4 bytes represents a unsigned int32 containing the ownerId
154+
155+
**Endif**
156+
157+
### MLAPI_CLIENT_DISCONNECT (MessageType 3)
158+
Sent server to client
159+
160+
The first 4 bytes is a unsigned int32 containing the clientId
161+
162+
### MLAPI_DESTROY_OBJECT (MessageType 4)
163+
Server to client
164+
165+
The first 4 bytes is a unsigned int32 containing the netId
166+
167+
### MLAPI_SWITCH_SCENE (MessageType 5)
168+
Server to client
169+
170+
The first 4 bytes is a unsigned int32 containing the sceneId
171+
172+
173+
### MLAPI_SPAWN_POOL_OBJECT (MessageType 6)
174+
Server to client
175+
176+
The first 4 bytes is a unsigned int32 containing the netId
177+
178+
The next 4 bytes is a single precision floating point value containing the x position of the object
179+
180+
The next 4 bytes is a single precision floating point value containing the y position of the object
181+
182+
The next 4 bytes is a single precision floating point value containing the z position of the object
183+
184+
The next 4 bytes is a single precision floating point value containing the x rotation of the object
185+
186+
The next 4 bytes is a single precision floating point value containing the y rotation of the object
187+
188+
The next 4 bytes is a single precision floating point value containing the z rotation of the object
189+
190+
### MLAPI_DESTROY_POOL_OBJECT (MessageType 7)
191+
Server to client
192+
193+
The first 4 bytes is a unsigned int32 containing the netId
194+
195+
### MLAPI_CHANGE_OWNER (MessageType 8)
196+
Server to client
197+
198+
The first 4 bytes is a unsigned int32 containing the netId
199+
200+
The first 4 bytes is a unsigned int32 containing the ownerClientId
201+
202+
### MLAPI_SYNC_VAR_UPDATE (MessageType 9)
203+
Server to client
204+
205+
The first byte represents the amount of dirty fields
206+
207+
The next 4 bytes is a unsigned int32 containing the netId
208+
209+
The next 2 bytes is a unsigned int16 containing the order of the netBehaviour
210+
211+
//HERE IS THE SYNCVAR DATA. NOTHING TO OPTIMIZE
212+
213+
### MLAPI_ADD_OBJECTS (MessageType 10)
214+
Server to client
215+
216+
Same as ADD_OBJECT, but contains two bytes (unsigned int16 specifying the amount of objects, then repeated ADD_OBJECT patterns)

0 commit comments

Comments
 (0)