From 52d6632a0b51e48334ada3ec4d489d15c2d59c8a Mon Sep 17 00:00:00 2001 From: bt Date: Sun, 29 Mar 2026 08:45:04 +0200 Subject: [docs] Update docs --- docs/rfc.html | 1772 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ docs/rfc.txt | 267 +++++++++ 2 files changed, 2039 insertions(+) create mode 100644 docs/rfc.html create mode 100644 docs/rfc.txt diff --git a/docs/rfc.html b/docs/rfc.html new file mode 100644 index 0000000..42c570a --- /dev/null +++ b/docs/rfc.html @@ -0,0 +1,1772 @@ + + + + + + +System of Lightweight Electronic Communication + + + + + + + + + + + + + + + + + + + + + + + + +
Internet-DraftSOLECMarch 2026
btExpires 30 September 2026[Page]
+
+
+
+
Workgroup:
+
SOLEC Working Group
+
Internet-Draft:
+
SOLEC
+
Published:
+
+ +
+
Intended Status:
+
Experimental
+
Expires:
+
+
Author:
+
+
+
bt, Ed. +
+
RCTT.net
+
+
+
+
+

System of Lightweight Electronic Communication

+
+

Abstract

+

This document describes working principles, features and network protocol of +SOLEC system.

+
+
+
+

+Status of This Memo +

+

+ This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79.

+

+ Internet-Drafts are working documents of the Internet Engineering Task + Force (IETF). Note that other groups may also distribute working + documents as Internet-Drafts. The list of current Internet-Drafts is + at https://datatracker.ietf.org/drafts/current/.

+

+ Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress."

+

+ This Internet-Draft will expire on 30 September 2026.

+
+
+ +
+
+ ▲

+Table of Contents +

+ +
+
+
+
+

+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. 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 +
    • +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Table 1
TypeNameAttributes
0x00R
0x01SuccessSCE
0x02ErrorS
0x03HandshakeSC
0x04AuthC
0x05MessageSC
0xFFTestR
+
+
+

+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 +
+ + + + + + + + + + + + + + +
Table 2
TypeDescription
0x01Auth failed. Invalid username or password.
+
+
+
+
+
+
+

+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. +
    • +
+
+
+
+
+
+
+ + + 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_. -- cgit v1.2.3