diff options
Diffstat (limited to 'docs/rfc.txt')
| -rw-r--r-- | docs/rfc.txt | 267 |
1 files changed, 267 insertions, 0 deletions
diff --git a/docs/rfc.txt b/docs/rfc.txt new file mode 100644 index 0000000..a53f170 --- /dev/null +++ b/docs/rfc.txt @@ -0,0 +1,267 @@ +SOLEC Working Group bt, Ed. +Internet-Draft RCTT.net +Intended status: Experimental 29 March 2026 +Expires: 30 September 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. Decentralization + 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. Auth + 2.4.5. Message + 2.4.6. Test + 2.5. Sequential operations + 2.5.1. Connection initialization + +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. Decentralization + + Recurring problem with modern day instant messaging is its + centralization. SOLEC solves is it in similair 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 octed which gives 256 + types that can be represented. + + * Length (16): Payload length is 2 octets. It indicates lenght 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 typres are basic types that are used in construction of more + comples 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 + +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: implementattion 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 | Auth | C | + +------+-----------+------------+ + | 0x05 | Message | SC | + +------+-----------+------------+ + | 0xFF | Test | R | + +------+-----------+------------+ + + Table 1 + +2.4.1. Success + + Payload is always empty for this type. + +2.4.2. Error + + 0 + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | Error Type | + +-+-+-+-+-+-+-+-+ + +2.4.2.1. Error types + + +======+=============================================+ + | Type | Description | + +======+=============================================+ + | 0x01 | Auth failed. Invalid username or password. | + +------+---------------------------------------------+ + + Table 2 + +2.4.3. Handshake + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ver_major | ver_minor | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.4.4. Auth + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | username (string) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | password (string) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.4.5. Message + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | source_address (string) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | target_address (string) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | timestamp | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | message_content (string) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.4.6. Test + + Test payload is used for encoder and decoders testing. Clients and + servers should ignore this kind of payload. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | num1 (uint8) | time1 (timestamp) | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | | str1 (string) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | num2 (uint16) | str2 (string) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | num3 (uint32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | str3 (string) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | num4 (uint64) | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.5. Sequential operations + + Some perations 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 incomming message) cannot + interrupt this process. + +2.5.1. Connection initialization + + * Client: Initialize TCP connection. + * Client: Send _handshake_. + * Server: If _major_ version of protocol differs close the + connection. + * Server: Otherwise send _handshake_. + * Client: Send _auth_. + * Server: If user credentials does not match send _error_ with + _auth_failed_. + * Server: Otherwise send _success_. |