-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathNew Protocol.txt
283 lines (236 loc) · 9.17 KB
/
New Protocol.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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
VectorNet Protocol Specification v2
2/16/09: The first specification of the VectorNet protocol was written. This was a text based protocol which used values separated by null strings.
12/30/09: The Second revision of the protocol is made. This utilizes multiple data types for information. In this version, the packets for VectorNet are made of of these parts:
BYTE Packet ID
WORD Packet Length
VOID Data
Note: By default, the port for VectorNet is 4800.
When flag is mentioned in any of these packets, it refers to these values:
0x00: Normal VectorNet User
0x01: VectorNet Admin
0x02: VectorNet Moderator
0x04: VectorNet Channel Operator
0x08: squelched
0x10: muted
0x20: hidden (unseen by the client, cannot parse info, but can hear text)
If you see Client <-> Server, that means the data sent is exactly the same data
that is received from client to server, and vice versa
VNET_KEEPALIVE (0x00) Client <-> Server
Data:
None
-Note: This ensures that the client is still alive
Just reply to this packet when its sent to you
VNET_LOGON (0x01) Client -> Server
Data:
STRING Username
STRING Password
STRING Client Name
VNET_LOGON (0x01) Server -> Client
-The response to 0x01
Data:
BYTE Logon result (everything after this byte is included if result is 0x00)
STRING Server version string (VectorNet x.xx by Vector)
STRING Hosted by name
STRING Your name (#2, etc., if you log on the same name more than once)
DWORD Your ping
BYTE Your flag on the server (regular user, moderator, admin, etc.)
Logon result can be one of:
0x00: Account logged on successfully
0x01: Invalid password
0x02: Invalid characters in name
0x03: Account is banned
0x04: Account passed, You need to send a challenge to complete logon
VNET_SERVERCHALLENGE (0x02) Client -> Server
Data:
STRING Challenge key
-Challenge key should be a random string representing the unique client
VNET_SERVERCHALLENGE (0x02) Server -> Client
Data:
BYTE Challenge result
-Challenge result may have only two values:
0x00: Client has passed the challenge
0x01: Client has failed the challenge (client will now be disconnected)
0x02: Challenge has just been created (no prior known entry for this client)
VNET_CHATEVENT (0x03) Client -> Server
Data:
STRING Message
-Simply send this message to VectorNet
VNET_CHATEVENT (0x03) Server -> Client
Data:
BYTE Message ID
DWORD Ping
BYTE Flag
STRING Username
STRING Text
Data:
There are several message IDs, to which Username, text, Ping, and Flag might change
0x01: ID_USERJOIN
Text: The name of their product
0x02: ID_USERLEAVE
Text: The name of their product
0x03: ID_USERTALK
0x04: ID_USEREMOTE
0x05: ID_SERVERINFO (Ping field contains server message ID)
0x01: Server error messages
0x02: Server info messages
0x03: Account-related messages
0x04: Broadcast messages (Username contains name of broadcaster)
0x05: Successful channel join
- Username contains name of channel owner
- Text contains proper cased channel name
- Flags contains channel's flags
0x06: ID_USERJOINCHANNEL
Text: Contains the name of their client
0x07: ID_USERLEAVECHANNEL
Text: Contains the name of their client
0x08: ID_WHISPERTO
0x09: ID_WHISPERFROM
VNET_APPS (0x04) Client <-> Server
Data:
BYTE App ID
BYTE App Flag
App flag has the following values:
0x00: Client does not support this app
0x01: Default flag (send this in all communications)
0x02: Denied (User has denied the request)
0x03: App quit (send this when you want the other user to quit the app)
0xFF: Initial request (when you wish to start an app, send this first)
STRING Name of user to send packet to (Server -> Client contains name of sender)
VOID Rest of data
The app IDs are the following:
0x00: Unsupported
Notes: The client that receives an ID it does not support
should send this ID back to the other client
0x01: Tic-Tac-Toe
0x02: VNET PAD
-Note: The individual app protocols are shown below
For app ID 0x01 (APP_TICTACTOE) Client -> Server
Data:
BYTE Event ID
BYTE Extra byte in Events (S>C 0x08, C>S and S>C 0x09)
STRING Extra string in event 0x10
The events can be summarized with the following bytes:
0x01: Game request (requests a game from the other client)
0x02: Game accept (accepts a game request from the other client)
0x03: Game deny (Rejects a game request)
0x04: Game quit (quits a game in progress)
0x05: Game reset (resets the current game)
0x06: Game prepare (selects who plays as what, X or O)
- The server will determine who plays as what (only ID handled by the server)
- The result will be sent to the other client as a BYTE:
0x01: X
0x02: O
- Only on S > C will there be an extra BYTE
0x07: Board move has the following moves as a BYTE:
0x01: bottom left
0x02: bottom
0x03: bottom right
0x04: left
0x05: center
0x06: right
0x07: top left
0x08: top
0x09: top right
0x08: Game chat (chat messages passed between players)
STRING Text
0x09: Game already in progress (the client is already playing a tic-tac-toe game)
For app ID 0x01 (APP_TICTACTOE) Server -> Client
Data:
- This packet just mirrors the packets sent from client to client
- Note the different events which require an extra BYTE:
0x07, and 0x08:
For app ID 0x02 (APP_VNETPAD) Client -> Server
Data:
BYTE Message ID
Types of IDs:
0x01: Sets a title for this pad session
STRING Name of session
0x02: Passes control to other client
0x03: Requests the other client to clear their pad
0x04: Updates the other user's pad
STRING Appended data
VNET_LIST (0x05) Client -> Server
Data:
BYTE Request ID
-Requests a list of users in the client's current channel
Types of requests are:
0x01: Users in current channel
0x02: Banned users in channel
0x03: Users on VectorNet
VNET_LIST (0x05) Server -> Client
Data:
BYTE List Type
WORD User Count
List type may be one of the following:
0x01: Users in client's current channel
0x02: Banned users in client's channel
0x03: Users currently on VectorNet
0x04: Indicates a stat update
For Each User:
STRING Username
STRING Client
STRING Channel (on ID VNET_SERVER_LIST (0x03))
BYTE Banned (on ID VNET_SERVER_LIST (0x03))
STRING Channels banned from (on ID VNET_SERVER_LIST (0x03))
DWORD Ping
BYTE Flag
Remarks: The fourth field, (BYTE banned), if 0x01, will include the next STRING as a list
of channels the user is banned from, delimited by the 0x01 character
otherwise the next STRING field will not be present.
VNET_QUEUESHARE (0x06) Client -> Server
-This packet sends the specified message to any other clients
participating in message sharing (Battle.Net bots)
which requires the queue sharing byte to be on at login
Data:
BYTE Action ID
For ID 0x01:
BYTE Enable/Disable Queue Sharing (0x01 = on, 0x00 = off)
STRING Battle.Net Channel (If enabling queue sharing)
For ID 0x02:
BYTE Message ID (0x01 = Normal, 0x02 = Load Moderation, 0x03 = Flood Moderation)
STRING Battle.Net channel
STRING Message to send to others
For ID 0x03:
STRING New queue master
For ID 0x04:
BYTE IP pool status (0x01 = on, 0x00 = off)
For ID 0x05:
STRING User to remove from pool (can only be done by channel master)
Remarks for the specified IDs:
0x01:
This just enables/disables queue sharing functionality
0x02:
All users must be in the same Battle.Net channel for messages
to be passed to other clients
0x03:
Note: If the name STRING is not sent, the server will send back
a reply of who the current channel master is.
Also note that only the channel master may change
the current channel master, or a VectorNet admin
0x04:
This opens or closes your IP pool, if you are channel master
so no other users may join your pool
0x05:
This removes a user from your pool, so they can no longer
take part in queue sharing
VNET_QUEUESHARE (0x06) Server -> Client
Data:
BYTE Message ID
STRING Message (not contained in ID 0x01 or 0x04)
Message IDs consist of the following bytes:
0x01: No reply sent from server
0x02: Message sent from another queue slave. Send this to Battle.Net.
0x03: Message contains name of channel master (if request is not blank)
0x04: No reply sent from server
---------------------------------------------
- -
- -
- How the queue sharing process works -
- -
- -
---------------------------------------------
You must send the queue sharing packet with ID 0x01 to enable queue sharing.
You must also be in the same Battle.Net channel as another user who is also
participating in queue sharing. Furthermore, they must be in the same IP pool
as you are. If you are the channel master, you may open and close the pool
at your leisure. If the pool is closed, no one else may join your queue pool