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 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1772 insertions(+) create mode 100644 docs/rfc.html (limited to 'docs/rfc.html') 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. +
    • +
+
+
+
+
+
+
+ + + -- cgit v1.2.3