blob: 04d931e50fc0ecec62ee90f1213f00b6b0b32a9f (
plain)
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
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
|
SOLEC Working Group bt, Ed.
Internet-Draft RCTT.net
Intended status: Experimental 19 April 2026
Expires: 21 October 2026
System of Lightweight Electronic Communication
SOLEC
Abstract
This document describes working principles, features and network
protocol of SOLEC system.
Table of Contents
1. Introduction
1.1. Decentralisation
1.2. User to user communication
1.3. Channels
2. Network protocol
2.1. Protocol Data Unit Structure
2.2. Payload structure
2.3. Data types
2.3.1. Numeric types
2.3.2. Timestamp
2.3.3. String
2.4. Payload types
2.4.1. Success
2.4.2. Error
2.4.3. Handshake
2.4.4. UserAuth
2.4.5. ServerAuth
2.4.6. Message
2.4.7. Test
2.5. Sequential operations
2.6. Client-Server connection initialisation
2.7. Exchanging messages between servers
2.7.1. Authentication
2.7.2. Server-Server connection initialisation
3. Addresses
1. Introduction
SOLEC is currently under development for PWR group project and as
part of my engineering thesis.
System of Lightweight Electronic Communication or SOLEC is a system
for decentralised communication designed for low-speed networks. It
uses binary protocol to keep required bandwidth as low as possible.
Current implementation works on top of TCP/IP stack. In future,
SOLEC will be adapted to work over LoRa.
1.1. Decentralisation
Recurring problem with modern day instant messaging is its
centralisation. SOLEC solves is it in similar fashion to XMPP or
SMTP. SOLEC servers exchange messages between each other so the
users using server A can reach out users using server B.
1.2. User to user communication
User can exchange messages with other users of the network if they
are both in their _contacts_ group. Messages from untrusted users
are not forwarded by the server. If users are using different
servers chat history is stored on both.
1.3. Channels
Message can be send to a group of users called channel. Channels
settings and history is stored on a specific server. Users can
access channels from servers other than their own. To receive
channel messages user have to join specific channel.
2. Network protocol
In current version session is provided by TCP connection. Security
of client-server connection can be achieved using TLS.
2.1. Protocol Data Unit Structure
SOLEC is using Type Length Value (TLV) structure for data exchange.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure: SOLEC PDU Layout
* Type (8): Payload type is indicated by 1 octet which gives 256
types that can be represented.
* Length (16): Payload length is 2 octets. It indicates length of
the payload field. The length does not include type and length
fields.
* Payload (variable): Payload stores set of fields determined by its
type.
2.2. Payload structure
Payload usually consist of one or more data fields but it is possible
for payload to be empty. Some payload types are used only to signal
some event and does not carry any data.
2.3. Data types
Data types are basic types that are used in construction of more
complex payload types.
2.3.1. Numeric types
Numeric types are Big-Endian. Numeric types names are taken from Go
language spec (https://go.dev/ref/spec#Numeric_types). Following
types are in use:
* uint8
* uint16
* uint32
* uint64
Number in numeric type name is number of bits used to encode this
type.
2.3.2. Timestamp
Uint64 containing Unix timestamp in UTC timezone.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.3.3. String
String is prefixed with two octets indicating number of bytes that it
occupies. Text is encoded using UTF-8.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | UTF-8 string ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure: String Layout
2.4. Payload types
Payload type attributes describes following characteristics:
* R - Reserved: implementation should ignore payloads of this type
* S - Server: can be send only by a server
* C - Client: can be send only by a client
* E - Empty: signals an event but does not carry any data
+======+============+============+
| Type | Name | Attributes |
+======+============+============+
| 0x00 | | R |
+------+------------+------------+
| 0x01 | Success | SCE |
+------+------------+------------+
| 0x02 | Error | S |
+------+------------+------------+
| 0x03 | Handshake | SC |
+------+------------+------------+
| 0x04 | UserAuth | C |
+------+------------+------------+
| 0x05 | Message | SC |
+------+------------+------------+
| 0x06 | ServerAuth | S |
+------+------------+------------+
| 0xFF | Test | R |
+------+------------+------------+
Table 1
2.4.1. Success
Payload is always empty for this type.
2.4.2. Error
+=======+============+
| Type | Name |
+=======+============+
| uint8 | error_type |
+-------+------------+
Table 2
2.4.2.1. Error types
+======+============================================================+
| Type | Description |
+======+============================================================+
| 0x01 | Client auth failed. Invalid username or password. |
+------+------------------------------------------------------------+
| 0x02 | Not found. User or channel cannot access user or |
| | channel. |
+------+------------------------------------------------------------+
Table 3
2.4.3. Handshake
+=======+===========+
| Type | Name |
+=======+===========+
| uint8 | ver_major |
+-------+-----------+
| uint8 | ver_minor |
+-------+-----------+
| uint8 | conn_type |
+-------+-----------+
Table 4
2.4.3.1. Connection types
conn_type specifies type of the connection. User connecting to
server should use 0x01. If connection is initialize between two
servers to exchange message connection type should be 0x02.
Depending on connection type different auth method will be used.
+======+==================+
| Type | Connection type |
+======+==================+
| 0x01 | User -> Server |
+------+------------------+
| 0x02 | Server -> Server |
+------+------------------+
Table 5
2.4.4. UserAuth
+========+==========+
| Type | Name |
+========+==========+
| string | username |
+--------+----------+
| string | password |
+--------+----------+
Table 6
2.4.5. ServerAuth
+========+======+
| Type | Name |
+========+======+
| string | name |
+--------+------+
Table 7
2.4.6. Message
+===========+=================+
| Type | Name |
+===========+=================+
| string | source_address |
+-----------+-----------------+
| string | target_address |
+-----------+-----------------+
| timestamp | send_time |
+-----------+-----------------+
| string | message_content |
+-----------+-----------------+
Table 8
2.4.7. Test
Test payload is used for encoder and decoders testing. Clients and
servers should ignore this kind of payload.
+===========+=======+
| Type | Name |
+===========+=======+
| uint8 | num1 |
+-----------+-------+
| timestamp | time1 |
+-----------+-------+
| string | str1 |
+-----------+-------+
| uint16 | num2 |
+-----------+-------+
| string | str2 |
+-----------+-------+
| uint32 | num3 |
+-----------+-------+
| string | str3 |
+-----------+-------+
| uint64 | num4 |
+-----------+-------+
Table 9
2.5. Sequential operations
Some operations require multiple rounds of communication. In this
case payloads are send in a sequence. Payload that is not part of
this specific operation (for example incoming message) cannot
interrupt this process.
2.6. Client-Server connection initialisation
+--------+ +--------+
| Client | | Server |
+----+---+ +----+---+
| |
| Initialise TCP connection |
+--------------------------->|
| |
| Send [Handshake] |
+--------------------------->|
| |
| +- If [ver_major] does not match
| | server protocol version close
| | the connection.
| |
| Send [UserAuth] |
+--------------------------->|
| |
| Send [Error 0x01] |
|<---------------------------+- If [username] or [password]
| | does not match and close
| | the connection.
| |
| Send [Sucesss] |
|<---------------------------+
2.7. Exchanging messages between servers
Exchanging messages between SOLEC servers is a core concept behind
the project. Sending message to user residing on a different server
require estabilishing a connection between both servers.
2.7.1. Authentication
Server authentication is crucial to prevent message spoofing and
other forms of abuse. Server cannot use same auth process as clients
because that would require creating account for each server on any
other server which is impossible. Possible solution are TLS or other
public key based protocol.
As for now the issue remains open and server authorization uses mock
[ServerAuth] payload which specifies just the connecting server name.
This is obviously insecure.
2.7.2. Server-Server connection initialisation
+--------+ +--------+
| Server | | Server |
+----+---+ +----+---+
| |
| Initialise TCP connection |
+--------------------------->|
| |
| Send [Handshake] |
+--------------------------->|
| |
| +- If [ver_major] does not match
| | server protocol version close
| | the connection.
| |
| Send [ServerAuth] |
+--------------------------->|
| |
| Send [Sucesss] |
|<---------------------------+
3. Addresses
Message can be addressed to a single user or a channel.
* user@example.org
* #channel@example.org
|
