-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathrfc.txt
127 lines (100 loc) · 3.9 KB
/
rfc.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
RType F. Beche
Category: Communication Protocol January 2018
RType Communication Protocol
Status of this Memo (58 lines per page)
This memo provides informations for the RType
communication protocol.Disribution of this memo is
unlimited.
Copyright Notice
Copyright (C) RType (2018). All Rights Reserved.
Table of Contents
1. Introduction............................2
1.1 Purpose.................................
1.2 Requierments............................
1.3 Terminologie............................
1.4 Overall Operation.......................
2. Notation Convention and Generic Grammar.
2.1 Command.................................
2.2 Arguments...............................
3. Serialisation...........................
4. Methode.................................
5. Request Header..........................
5.1 Opcode Array............................
5.2 Signification...........................
6. Author Address..........................
RType F. Beche
Category: Communication Protocol January 2018
RType Communication Protocol
1. Introduction
1.1 Purpose
This request for Comments provides informations about the
communication protocol for developping the Rtype video
game.You will find a description of the protocol
and an explanation of its use.
1.2 Requierments
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in RFC 2119 [34].
An implementation is not compliant if it fails to satisfy
one or more of the MUST or REQUIRED level requirements for the
protocols it implements. An implementation that satisfies
all the MUST or REQUIRED level and all the SHOULD level
requirements for its protocols is said to be "unconditionally
compliant"; one that satisfies all the MUST level requirements
but not all the SHOULD level requirements for its protocols is
said to be "conditionally compliant."
1.3 Terminology
This specification uses a number of terms to refer to
the roles played by participants in the RType communication.
connection
A transport layer virtual circuit established between two
programs for the purpose of communication.
message
The basic unit of this communication protocol,
consisting of a structure octets matching the syntax
defined in section 4 and transmitted via the UDP
protocol, client <-> server.
1.4 Overall Operation
This protocol behavior is based on message, the client and the server
can send and receive message on both side. see section 4 for the
message list.
RType F. Beche
Category: Communication Protocol January 2018
RType Communication Protocol
2. Notation Convention and Generic Grammar
Each message has an size of 512 octets
2.1 message
Message are binary suit of octet that means all message MUST be
serialised before being send. Message MUST be formated like this:
OPCODE SPACE $ARG1 $ARG2
ex: 0x01 playerid $touchN°1 $push&release
2.2 argument
Arguments are OPTIONAL, some messages can have arg. see section 4
for more informations about message.
3. Serialisation
This communication is a binary based protocol, all message and
command sent MUST be serialised before communication,
using the next stucture serialisation.
3.1 Structure serialisation
{
char opcode;
vector<string> args
}
4. Message
4.1 move
0x01 $playerId $x $y
4.2 attack
0x02 $playerId $x $y
4.3 die
0x03 $playerId
4.4 take bonus
0x04 $playerId $bonus
4.5 connexion
0x05 $data
6. Author Address
François Bêche
20 boulevard pierre 1ER
33000 Bordeaux
0648125249